How to keep a PRINCE2 project lean?

Question

I gathered some project management experience (I consider myself an advanced beginner) and some time ago I attended the PRINCE2 courses successfully. Now I'd like to conduct my next project using PRINCE2. In PRINCE2 terms it is a normal project with medium risk, commercial supplier-customer relations and multiple locations. Now that I am planning the project in more detail I see an overwhelming lot of activities to be done and my boss and I fear using PRINCE2 will introduce a lot of unneeded organisational overhead. How do you, experienced practitioners, handle this and keep your projects lean?

Answer 1

I qualified in PRINCE2 long before I moved into the Agile arena and became a ScrumMaster / Agile Coach so I have seen both sides of the coin and understand how hard it can be to;

• Gain a PRINCE2 based answer from the PM SE community
• Divorce the the actual intent of PRINCE2 from the taught syllabus

I will be brief and simply say that

Remember exactly what the PRINCE2 guide calls for...

You colleagues and stakeholders will consider meetings, reports and paperwork as evidence of progress however PRINCE2 does not mandate these things in the Principles.

It calls for

Continued Business Justification

This means to review your product offering frequently. Agile practitioners would immediately recognize this as periodic reviews. The easiest way is to physically demo the product. Not show the plans, not show the intent of the product but physically demo the product. That lets you show stakeholders that a working product is the priority they should expect that any artifact they request (logs, reports etc) should be to support the idea of a working product.

Demonstrate progress in your product so that you can...

Manage By Exception

This means that you have to have the courage to sit back and shepherd the process rather than control every aspect. Depending on your delivery that can be challenging because stakeholders have differing ideas of what a project manager does. Agile practitioners would recognize this as the daily standup or huddle or check-in which is limited to 15 minutes normally. The project team comes together to verbally confirm what they are working on today, what they focussed on yesterday and what impediments they need you to remove. More than 30 minutes is a complete waste of people's time.

You shepherd rather than control so that you can...

Learn from Experience

By conducting frequent post-mortems of your progress you can take action to correct poor working practices, remove impediments and support the team with addiitional resource or materials they might need. In Agile terminology we would refer to this as the Retrospective which is conducted weekly, fortnightly or monthly.

All of this helps you

Manage a Stage

Agilists would recognize this trough such mantra's as Managing WIP (Work in Progress), reducing bottlenecks, improving flow etc. Your job, ultimately is to try and protect your project resource and given them an environment set up for success.

Very rarely does an environment benefit from additional ceremonies or increased paper artifacts. You will get just as much information from buying a coffee for a team member and asking him/her what is going on as you would from calling an "update meeting". Except you saved 8 other people from having their diaries crashed.

Remember always that PRINCE2 does not call for meetings and reports; it calls for information and updates and these can take many forms which you decide in such a way as to not burden your team with heavy process.

Is it enough for a project engineer to simply confirm to you verbally they are progressing with a task? That is an update.

Miscellaneous advice

My advice to you, given your environment, would be that your stakeholders are going to expect certain artifacts that are likely to be unavoidable

• Risk Log
• Gantt Chart

These things are anathema to Agile because we account for risk management in a different way and our plan is contained in the priority of the backlog and possibly, a roadmap.

Gantt Chart

If you must do a Gantt chart, do one. But brush up on the cone of uncertainty and ensure that it is only granular out to 6 weeks. Anything beyond that should be big building blocks otherwise you are setting yourself up to fail.

Risk Logs

As someone who completed 10 years in the intelligence community conducting Risk Management around the globe; trust me when I say the easiest most effective way of running is a risk log is the four T's model.

For every risk you identify, write a short description and label it

• Treat (take mediating action to stop the risk)
• Terminate (remove the risk entirely)
• Tolerate (simply live with it and react if it occurs)
• Transfer (tell a higher authority it is their risk now - the best one!)

That's it. Decide what you want to do and keep it up to date to show auditors and or the Steering Commitee / Gatekeepers. To maintain the validity, simply ask the project team

If this was going to be delayed in any way, what might delay it?

Whatever they say, write it on the risk log and give it an appropriate T.

In summary

• Remember the principles and live by them
• Decide if you need reports/meetings or simply information/updates
• Keep your risk log lightweight
• Don#t hang yourself or devote too much time to a Gantt chart. It will be redundant as soon as you publish it so keep your time on it to less than 5% of your effort.
• Remove impediments for your team
• If you are constantly busy it indicates the project has problems or you are being micro-managed

Final Thoughts

When you get to the gate checkpoint for more funding; push strongly on why the gate needs all of the evidence they are asking for. But don't push too strongly; a fired Project Manager cannot help anyone including themself.

If you have any pointed questions; you can always come back to this community.