Project Management in Practice

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

Tag Archives: Methodology

Building PMO metrics

The Christmas and New Year is always a good time to take some time off the hurly burly of daily grind and reflect on how things are going. Towards the end of the year I did some work on what metrics would help us run our PMO more efficiently. Metrics are always difficult to establish, especially as they only tell a story once you have a baseline to measure against. This is probably a heavy topic for the first post of the year. Apologies for that.


While I see a pressing need for making decisions on evidence, I am also cautious against spurious interpretations of metrics, which can easily happen if taken out of context. You only have to look at statistics driven sports such as baseball or cricket where fans and officials will take diametrically opposing views of players or tactics using different statistics. Numbers are just that. What you interpret from them is what gives them meaning.

The first task was to explore what type of metrics would be useful for our business. I work for a IT professional services firm. It has unique challenges from other types of businesses. I did some research on what other similar organisations are doing. I found this compilation from OpenAir and excellent resource. There are three articles in this and the first one by Thomas Loh is by far the best. This was an excellent start. The key is not to go chasing every metric under the sun, but the ones that you need to measure. That is even more crucial when your PMO is lean and you are in the process of building its maturity. Capturing metrics and analysing them takes effort and time. You cannot afford to be spending either frivolously.

The standard metrics of utilisation, profitability, billing rate etc are quite easy to measure after the effect. We were looking at getting at least one forward looking metric that can help validate our decision making. We decided to invest in our effort in an area that is most challenging for a services business like ours – that is the pull between resource and demand.

Resource-vs-DemandIn services business you either have too much work or too many people. It is crucial to have a good handle of this to maximise profitability. The cycle of winning new business always takes time. If you have left your efforts to bring in new work too late, you will inevitably have periods of low revenue. Unlike products which you can sell at a later time and recoup some revenue, if not all, lost consulting time cannot be archived and sold. That is effectively lost.

To ensure an optimum work pipeline, we can use the charge rate to either stick to our margins, because work is plentiful or use discounting effectively to be more competitive than usual in tough market times. We want to be making a decision on them at the correct times (i.e., not stick to higher margins when market is tough or give away margins when not necessary). We are looking at using Backlog (total value of contracts yet to be executed) as a forward measurement for that.

The aim is to look at recording the backlog value three months out and updating the actuals at the end of the month. As we currently do not have a baseline, I do not expect us to be able to use this effectively in the next year. However, once we have built a picture, we should be able to predict with some confidence what it means to be at a certain point in our backlog and what that is likely to mean in terms of likely actual income.

Because we are looking at it three months out, we’re likely to have enough time to win new business to fill up the pipeline if it is looking less than promising. If pipeline is strong, we know we do not need to compromise on margins. There is likely a follow up on this topic this time next year on how this measurement plays out. Hopefully my challenge is not unique to me and the process is helpful for others to reflect on.

I am keen to understand what predictive measurements you have successfully implemented.

Image credit:

Enhanced by Zemanta

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

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.

The project management religion

I was talking to a fellow project manager today discussing how our projects are run. During the discussion it was apparent that I was speaking to someone that had very clear views on how projects should be run. So much so, that all things needed to run in a very prescribed manner.

I was intrigued at such a dogmatic nature of his management style. So I probed more about some of his reasons behind his approach. To start with, my intention was to understand if I was missing something by not following a methodology in such a strict manner. Suddenly the shutters went up and I was told in no uncertain terms that I was a discredit to my profession for having the temerity to ask questions of such nature.

The project manager I was following PRINCE2, something very close to my heart. I pointed out that one of the principles of the methodology is to tailor it to the project. That was indeed the last straw and the end of the discussion. This whole episode reminded me of people that preach religion. If you ask any questions, they look at you as if it is so obvious and you should be so grateful to receive the message. If you ask a legitimate question, they start getting defensive. If their particular argument has merit, they should be able to articulate that.

All the major religions in the world teach the same things – love for others, consideration for all, humanity, rights of people, taking care of the ill, poor and the less fortunate etc. Each have their own way of getting there. Similarly, project management practice has many methodologies. Mostly they provide similar guidance. Treat project management zealots in the same way you would treat the religious zealots. PRINCE2, PMI, agile … these are equally appropriate methodologies to meet your objectives.

Tailor the methodology to suit the project, don’t shoehorn the project to fit the methodology. That will be utter madness!

%d bloggers like this: