This article is the second in a five part series around successfully delivering step changes in value through a comprehensive view of project / portfolio best practices and organizational change management. To access the other articles in this series, click here.


Business processes may sound like a boring topic, but it’s the organizational equivalent of eating your veggies and going to the gym.

  • Having capable people who know what they’re doing is a good thing. But it’s a risky thing to depend on.

  • Having technology in place can help, but if the process is broken, then you will only amplify the problem.

  • Having a good governance framework is useful, but it usually finds issues too late to fix the root cause.

  • Having a great project culture is awesome, but if you have project teams re-inventing the same processes with each new project, are you really getting the most value from your team?

Plan the Work, then Work the Plan

Project processes and supporting business processes are fundamentally about delivering on this basic maxim: “plan the work, then work the plan.”

There is no cure for bad planning processes, I’m afraid. So it’s critical to get this right. But it involves rolling up your sleeves and applying a few project fundamentals. But what does “good” really look like? Even though there are so many project methodologies, and the fundamental processes, particularly in project controls disciplines, that have been around for decades, teams somehow feel the need to re-invent the wheel.

High performing project organizations don’t throw out the playbook every time a new project comes along - they build a strong foundation around the basics - those aspects of projects which don’t really change - even in the face of staggering new technological capability, and adopt a clear approach to continuous improvement.

Take the estimating process for example. It is the same as it as been for decades - maybe even longer than that. We have new technologies which can improve the accuracy of quantities, new ways to engage the market for pricing / escalation / inflation / forex data, new ways to integrate schedule, new ways to apply factorization and benchmarking, new ways to evaluate risk and uncertainty ranges, new ways to present and analyse scenarios. But at its core, the process is identical. The trick is finding new ways to apply innovation to these fundamentals.

Process Standardization in Capital Projects

I have reviewed hundreds of projects around the world, and there is one thing that every single project manager has said to me when I arrive:

“Let me tell you why my project is different / special".

As if this gives them the license to throw everything out, ignore the fundamentals, and try to create something unique. Nothing destroys an organization’s ability to continuously learn faster than this approach. And in all my years of with global portfolios, I have only encountered 2 projects which truly qualify as so different to warrant a fully bespoke approach (and both of these were disaster recovery / incident response projects).

This isn’t to say that we should enforce a blind compliance to process, either. We should allow projects to acknowledge when their project would or would not benefit from a certain process, and adapt it or eliminate it. There is a way to do this without throwing out the whole playbook.

Consider this spectrum of process standardization:

  • Nothing: No process documentation at all. Everyone makes it up as they go along.

  • Light Documentation: We made it all up, but at least we wrote it down.

  • External Standards: Here is the PMBoK, PRINCE2, etc. Figure it out from there.

  • Past Project Procedures: Here are a few small documents we wrote long ago, use them if you want.

  • Optional Guidance: Here are some guidelines, recommendations and best practices. Use them if you want.

  • Right-sized requirements + Helpful Guidance: Here are our requirements for projects, things you should generally do every time, and the visual aids & training to go with them. But we also have some useful guidelines, templates, examples and best practices.

  • Rigid Requirements: Here are our high-level requirements for projects. Do not ever deviate from them. As long as you deliver these requirements, you can do whatever you want around the edges.

  • Full Process Documentation: Here is our full suite of ISO-compliant process documentation policy, procedures, work instructions, etc. They tell you everything to do, and we will audit against these.

  • Rigid Enterprise Process Models: Here is our fully mapped detailed business process model, integrated with our ERP, which is so rigid, you’ll never actually get it to work for a execution or contracting strategy we didn’t think of.

Your existing organizational culture might have a natural bias to one end of the spectrum, but can you really afford to stay at the extremes of the spectrum?

Striking the Right Balance: Organizational Learning in Projects, Innovation and Continuous Improvement

Some key things to consider when developing an approach to project process definition and standardization:

  • Get the basics right - Have a clear understanding of what the fundamentals of each underlying process are, and frame the right level of standardization for each layer that you apply on top.

  • Functional Excellence & Professional Integrity - Strive for best practices in each functional discipline, and give each the respect they deserve. For example, project cost engineering is not just an unimportant function that collects and reports information, but think of them as critical to structuring the project, predicting, identifying and correcting cost deviation. All functions should be encouraged to provide constructive challenge to the project manager, with everyone accountable to drive transparency and realistic forecasting.

  • Functional Interfaces (Finance, Supply Chain, etc.) - Do not allow project processes to be unduly affected by the Finance or Supply teams. Maintain the integrity of project data and find ways to meet other needs by filtering the complete project data set.

  • Third-Party Interfaces - Many major project operators work with one or more third-party contractors to plan and execute the project. Remember to select contractors who have strong internal processes, systems and people, and find the right way to integrate with them.

  • Design for Flexibility - Projects may be unique, but they can be structured and reported consistently. Understand the difference between WBS, CBS, PBS, FBS and other alternative breakdown structures to ensure the right mix of standardization in process / reporting, and flexibility to accommodate for unique project scope and execution / contracting strategy.

  • Design for Humans - Remember that your processes won’t be implemented correctly if humans can’t understand them. Be clear on expectations about what must be done, and plenty of supporting content about what could be, or should be done in certain cases. Engage your entire team in an approach to structured continuous improvement, rather than innovation for its own sake.

  • Design for Machines - Ensure that your processes are designed for the digital context we now live in. New technologies are allowing machines to interpret and act on data in exciting ways (robotic process automation, semantic AI, chatbots, etc.), and it’s worth exploring how you can apply this to your project(s).


At ProjectAI, we believe strongly in the fundamentals of portfolio and project management / control, we just find new ways to deploy processes across complex organisations, and set them up for a sustainable approach to continuous improvement. To find out more about how we do this, please contact us.

We’d love to hear more about your experiences with project processes and standardization. What has worked, and what hasn’t?