The Project Management Maturity (PMM) model is a pretty hot topic these days.  There are waves of consultants who can help organizations assess their “maturity level” which is pretty much always listed hierarchically with less mature being worse than more mature.  Proponents of the concept say the PMM model shows the capabilities of an organization to manage projects.  Whether you’re a fan of this assessment or not, there is another kind of maturity model that I’ve experienced personally and it has to do with the use and deployment of Project Management (EPM) systems

When we work with organizations who are deploying a project management system, it’s very common to find that the desires of the people doing the deploying is that they’ll get to enjoy every element of the new system they’ve just had demonstrated.  While there are a few showcase organizations that’ve been able to do this it’s much less common than you’d hope.

What is more likely is that there is a sequence of usage of such systems.

At the most basic level we tend to see Planning as the first wave.  Some organizations never get beyond this.  They make a basic schedule, bronze the GANTT chart then mount it on the wall of the project team’s office.  People refer to the plaque from time to time nostalgically as they remember the fine state of their schedule just before the project started.

While I’m being a bit cruel at those who are only using their expensive project management software to make a barchart, there is certainly value from doing so.  Creating an organized schedule tends to make the project participants think about how the work should be put together and is much more effective than doing nothing or just making a spreadsheet list.

Next in line in our experience is typically tracking.  An organization which is a little more “mature” in the use of their project management system will not only plan, they’ll track their schedules, advancing them on a regular basis with the progress to date and even look forward with projected schedules as the plans advance.  For many organizations, stopping here is effective.  They’re planning in their project management system then they’re working the plan by updating it regularly and even giving useful reports to management.

Once planning and tracking are handled, organizations tend to look to the resource management problem and how it might get resolved using their project management system.  Resources can have many aspects as I’ve discussed in here before but at the most basic level, resource allocation (assigning the work to resources) is a big step, followed by resource analysis of some kind. 

Cost management is the fourth typical area and many organizations never get here.  At a basic level, having a cost estimate broken down by phase or better yet by task in the project is a good costing start.  Tracking the actual costs either by hours or by dollars is the next level.

I’ll put a fifth area here for “Advanced” subjects and put Risk Analysis, Document management, automated workflows in here.  There are also advanced areas in each of the other four areas I’ve discussed so far.  If we were to diagram this the way that such things are most often diagrammed, we might end up with this:

This is the sequential kind of thinking and the problem I have with this is that it implies that level 1 is worse than level 2 and if only you could “get” to level 2 you’d have a better organization.  In fact, I think the diagram would be better represented like this:

In this kind of representation, at least we get away from the notion that each level higher is a better thing or that each block to the right is better than the block to the left.  In fact, even though I’ve described our experience that most organizations start to use their project management systems to do planning, it’s probably a good thing to imagine that they could start almost anywhere.  Some organizations could start working on resources perhaps or on risks or on document management. 

For each element I’ve described, we can also imagine more effort being put into that element to advance it further.  If we think about that for a moment, we might end up with a diagram looking something like this:

Now element that I’ve described has more depth of usage of the project system and perhaps can return more value from the system.  Planning for example, can be extended to include multi-project planning.  The algorithm for scheduling could be further extended into Critical Chain scheduling.  More detail could be added still and we could work with inter-related schedules with inter-project links.  The same goes for tracking.  If we extend beyond just percent complete, perhaps we now can look at tracking the resource usage along with the tasks.  Or perhaps we go from percent complete to remaining duration tracking which is more advanced.  From remaining duration tracking, we go to weighted milestones, something that’s often used in Earned Value calculations even when costs are not involved.

Each element can be extended further.  We could probably make a third level out from the center and then a fourth.

I think looking at the Project Management Systems Maturity model like this we can start from anywhere on the diagram.  Indeed, I’ve seen organizations not start their advanced use of their project management system in the planning area but rather in the cost area.  The organization does their planning from a cost perspective and before you know it, they’ve extended the costs section in tremendous detail yet haven’t done much with resources or risks. 

There’s no “right” way to advance in your use of your project management system or is there a “wrong” way.  As I’ve said in these columns before, what is most important is that you look first at what you need to accomplish in order to be more effective as an organization and from there design the solution to that challenge.

Use of your project management system is only one aspect of a possible solution and it’s up to you to decide how “mature” you should be and in what areas in order to make the management of your projects more effective.

It’s quite the buzz in the project management industry at the moment and it goes by the name of the “Project Management Maturity” model.  If you’re wondering if this is a relative to the IT world’s Capability Maturity Model (CMM), you need wonder no longer it’s a not-so-distant first cousin.

The idea of the PMM is that an organization’s capabilities of managing project management are assessed at a range of different levels.  There are several flavors of the model floating around but the most common iteration shows five different levels at the moment.  Labels vary but for the sake of conversation let’s number them like this: Level 1: Ad-hoc, Level 2: Planned, Level 3: Managed, Level 4, Integrated and Level 5: Sustained.  Ad-hoc is where you’d expect most organizations to be and you’d probably be right.  This means that project management occurs project-by-project in a non-standard manner.  Planned means that there is some standard for the planning aspect of project management at least but that tracking the project is done on a project-by-project  basis.  Managed would indicate that there is some normalization of how projects are both planned and tracked.  Integrated means that there is a method which brings the project management process and data together for all projects in the organization.  Sustained would mean that there is a reiterative process which would self-correct, self-improve and that the process would be self-sustaining.

I bring up the subject for two reasons.  First, there is a lot of activity in the industry at the moment doing PMM assessments, PMM implementation plans and PMM improvement projects.  So, if you’re not yet involved in such an initiative, you might expect to be soon.  The second reason is a little less obvious.  It seems that one automatically accepted aspect of this whole concept is that it is, of course, better to be higher on the scale.  I’ve been in meetings recently where this 5-level chart is put on the wall and a senior executive is informed that an assessment of the organization has determined that it is at, for example,  level 2.5.  You might just as well wave a red flag in front of a bull.  “Why aren’t we at level 5?!” the executive demands.  “I want to see a plan to get us to level 3 as soon as possible!”  Why?  Because 5 is obviously better than 1. 

It’s worthwhile to note that you can make a case for any one of these levels being appropriate for any particular organization.  We spend a lot of time talking to people about enterprise-wide project management in our firm but epm simply isn’t appropriate for some companies. 

You’ve always got to think of the overall return on investment.  In some organizations, the difficulty in implementing the culture change required to do epm outweighs the potential benefits.  In others, the shear diversity of the types of projects managed means that epm doesn’t return much investment at all.

For some of these organizations, being at a level 3, 2, or even 1 will be the most effective choice.

So, if you’re doing a PMM assessment at the moment, by all means, continue.  It’s always good to know where you stand and introspection almost always returns good value.  But, before you jump on the bandwagon to see how high up the PMM ladder you can get, make sure that the benefits are there.

Article: Integrated PM System and the Project Maturity Model
With the release of Microsoft Project Server originally in 2002, Microsoft catapulted itself from the ranks of individual project management software provider to organizational or enterprise provider.  How does EPM software like Project Server affect an organization’s score in the Project Management Maturity Model?