Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Category Archives: PRINCE2

How good are we at lessons learned?


We as human beings have the incomprehensible ability to make the same mistakes over and again. You have to take a glance at history to see the same pattern repeat itself – a nation is enlightened, makes rapid progress, gets intolerant and starts to impose itself, loses its hold and goes back to the pack. Chinese, Persians, Romans, Greeks, Ottomans and Arabs – all had a go. In recent times Great Britain and the United States. It is therefore not surprising that we do the same with projects.

Lessons Learned

One of the PRINCE2 principles is to learn from previous lessons. Good in theory. How well is it done? Not very well in my view. Lessons learned is something that is left to the end of the project in my experience. On any sizeable project, the project team should be implementing lessons learned as they go. Lessons learned is not only for not repeating the mistakes of one project in another, it is also to ensure mistakes of one task in the project is not repeated in another.

The difficulty of recording lessons learned is very similar to that of benefits realisation in a project. By the time people have some ability to look into that, the project is completed, and attention has shifted to the next project, or towards embedding the products of the project into the organisation. Keeping focus to ensure this is captured takes a lot of discipline. Standard practices are also required for capturing lessons and reviewing those at the initiation stage of any projects. Otherwise, the lessons are not worth the paper (or disk space) they are captured on!

What things should you capture as part of lessons learned? The first and foremost thing you must capture is your estimated effort versus actual time spent. Estimation is an inexact science. Projects by nature are risky and whatever methodology you use to estimate, it is a matter of continually refining those. The bare numbers are not sufficient. You must analyse what led to those numbers. You may have estimated high, but because of scope creep you may have come on budget. Was that success or failure?

A second thing I recommend is the identification or risks. Were there issues which were not identified as risks at the outset? If not, what led to those issues? How could they be identified better in future? Where issues were identified as risks at the outset, review the risk responses. Were they appropriate? Were the likelihood, impact and proximity identified correctly? If not, try and analyse how it could be done better.

I would also look to see if the project methodology was tailored to suit the project and the organisation. Many organisations think using a methodology like PRINCE2 will ensure success. Without the appropriate tailoring, methodologies are doomed to failure. It is not the methodology that brings success, it is the people that understand the principles and ask the right questions that make the difference.

These are by no means an exclusive list. In many ways you should look to evaluate each of the six tolerances that the organisation affords a project manager – time, cost, scope, risk, quality and benefits. The three above are the most common causes of repeat mistakes from my experience.

Image Credit: Ryan Renfrew

PMBOK or PRINCE2 … which one is better?


I often see debates on project management forums on LinkedIn, blogs and even at the water cooler around the office regarding what project management methodology is best. I have often wondered about the wisdom of such discussions. The two that are always compared are PMBOK (Project Management Body of Knowledge) and PRINCE2 (Projects in Controlled Environments Version 2 – 2009). One such discussion with a fellow professional led me to have a little bit of a think.

PMBOK Process Model – Credit: PMI

I will declare my hand at the outset. I have squarely gone for certification route through the Cabinet Office products for project, programme and service management (PRINCE2, MSP and ITIL). This is not necessarily because I was convinced these were the best frameworks, but my assessment of what the market around me considered more valuable. With the Australasian market following that of the United Kingdom and Europe, it made more sense for me to pursue this line, than the PMBOK based certifications from the Project Management Institute (PMI) in PMP and PgMP.

PRINCE2 Process Model – Credit: ILX

Genesis of PMBOK is in the engineering sector in North America. I can see that has led to significant emphasis on the tools and techniques of how to manage projects. I find it has excellent guidance in what it calls the knowledge areas. For example, it provides techniques for monitoring and controlling projects through Earned Value Analysis (EVA), estimation through the Program Evaluation and Review Technique (PERT) analysis. It elaborates on Precedence Diagramming Method (PDM) to identify sequencing and various lag options. It has tools and techniques for scheduling using Schedule Network Analysis, Critical Path and Critical Chain, discusses Resource Levelling and What-if Scenario Analysis. Tools and techniques is where PMBOK has it all over PRINCE2, which goes very little into the skills required to be a project manager.

PRINCE2 began with a desire to control capital IT projects in the United Kingdom. Interestingly, a methodology that began in such a technical sphere has very little in the form of guidance through tools and techniques. PRINCE2 is very strong on project governance. Its strength is in the focus on the continued business justification through a living Business Case. In managing by exceptions, it removes the temptation for death by project reports, but at the same time provides a mechanism for escalating when necessary. In managing by stages, it builds in regular reviews of whether the business case the project is trying to deliver to be still valid. The biggest outcome of this is the assertion that a project unlikely to deliver to business case is better cancelled than meandering along. Project structure and principles also ensure projects are delivering to strategic initiatives of the organisation.

