The Project Management System Maturity Model
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 Enterprise Project Management (EPM) systems.
When we work with organizations that 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 have 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 bar chart, there is certainly value in 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 that, in our experience, 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 its 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.
Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]