Being accountable for the planning, execution, and delivery of a project is demanding. Managing people, facilitating communication, resolving conflict, and mitigating risk are prerequisites to completing on schedule, and within an agreed budget. Add to this the often unpredictable nature of these factors and it’s little wonder that project managers feel a great burden of responsibility.

Those suited to such a role are acutely aware of this responsibility and it’s something they take on quite willingly. They perceive the role of a project manager as a guardian presiding over a project in order to protect it from failure. They are the last line of defense, willing to take the fall should something go wrong. It’s an admirable position of leadership they seek to adopt, but the responsibilities attached to it can become overwhelming for even the most seasoned practitioners.

That’s why I think they need to lose control.

Chasing waterfalls

Software-driven projects are rarely predictable. Initial requirements may prove difficult to implement, or, on reflection, prove to be the wrong approach. People are also fallible and can behave irrationally under pressure. Those project managers who fail to recognize these contributing factors and make allowances for them are simply battling the forces of nature that ultimately derail many projects.

In truth, failure is very likely an outcome at many stages of a project, so project managers’ tendency to implement strategies for avoiding it when they feel ultimately responsible seems natural. It’s easy for them to believe that the more predictable and orderly things are, the less likely it is that failure will befall their project. So preparing a detailed and prescriptive plan for the work required to complete the project seems like a good place to start.

The more traditional and predictive waterfall model is one safety net managers have used for many years as they seek greater levels of security. It’s a time honored approach, and it’s an especially common theme for project managers involved in software development.

Faced with commercial pressures to meet deadlines and work within the bounds of restrictive procurement rules, project managers are also averse to change. They seek predictability and produce project artifacts like gantt charts, interface designs, and technical specifications that endeavour to precisely define project outcomes. They see them as a blueprint for success and use them as a weapon against anything that may threaten it.

But the more project managers seek certainty, the more they endeavour to control the factors that may affect it. Those that receive the most attention tend to be the people around them—those responsible for producing the outputs a project requires. Suddenly, strict boundaries constrain the project team, and managers encourage that team to avoid deviation. They direct all of the team’s efforts to appeasing stakeholders expecting a predefined outcome.

Whist these behaviors may be understandable products of the pressure brought to bear on the project, the project manager creates an environment in which change is perceived as a highly disruptive occurrence. Thus, the reengineering of supposedly precise specifications and delays to a fixed schedule are unacceptable. Original plans become inflexible, and project teams are subject to close scrutiny in order to ensure overall compliance with it.

The much better alternative is to take a more agile, collaborative approach—where responsibility is distributed, failure is not feared, and change is recognized as a constant. It’s a more common-sense approach that better accommodates the human factors that so strongly influence the success or failure of a project.

Begin with culture

Yet project managers unaccustomed (or even unaware) of this alternative require a fundamental shift in mindset. Overcoming the desire for a prescriptive approach is not easy. Many are trapped in staid business environments where tradition dictates practice, and the appetite for change is low.

Fortunately, more managers are recognizing the appeal of agile approaches to project management. And they’re heavily promoting these across the business sector while adoption in government is strengthening. People acknowledge agile approaches as a good way to increase value, foster a greater level of engagement with users, produce better products and services, and increase the well being of the teams who produce them.

The trend itself is good leverage for project managers who wish to move toward more agile practices. Even small measures to become more agile can benefit their projects. They should better harness their leadership abilities to influence key stakeholders and managers. If possible, they should also seek to be more involved in the procurement process and negotiate a more agile approach at this early stage of the project.

The key message for project managers seeking a change is that you need to work on developing the right mindset both for yourself and those around you. Facilitate more collaboration, empower individuals to take on more responsibility, and encourage your teams to become more self organized. Stop obsessing about plans or processes and lead your projects rather than trying to control them.

You might even find your team celebrating your next project as something enjoyable—not just something that’s over.