Project Management in Practice

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

Category Archives: Agile

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

Managing Projects Better

Where is the line between agility and chaos?


We are living in an age of social media. One where opinions are best expressed in 140 characters or less, hashtags galore and needs need to be met instantly. There is a level of agility required to work well in this environment. If an organization rigidly sticks to how business used to be done, more than likely they will be left behind by others that are willing to alter course. However, can one get into the habit of altering so much that they go around in circles? There are many misconceptions about Agile. Let us explore some of those.

Aglie is NOT Agile IS
A methodology Agile is a set of principles.

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

People have created methodologies around these principles – namely Scrum, Kanban, Extreme Programming (XP) etc.

License to dive straight into code All Agile methodologies have a significant emphasis on continually solidifying user stories. A successful delivery is judged by how closely the delivery met the user stories.
License to develop without scope User stories are the definition of scope. User stories must contain enough information for the developers to quantify a particular story “done”.
License to change your mind daily User stories are worked on continuously. More imminent a story is to be worked on; more time is spent detailing it. Adjustments to requirements are accommodated during sprint planning and treated as any other requirement, which it is being prioritised against.
License to leave half finished work floating around Most agile methodologies will restrict the number of in-flight tasks. If some of the team complete their work before others, it is their role to help others complete tasks at hand.
License to continually chop and change the team Most efficiency is gained when you arrive at a team that gels well. The sum of the capability of the team dictates the velocity at which it can operate at. Constant swapping of resources makes it near impossible to measure progress through burn-rate. One area where you expect change is in the role of the subject matter expert, based on tasks at hand.
License to pull resources mid assignment Once the sprint starts, resources are committed to getting the sprint ‘done’. It is acceptable to commit a resource to part of the sprint or a portion of the resources availability. But once committed, they see it through.
Something that only works on its own Agile is perfectly paced to be used in conjunction with other project management methodologies. For example, one can use PRINCE2 and manage by stages, where the stage boundaries represent iterations in an Agile methodology. Agile requires complete software at the end of iterations. PRINCE2 requires the ability to close a project if the business case can no longer be satisfied. Using the two together allows for tangible benefits to remain with the customer even if a project has to be cancelled.

To avoid chaos, you need a level of planning. When planning is impossible, chaos is the more likely outcome than agility.

Do procurement processes allow Agile software delivery?


Longer projects run, higher likelihood of project failure. One of the moves in recent times to reduce complexity in software development is to adopt Agile delivery approaches. The desire to build confidence and leave tangible benefits even if projects are cancelled has provided further impetus to adoption of Agile practices. This approach has delivered good outcomes for teams that work in in-house and product development teams. However, challenge remains in successful adoption Agile practices in contracted deliveries.

It is rarely the willingness of the project teams or suppliers that is the barrier, but the way organisations work. A quick review of how most organisations initiate projects will highlight this. In most organisations operational staff will identify areas of improvement. Organisations have processes to provide feedback to management to achieve this. Management then compile business case, which is then reviewed and approved by the organisation. It then moves through the procurement cycle, supplier selected and contracts agreed. These contracts are on the basis of deliverables (outputs in PRINCE2) from the project, rather than benefits.

Let us now review the consequence. The project is set up with A, B and C as deliverables. As the project starts, it becomes clear that modifying B will provide far more benefit, even if C is dropped off altogether. In an agile project, the customer is able to provide immediate feedback and the product backlog would be adjusted accordingly. Here the project team consists of suppliers who are under contract to deliver C. They cannot alter the required deliverables. The project team from within the organisation is also not authorised to make this adjustment.

As you keep moving up the organisation challenges still remain. Project governance is set up to hold people accountable for the delivery. Benefits are more difficult to quantify than outputs. Therefore the culture is usually to hold people accountable for the outputs. Modifications to business cases are usually treated as acknowledgement of omission, rather than as an evolution of the project.

So why this inertia for reviewing the deliverables in order to extract the best benefit? Consider what else the people in charge of procurement acquire for the organisation. For most things they are able to show something tangible – an air conditioning unit, an executive table, a new building. Other things they procure are services that are usually measured in time – 3 weeks of consulting. Software development is somewhere in between. You have time, the deliverable is something abstract and it is difficult to judge whether you got what you had asked for – a lot of grey areas. The people to judge is often not the ones that approve the procurement or control them. Auditing the procurement is therefore difficult terms of benefits. As a result you end up with controls on outputs.

In order to successfully embrace Agile delivery practices it is imperative that procurement and auditing methods in the organisation is geared towards measuring benefits, rather than outputs.

%d bloggers like this: