Some Thoughts on Project Management
Organizational Maturity Models
Maturity Models have been around for some time. There is the well known Capability Maturity Model of the Software Engineering Institute (CMM), a building Architecture Maturity Model, an Enterprise Architecture (EA) Maturity Model, an Acquisition Maturity Model, many business process maturity models and – The Project Management Institute's (PMI®) Organizational Project Management Maturity Model OPM3™.
The basic idea of a maturity model is to assess work process practices (development, management, design, manufacturing, customer service, any repetitive process) against a “norm” and identify areas of possible improvement. These improvement must connect to a business benefit. This was a struggle for the original CMM approach, since there was insufficient data to show a “bookable saves.” At this point in my career (late by many standards), I’ve become jaded to process improvement initiatives that don’t come with built in business benefit models. Even more so for models built around commercial approaches. Over the years, the idea of maturity assessment has become the means of identifying risks, focusing management on improvement and identifying areas of business payback. We have our own “maturity” assessment process built around the US Department of Defense's Integrated Product and Process Development.
OPM3 and Market Need
So along comes PMI® with its generic process assessment tool. Much has been written about OPM3®. There is an underlying assumption here. “Greater process maturity leads to better project outcomes.” If this were actually the case, my current employer’s “poster child” project failure would likely have been avoided. A very mature program management process is in place, but OTB (Over target budget) and OTS (over target schedule) indices in the 1000’s of percent are the norm. If only it were as easy as “get compliant with Level 3 maturity and you’ll be on your way to better project.”
This was the approach of early non-defense users of SEI CMM. Level 3 and even Level 5 maturity compliance was used as selection criteria for IT developers and system integrators. I personally led the recovery effort for a failed project that succumbed to the siren songs of “we’re CMM Level 5 ” selection process for an offshore development project. It was a disaster not because of the process maturity but because the development organization knew nothing about the business domain (realtime newspaper publishing systems). The use of maturity assessment process in the absence of a technical and business context was the road to ruin for many businesses in the early 90’s. They have since “grow up” about maturity models – with CMMI replacing CMM.
So what’s the problem with OPM3®? First, do we need another maturity assessment process? Especially one based on commercial interests? SEI CMMI has a very nice sub-section for project management. But most importantly – and I can’t emphasis this enough – CMMI (and similar models) have a business context beyond project management. This includes requirements, quality and procurement. Below is a “relationship” diagram for the various elements of CMMI-System Engineering.
This picture illustrates the complexities of a maturity model in a mature business domain (system engineering). To show that the quest for Project Management as a “leading” process is misguided at best. Project Management is an enabling process, not a strategic process. Very few firms “manage projects for money.” Projects are managed as part of the delivery of products or services. I’ve worked for “project delivery services” firms, but in the end we built roads, decommissioned nuclear weapons plants, deployed telecommunications infrastructure and managed large ERP systems. Project management was performed, but it was always a secondary process. PM consultants, those who sell PM software, or those who train PM’s perform project management “as a business.”
General Purpose Solutions
So here’s my beef – OPM3®, much like the Guide to the Project Management Body of Knowledge (PMBOK®) is targeted at a broad and amorphous community of “project management.” A community that is likely struggling with the process of project management (PM) for sure. But solving their project management problems is only a small step in getting their business back on track.
First some high level issues…
“OPM3® defines 586 best practices,” says John Schlichter in a PMFORUM posting. My first reaction is “My God in Heaven, I thought CMM had too many dimensions.” 586 best practices is quite frankly a ridiculously large number. If I look at our internal Program Performance Management guide we have basically three best practices – do you have a resource loaded schedule, are these resources, their time frames, and sequence electronically connected to the cost management and reporting system, is there a clearly defined critical path for the high risk activities. The Software Program Managers Network has sixteen (16), http://www.spmn.com/16CSP.html Another “simple” maturity assessment from SPMN is the Project Breathalyzer, http://www.niwotridge.com/PDFs/Project Breathalyzer.pdf Both these have served well in large and complex project management environments.
The “organizational” part of OPM3® needs to be separated from the “project management” and the “maturity model” parts. These are three separate and distinct activities. Let me explain.
Organizational Improvements
Balanced Scorecard is a popular method for defining, directing and assessing business strategy.
http://www.niwotridge.com/PDFs/UsingBSCtoBuildProjectFocusedOrg.pdf
discussed one example. This is a large file (1.2MB) so hopefully you have
a broad band.
Project Management Improvements
Having a project or program management handbook is a useful starting place. But understanding how to manage projects is even better. SPMN is one example for software based systems. CMMI is another. Even PMBOK, (wince) - but the DoD PMBOK, is probably a better place since it has working examples of the process areas more in tune with a linear baseline set of processes.
Maturity Models
Having 500 or so best practices areas is probably NOT the place to start. For those in the software or IT business CMMI-SE/SE/IPPD should be looked at http://www.sei.cmu.edu/cmmi/models/models.html This will give you a flavor of how process areas are tied to business outcomes.
Last Thoughts on OPM3®
For anyone considering a process improvement process, search for the answer to … “how will an improvement process – in this case OPM3® - measurably impact my business process? Project Management processes are an enabling technologies. In the absence of good requirements, real markets, real customers, viable technologies, supportive infrastructure and skilled and experienced staff, improving the project management process is simply “paving the cow path,” on the way to business improvement.