None of us know what will happen tomorrow, let alone in six months’ time, it is a fallacy to believe that a project will follow a strict plan.

Project management is fundamentally about risk management. Whilst planning a project is essential, the role of a Project Manager is to continuously adapt to change and risks coming their way.

Through adopting agile ways of working, we tackle risk head on and use it to inform our project set-up, project risks cannot be managed with a risk log alone.

The Product Owner

In our experience, the biggest risk in a project is the lack of a dedicated Product Owner or one with a lack of understanding around the requirements of the role.

This is the most important role to identify with the client (internal or external) to the extent that we write into our contracts, that we cannot guarantee our price or timelines without a competent, dedicated Product Owner.

We identify the person and make sure they have the authority to make decisions about the product, the budget and timeline, until this is in place, the project should not commence.

Once the Product Owner is identified we ensure that they understand their role in the project, the involvement and time required for this role as well as ensuring a mindset of embracing change from the get-go.

Managing the Project Triangle

Every project has three main constraints competing against one another: time, price and quality. Whilst they can all live in harmony, no project can realistically achieve all three, generally two out of three at most.

In our experience most projects have one constraint that trumps all the others:

• An immovable deadline e.g. sporting event, TV show etc
• A fixed budget: it's year-end, no more money will be given regardless of circumstances etc
• Only incredibly high standards will only do: we are competing against formidable competitors and need to exceed expectations to make a dent in the market etc

Determining the main project constraint is paramount because it will inform the project management set-up:

• project metrics
• information sharing protocols and technology
• escalation procedures

For example, if the budget is the main constraint, timesheets will be done daily and linked with an automated financial reporting system, so project financial information is collected quickly and accurately. Thresholds of overspend and key warnings are automatically set-up to warn stakeholders before budgetary problems arise.

If time is of the essence, the reporting will be focused on features delivered against the original timeline rather than time spent on the project. The cost will still be tracked and reported but the key data should concentrate on the deliverables, not time spent by the team.

If quality is of the essence, user testing and feedback will be a key part of the project development cycle and decision making regarding the project backlog management and feature pipeline.

External Dependencies

Of all project risks, the least manageable ones are those out of the team’s control. These can be split into three categories, all requiring different strategies.

New technology or framework

Too often the latest tech or new framework won’t be able to deliver on some of the basic product requirements like scalability, performance or stability.

The Project Manager needs to ensure any new tech or framework is tackled early in the project in terms of key feasibility, scalability and performance.

For example, can your new JS framework for a live event application perform under stress and deliver speedy response times or will React.JS work with the content management system you chose?

External services

External services, APIs or authentication services often have poor documentation, are unable to scale properly or simply do not function as expected. 

Any external service used will require extra work to de-risk e.g. caching strategy, alternative UX for login, so they need to be assessed early in the project.

In my experience, development teams suffer from ‘hope-ium’ i.e. they are addicted to the hope that technology will work the first time, but it generally doesn’t. Do not fall into this trap.

Assets delivery by third parties

Any deliverables: graphics, copy, translation etc are rarely delivered on time or in the right format.

Our strategy is to require data/asset samples ahead of any development so we can assess the impact on development before we start. We also make clear in our contracts that feature delivery and price are dependant on timely delivery of assets in the agreed formats from third parties.

As per with external services, don't fall into the trap of assuming everything will be delivered perfectly and on time.

Conclusion

Project management should be at the service of the product rather than the original plan.

There is no doubt that project management is largely about risk management, but I would argue that the word risk is unhelpful.

Every change and dependency is potentially a risk, and therefore project management is about adapting to change to reduce risk on a project.

This is why I believe Agile methodologies are better suited to project management as they are inherently designed to adapt to change.

The key is to accept the fact that projects are risky, the best job a Project Manager can do is work very closely with the Product Owner and the team to embrace change as a constant and have strategies to adapt.