Sign in
  • Blog
  • Processes
  • Project management

Author  Steven Deneir – PPM coach, trainer and consultant, owner of be.Projectized

February 26, 2016 |

 4 min read

  • Blog
  • Processes
  • Project management

The principal objective for a project – delivering a specific output – can often be relegated to a focus on standardization. And very often this standardization of the project management processes boils down to completing a set of project templates. I’ve seen this happen very often, even while the project is, simultaneously, running over budget by over 300%.

But why standardize processes at all? I understand companies have good reasons. A reason is often that the many project managers in an organization all use their own methods, resulting in various approaches, formats, timings, naming, etc. In itself this is not a bad thing, as long as the projects deliver. This risk is about misunderstandings between the different project stakeholders resulting in a lot of wasted time – often for senior managers – in understanding each project’s status correctly.

So we agree there is a need for standardization of the project management processes. Next question is how far this standardization needs to go?

I have worked for a customer that insisted in having a detailed step-by-step procedure for estimating a work package. The reason given for this was to achieve level x in maturity framework y (which is by the way a big misunderstanding of the use of maturity frameworks). The procedure was useless, and it didn’t support the maturity assessment at all.

What is important though is that each organization:

  1. Determines the key performance indicators for any process and provides support to reach or improve these indicators
  2. Defines the key decision points in any process or project and what information is to be available at those moments.

These points indicate the expected level of detail in the process standardization and where to support the teams executing these processes.

While more detailed procedures allow an organization to list the expected activities to be performed, and templates allow an organization to list the expected information to become available, checklists allow a combination of both and moreover allow additional attention points.

Three office workers sat reviewing documents

Take, for example, the key decision point in a project: Approve Project after Initiation. A checklist could list the different expected activities such as Develop Detailed Business Case, Develop Project Plan, etc. It could also list the expected deliverables such as the Project Initiation Documentation, the Benefits Review Plan, etc.

But, more interestingly, it could also align upfront the market situation with the Project Executive and Senior Uses while drafting the Business Case, or identify Business Ambassadors and get them involved to facilitate the change afterwards.

Yes, you could see these as activities or information to be shared. The main difference compared to a process description is the use of checklists should not be long winded procedures that are never read anyway, or templates that are just completed because they exist but their purpose is unclear. Checklists are really useful tools that with a quick run through indicate whether this part of the project is successfully completed and can go to the Project Board for approval.

You can develop checklists for any important project step - before starting the project, at initiation, before each each stage and at closing. The use of Health Checks in PRINCE2® enables project managers to start using a checklist approach for the PRINCE2 processes instead of going through the entire best practice manual every single time to be sure you have not overlooked something.

A big advantage of checklists is that they allow greater project agility. Any point on the checklist should be written so that it allows flexibility in the way to achieve the expected result. Your customers are surely looking for a more agile approach, which means having a lesser focus on detailed processes and templates, but supporting greater flexibility and innovation among the project management team.

A final, but an important point: maintain your checklists! You’ve certainly heard about lessons being captured at the end of projects – although they should also be captured throughout the project itself. You might want to turn this into action and improve your Checklists in light of experience.

So, keep learning from experience and check off that the learning is applied.

See our PRINCE2 section for more information about project management.

More Axelos Blog Posts from Steven Denier

My CPD Life

The top myths about PRINCE2® and agile methods.