I always smile when learning about a new project framework or tool. At some point, the purveyor of the method is bound to mention that this technique is different because of the soft skills of the project manager. Be that listening, relationship building or conflict resolution.
For example, in the last post we looked at the mechanics of defining (envisioning in Agile) a project. However, the practitioners of any framework will tell you that the key to a good definition is to include the whole team. And by team, they mean customers, sponsor, users and any other relevant stakeholder (for instance, in a compliance project you will include the Quality Manager or subject matter expert for the standard or regulation you are following). Moreover, they won’t leave it there.
Each framework encourages project managers (PMs) to use all the soft skills mentioned so far in this post. They tell us that the modern-day PM has moved on from command and control to coaching and facilitating and I welcome that change. The pioneering Project Manager builds skills across three areas: modern project management, change management and business analysis.
We have to be comfortable with the mechanical skills of project management. Indeed, we need to work quickly and efficiently in this arena because we are also team coach. We work with our team to support individuals and help them deliver. We do not do the job for them or make technical decisions; we help our team so team members can apply their expertise to the project. We create an open environment where each team member can express their opinion and concerns. We negotiate with the sponsor and key stakeholders, making sure they understand what they are buying into and the impact of changes on cost and timings.
As a change manager, we think about the end customer of our project. We make sure they are ready to change; we resolve their concerns; we act as their advocates within the project team. If we are launching a new product or service, we bring the voice of the customer into our requirements, reviews and decision-making.
Wearing a Business Analyst hat, we find and provide the information to make data-driven decisions. We present progress in a way that is meaningful. We can build a business case and realise benefits. We structure requirements to make them congruent and complete.
Why pioneering? At times our stakeholders are impatient with good preparation (I was once told to “get on with the f’ing project”, which the board later cancelled because the preparation work showed it was ill-conceived). Standing up against this pressure is hard, particularly when recruiting managers seek a Project Manager to produce a Gantt chart and nothing more. There will always be an important place for a schedule and risk register in projects, but I hope that soon we will see the end of the belief that the key skills of a PM are the ability to work a scheduling tool and spreadsheet.