There are voices on LinkedIn and other outlets selling agile development, project management, and even complex adaptive systems solutions - Disciplined Agile, Scrum, which along with others are essentially a solution looking for a problem to solve.
In 2005 I wrote about the emerging issues with frameworks that first don't define the problem they are trying to solve. Those words are applicable today as they were then.
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 improvements must connect to a business benefit. But most importantly these benefits must address the identified root cause(s) of the poor performance they are supposed to be improving.
This was a struggle for the original CMM approach since there was insufficient data to show bookable benefits from applying the CMM. And this is the same issue with things like DA, SAFe, or any other software development process framework.
What's the root cause of the problem these solutions are supposedly fixing? And critically important, what are the conditions and actions creating these causes , and how specifically does the conjecture solution fix these causes that create the problems?
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 improvements must connect to a business benefit. This was a struggle for the original CMM approach since there was insufficient data to show “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, the timeframe for that payback, and the confidence level that the payback will appear in that timeframe.
We have our own maturity assessment process built around the US Department of Defense's Integrated Product and Process Development, and similar IPPD Handbooks
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, a recent 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. $5B OTB, and 27 months late.
If only it were as easy as getting compliant with Level 3 maturity and you’ll be on your way to a 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.
This program was a disaster not because of the process maturity but because the development organization knew nothing about the business domain (real-time newspaper publishing systems). The use of the maturity assessment process in the absence of a technical and business context was the road to ruin for many businesses in the early ’90s. 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 emphasize 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 PMs perform project management as a business. The same can be said of those who sell software development methods, from DSDM to DA to SAFe, to simple and, mostly simple-minded Scrum approaches
So here’s my beef – all those approaches, much like the Guide to the Project Management Body of Knowledge (PMBOK®) are targeted at a broad and amorphous community of project management or software development. A community that is likely struggling with the process of project management (PM) for sure. But solving their project management or software development problems is only a small step in getting their business back on track.
Without having definitive understanding of what Done looks like in units of measuring meaningful to the decision makers - Measures of Effectiveness and Measures of Performance as a start, and then Technical Performance Measures, Key Performance Parameters, and other measures Critical to Customer, all the process improvement frameworks are simply solutions looking for a problem to solve.
First some high-level issues…
If I look at our internal Program Performance Management guide we have basically three best practices – do you have:
- A resource-loaded schedule or product roadmap and release plan?
- Are these resources, their time frames, and sequence connected to the cost management and reporting system?
- Is there a clearly defined critical path for the high-risk activities or for agile development, a clear understanding of when specific needed Features will be delivered to meet the needed Capabilities of the business strategy?
One approach is the Software Program Managers Network has sixteen (16). Another “simple” maturity assessment from SPMN is Project Breathalyzer.
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. Here's an overview, Using Balanced Scorecard to Build a Project Focused Organization.
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 CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD/SS, V1.1, Continuous)
This will give you a flavor of how process areas are tied to business outcomes.
Last Thoughts on Processes and Their Frameworks
For anyone considering a process improvement process, search for the answer to … “how will an improvement process - measurably increase the probability of project success and the resulting business process?
Project Management and Software Development processes are enabling technologies
In the absence of:
- Identified needed Capabilities
- Good requirements
- Real markets
- Real customers
- Viable technologies
- Supportive infrastructure
- Skilled and experienced staff
- Identification and removal of the conditions and actions that create root causes improving the project management process
The result is a solution looking for a problem to solve and simply the results from the application of the process or framework, paving the cow path, on the way to not providing business improvement.