I have previously posted about the challenge in implementing PRINCE2 as the project framework for supplier organisations. I have used the principles rather than exact implementation as described in the text. It is much easier to take the PMBOK tools and techniques and implement directly into your projects in a supplier context. PRINCE2 however does a better job of risk identification and management techniques with the various response options and planning. There are also pros and cons about the accreditation methods. PRINCE2 is often criticised for allowing potential non-practitioners to get certified because of its examination only method. In order to get a PMP accreditation, you have to go through a significant effort to prove hours under the belt. That is a good idea. But you have to accumulate Professional Development Units (PDU) to stay current. I have seen plenty of mickey mouse outfits dispensing PDUs like confetti to have any meaning to these.

When I consider all of this, it appears a futile argument from those in either camp. In my view the best option is to use PRINCE2 to understand “how” to run the project and PMBOK for guidance on “what” to do in the specific scenarios. The question is not one of PMBOK or PRINCE2, but how to use both in your projects.

How do I tailor PRINCE2 to deliver IT projects?


I had been reflecting on a comment Geoff Rankins made at a previous PRINCE2 User Group Meeting regarding most IT projects not delivering the stated benefits. I have concluded that I agree. Most of the business cases for these projects are put up by the IT departments and vastly overstate the benefits to get those approved. Some even go to the extent of hiding the cost in operational budgets, so they don’t have to put up a business case in the first place! The consequence is those benefits can never really be measured or met. IT is not the core business of most organisations. I don’t think many of us in the IT profession have quite grasped it. It exists to provide an answer to a business question. Therefore, IT should not be putting up business cases. Their role should be to be the subject matter experts that advise the business in how they can enable capabilities.

From my perspective, delivering IT projects, there are two significant gaps in PRINCE2. One the text readily acknowledges is the lack of guidance around specialist areas like IT. It is interesting given the genesis of PRINCE2 was to control capital it projects in the UK. The second is in transitioning the outputs into the business. Of the cabinet office products, MSP has the best guidance around transition, but what if your project is not part of a programme? Many it projects aren’t.

Now let’s consider the environment in which the projects are usually delivered. Rarely will a project be delivered in a Greenfield environment. Most organizations today will either have an infrastructure or existing capability of some manner. They have a framework for delivering to their business. More and more the best practice framework used is ITIL.

The process that wraps around service design, transition and operation in ITIL is the continuous service improvement process. This is responsible for measurement of existing services to identify areas of improvement to deliver maximum value. This is the crucial link to connect a service management framework like ITIL to a project management framework like PRINCE2. The organization has already put a value to having this service available to them. Tying this improvement process to business cases ensures what makes sense technically also makes sense strategically.

In a real life example … a software that is used by an organization was about to become unsupported. It was flagged as something needing upgrade. But the organization was thinking about changing business processes that would no longer require that software. The IT team had moved the cost of this upgrade into operational budget, so they wouldn’t have to go through a business case for it! What was the consequence? They upgraded the system, delivered within budget and time, but discontinued it in less than 4 months! Was this a successful project?

Paradigm is shifting in the way IT delivers to the business. Cloud is becoming a realistic option for many services, applications and even infrastructure delivery. The advantage of this approach is a known risk pattern and the level of elasticity it gives you. The fact that you can scale to demand and not have to design for peaks, are good ingredients for success. Custom development therefore should be the exception, rather than the norm. It is somewhat ironic coming from someone that started his career as a software developer.

There will be times when you will have to build custom systems. Either due to legislation, or simply the problem is unique. In my experience, software development is part science … we’re building machine instructions, part art … designing user interfaces for example … and part voodoo. The problem the customer explains, the BA understands, the developer codes … are often coloured by their interpretation of the problem. It is the role of the project manager to ensure the language isn’t muddled. This is where I have found agile practices very useful.

Agile methods allow for quick feedback cycles – starting early and often. The biggest benefit I have found is stopping unnecessary features being developed – all developers are guilty of that, trust me. It also ensures what is delivered does not come as a surprise to the customer. Agile requires delivery of working software at the end of each iteration. Lining iteration boundaries coincide with management stage boundaries will ensure if it is ever determined that the project is unlikely to deliver the desired benefits and is cancelled; the customer is left with the latest working product.

The model I strived to establish in projects is Continuous Service Improvement forming the basis for startup activities, using the service design principles during initiation as you define you product description, use agile practices to build the product and use transition processes to deploy to the organization and finally as part of closure to establish the operational practices so a new cycle of service improvement activities can begin.

I want to end by sharing a statistic from Keith Ellis of IAG consulting … only 1 in 3 software projects make it to completion in the United States. That is the good bit. Of the ones that do, 85% are late and over budget. Traditional project centric thinking has a lot to answer for in IT project failures. We must tailor PRINCE2 in context of the delivery environment and project challenges. Frameworks like ITIL; practices like agile can help us achieve that.

What methodology do I use?


There are a plethora of project management methodologies out there. Each have their own strengths and weaknesses. How do we choose what is right for our environment? I am presenting to a peer forum of Project Managers. This is a draft of my thoughts. The full blog post can be read here.

Prince2 ITIL Agile … what is best for me?

View more PowerPoint from Shoaib Ahmed
%d bloggers like this: