The Project Management System Maturity Model

By: Chris Vandersluis
I wrote an earlier version of this article for Microsoft’s TechNet.  This update has been created for the EPMGuidance site.

The Project Management Maturity (PMM) model is a pretty hot topic these days.  There are waves of consultants who are making a good living helping organizations assess their “project maturity level” which is pretty much always displayed hierarchically with more mature always shown as being better than less mature.  Proponents of the concept say the PMM model shows the capabilities of an organization to manage projects.  There’s a whole conversation to be had about how organizations become more effective and I’m not sure just climbing the Project Management Maturity model necessarily gets you there.  But that is a subject for another day.  Whether you’re a fan of the PMM model or not, there is another kind of maturity model that I’ve seen with organizations who use Project Management systems.

When we work with organizations who are deploying a project management system, it’s very common to find that the desires of organization is to reap the benefits of every single element of the new system they’ve just had demonstrated by the vendor.  The client sees reports and screens and workflows and functions that they’ve only ever dreamed of and they imagine a world where all that functionality works as smoothly in their organization as it does in the sales demonstration.  It is usually unclear to the client that the demonstration data and demonstration configuration that is being demonstrated was carefully developed in order to showcase as much of the product as possible.

The client sees screens that may initiate from several sources of systems or other data   They see functionality that touches the database or the web server or other 3rd party enhancements. They might see workflow that is being driven by an installed workflow engine.  They might see  charts or dashboards that were created either by programming or with dashboard software.   The flow of data might follow a storyboard or a use-case scenario that makes understanding the potential benefits easy but understanding the underlying technology more difficult.

When we arrive to actually deliver the functionality the client is interested in, we need to temper their desires to deploy everything at once with a reality check.  The client will need to decide how they want to do business before we can even consider configuring such functionality and whether it can be delivered out of the box, with configuration or with customization effort.  There are some clients who are insistent that they deploy every aspect of the functionality they’ve envisaged and are prepared to dig in and do the design, training, learning and development of that solution as well as find the funding both in time and money to deploy it but these organizations are the exception.

What is much more common is that the client elects to deploy the aspects of their new project management system to the level that they are already comfortable with.  As the organization becomes more knowledgeable about both the system and the underlying business processes, they will demand more and more of the system; becoming more ‘mature’ as they progress.  It’s a natural progression.  As the organization’s understanding of a project management process that can be automated evolves, their demand for that automation evolves also.  This natural progression is just like the Project Management or Capability Maturity models.  Knowing that organizations will most likely evolve along these paths has made us very effective at knowing where to put our efforts in making an organization effective.  We tend to focus on those project system areas that we know have a better chance of adoption and of giving a return on the investment given the project systems maturity of the organization.  Of course no two organizations are the same so chiseling this knowledge into a tablet isn’t a good plan.  It’s just the most likely progression based on our experience with many companies.

In our experience, the natural evolution of use of a project management system comes in five basic although the sequencing of them has shifted in recent years thanks in large part to technology.  Let’s talk about the five basic areas to start with and I’ll cover some of the new shifts that we’ve seen over the last few years nearer the end of the article.

1 – Planning
We almost always 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.

2 – Tracking
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.

3 – Resource 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.

4 – Cost Management
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.

5 – Advanced
I’ll put a fifth area here for “Advanced” subjects for what might be a wide range of topics that I haven’t put in the other categories so far.  It’s not that they’re not important but that when you get to the 5th wave of evolution in an organization, it can go a lot of different ways.  So, I’ll put Risk Analysis, Document management and Automated workflows in here.  There are also advanced areas in each of the other four areas I’ve discussed so far.

Each of the elements I’ve discussed so far could be extended further and often are as the organization’s project maturity and the understanding of the automated aspect of their project management environment increases.

For Planning, the progression can go to multi-project integrated schedules with inter-project links or programme management with sub-projects.

For Tracking, the organization usually advances from simple percent complete progress which is typically the lowest quality of tracking data to remaining duration.  Tracking might also extend to timesheets to give an exact value of hours worked against the original plan by person.
In the Resources area we see going from just allocating the tasks to resources to tracking resource progress usually with a timesheet and then moving to the most requested aspect of EPM, Resource Capacity Planning.  For some organizations, Critical Chain fits in here also; merging the resource and schedule information into one advanced algorithm.

For Costs we usually see going from the basic budgeting to tracking actual costs along with hours and time to get budget vs. actual variance and from there to Earned Value tracking as is done in the Defense and Aerospace sectors.

Even the Advanced area has advanced topics.  The most popular among these are Monte Carlo Risk Analysis and integrating project management methodology (particularly in the IT sector).

Most organizations progress with all five of the basic elements from the left side of the graphic above in the order I’ve just described before turning to any of the advanced areas.  Some find that their particular project management challenge means focusing on one element ahead of others.  What is extremely difficult and rarely successful trying to be more mature than you are.
It’s very common for example, for an organization to desire Resource Capacity Planning yet when you look at the skills and experience of the organization you find that the building blocks of creating a resource capacity planning system are missing.  I often use capacity planning as an example of why knowing where you are on the Project Management Systems Maturity model is so important.  In my experience, this is the single most requested benefit from EPM systems and yet it is almost the last benefit I can deliver.  This is because resource capacity planning requires so many other elements to work first.  In order to deliver projected resource requirements vs. availability we first need:

• Project plans we can count on
• Projects tracked with accurate progress
• All tasks to be allocated to resources
• Complete and accurate resource availability
• All non-project work to be quantified and tracked
• Complete compliance by project managers and department managers on work completed, work projected and changes in resources.

Whew!  It’s no small list and the corporate culture required to comply with such an environment often requires change management on a big scale.  So, we turn back to the Project Management Systems Maturity model and clients can make a roadmap of what they need to accomplish.

This is not an exhaustive list of course.  We can easily make a 3rd column and then a 4th but I’ve not done so here because from this point the most common progression is less clear.  Each organization’s project management requirements will dictate the interest in moving forward in a particular area.
I promised earlier in the article to discuss something that has changed in the last few years.  The model I’ve described above has stood up for quite some time but in the last couple of years, movement in the IT industry has made a significant movement in another direction and that has everything to do with collaboration.

At one time in the project management software industry we were very algorithm-centric.  Everything stemmed from the critical path schedule, we thought.  In the last few years though, a few things have changed.  First of all, the availability of people through the ubiquitous Internet or telephone technology has made it even easier to assemble and communicate with your project team.  This has helped change who is on a project management team.  While once we would have thought of project team members being people deep within the organization, working in a small windowless room with desks surrounding a massive plotter, now we think of project team members throughout the organization.

Team members will include those doing the work of course but might also include the executive sponsor, the department resource managers, the users, the marketing department.  It’s now not at all uncommon to find that the project team extends not just beyond the building’s walls but well outside the organization itself to include sub-contractors, prime-contractors and even the client.  Sub-contractors may not be in the same time zone or even the same country.  All of this has made communication a key success factor for projects in many different types of industries.

That has caused some organizations in industries like R&D and IT for example to look at a Project Management Systems Maturity Model that progresses quite differently

The first element in these organizations is to create a communications plan and that’s almost always based on collaboration technology.  These organizations find that from a centralized perspective they can get more benefit from getting their extended project management team to collaborate and communicate than from any centralized planning. The meteoric rise recently in popularity of collaboration software or in-the-cloud collaboration services is a testament to how much pent up desire there is for getting people to work together.

The progression from a basic communications plan then often goes to document management one document of which might well be a project schedule.  It’s turning the classic enterprise project management progress on its head but you can see for some organizations how attractive this might be.  Get a handle on the contracts, documents, emails, meetings and other communication and efficiency increases very quickly.  Don’t get a handle on communications and the loss of efficiency might well be serious.

From document management, it’s a short step to managing issues and doing change management which for IT and R&D means managing one of the most potentially damaging aspects of a project.

Surprisingly, timesheets come next.  In fact, sometimes timesheets come even earlier.  When our organization first got started in the timesheet business with our TimeControl product, we were quite certain that who needed a timesheet like ours were those organizations which were already mature enough in their planning and tracking process to be able to take advantage of it.  You can imagine our surprise to find that many organizations want to deploy an enterprise timesheet before they deploy an enterprise project management system.  When you look at the change management challenge of each it becomes clear why.  Most users will adopt a timesheet grudgingly but quickly.  Getting a 1000 person organization to accept a centralized timesheet system takes a matter of weeks.  Getting the same 1000 users to accept a centralized project management system can take from months to a couple of years.  So, even though the centralized planning isn’t established, the organization can still get tremendous benefit from centralized timesheet data.

Finally these organizations turn their attention to the core project planning exercise.  This is not to say they haven’t been doing project scheduling so far but it won’t have been highly centralized.

Just like the first Project Management Systems Maturity Model, each of these elements can carry advanced topics too.

Communications plans often progress to more integrated communications systems including Instant Messaging, Email integration and more.

Document Management often progress to workflow management and forms integration.

Issue Management usually evolves to management of lists of all kinds and an integrated change management process

Timesheets evolve from task timesheets to links with Finance, Payroll, HR and ultimately links back to the enterprise project management system for auditable tracking data.

Planning and Resource Management tend to evolve just like my classic Project Management Systems Maturity model.

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.  What is important is knowing you have the building blocks from the basic elements before you start building something more advanced.  I’m often heard saying that we need Project Management 101 before we move to Project Management PhDs.

Remember that the use of a 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.