In a previous post on How to Assure Your Project Will Fail, the notion that the current project management processes are obsolete and the phrase of dealing with complexity on projects is a popular one in the software domain. By the way that notion is untested, unreviewed, and is missing comparable examples of it working outside the specific references in the orginal paper.
But here's the simplest approach to deal with project complexity...
Don't Let The Project Get Complex
Nice platitude, It's that simple and it's that hard.
Before the nashing of teeth is heard, here's a working example of not letting the project get complex.
So how is this possible? First let's make some assumptions:
- If it is actually a complex project domain, then the value at risk is high.
- If the value at risk is high, then investing in protecting that value is worth the investment.
- This means a project governance environment is likely the right thing to do. Skimping on process is probably not the right thing. And thinking that we can get this done with a minimalist approach is probably naïve at best.
- This also means a model of the project that reveals the complexity element. Tools provide this insight and are applied regularly on complex projects.
- One final assumption. If the term complexity is used to describe the people aspects of the project - the providers of the solution and the requester of that solution - then that complexity has to be nipped in the bud on the first day.
- You simply can't allow the complexities of the people aspects to undermine the techncial, managerial, and financial aspects project.
- This is an organizational management problem and the processes to deal with it are also well defined - and most time ignored at the expense of the project's success.
- Here's a case study of how this id done Making the Impossible Possible. It's hard work, it's difficult, but doable.
Here's the steps to dealing with project complexity that have been shown to work in a variety of domains:
- Define the structure of the project in a formal manner. sysML is one language for this. This include the people, processes, and tools.
- Define the needed capabilities in units of Measures of Effectiveness (MoE):
- This means defining what business capabilities will be produced by the project and assigning measures of effectiveness for each capability.
- How do we discover these capabilities? Look at your business, project, and product strategy document. You have one right? No, then go get one.
- Start with a Balanced Scorecard for your project. Better yet have a Balanced Scorecard for your business to reveal what projects will be needed to implement that strategy at the project level.
- Here's some guidance on how to construct a Balanced Scorecard in the IT Enterprise Domain.
- Once the Strategy is in place, apply Capabilities Based Planning. Here's an approach for using Capabilities Based Planning.
- Define the order of delivery of these capabilities, guided by the strategy and business road map.
- It is straight forward. Define what capabilities are needed on what dates for the business to meet its strategic needs defined in the Balanced Scorecard.
- Don't let the notion of emergent requirements happen in the absence of defined capabilities. You have the defined needs, the defined - monetized - benefits, the Measures of Effectiveness, Measures of Performance, and Technical Performance Measures for these capabilities.
- Sure there are uncertainties - Aleatory that are protected by margins. Epistemic - protected by risk buy down processes or management reserve.
- Manage the development of the solutions through an Integrated Master Plan (IMP), Integrated Master Schedule (IMS), Systems Engineering Management Plan (SEMP), and the Continuous Risk Management process. The IMP provides:
- The strategy for delivery of the needed capabilities at the planned time and for the planned cost to meet the business goals.
- The Measures of Effectiveness (MOE) and Measures of Performance (MOP) needed to assess the fulfillment of the needed capabilities delivered to the customer.
- Technical performance is stated in Technical Performance Measures (TPM) and Key Performance Parameters (KPP) both derived from the MOE and MOP.
- The SEMP describes the what, who, when and why of the project.
- There should be a similar description from the customer stating what purpose and when the capabilities are needed.
- These two descriptions can be grouped into a Concept of Operations, a Statement of Work, a Statement of Objectives, or some similar narrative.
Let's pause here for a process check. If there is no narrative about what DONE looks like in units of measure meaningful to the decision makers (MOE, MOP, TPM, KPP) then the project participants have no way to recognize DONE other than when they run out of money and time.
This is the Yourdon definition of a Death March project. Many who use the term complexity and complex projects are actually speaking about death march projects. We're back to the fundamental problem - we let the project become complex because we don't pay attention to the processes needed to manage the project to keep it from becoming complex. Read Yourdon and the Making the Impossible Possible: Leading Extraordinary Performance - The Rocky Flats Story books to see examples of how to keep out of this condition.
- Next comes the execution of the project to produce the desired outcomes that deliver the needed capabilities.
- Detailed planning may or may not be needed. This is a domain dependent decision.
- But the naïve notion that planning is not needed, is just that naïve.
- Planning is always needed, just depends on the fidelity of the plans. Without planning chaos reigns. From the DOD 5000.02 formality to the Scrum Planning session - planning and plans are the strategy for the successful completion of the project.
- All execution processes are risk reduction processes.
- Risk Management is how adults manage projects - Tim Lister.
- If you're working on a complex project and don't have a credible Risk Management Plan you're soon going to be working on a Death March project.
- So the first step in managing in the presence of uncertainty is to enumerate those uncertainties - epistemic and aleatory - put them in a Risk Register, apply your favorite Risk Management Process, mine is SEI Continuous Risk Management, and deal directly with the chaotic nature of your project to get it under control.
- Here's a summary diagram of the CRM process.
- Finally comes the measures of progress to plan.
- The the defined capabilities, some sense of when they are needed and how much they will cost - in a probabilistic estimating manner - we can now measure progress.
- Agile likes to use the words we're delivering continuous value to our customers. Good stuff, can't go wrong with that.
- What exactly are the units of measure of that value?
- On what day do you plan to deliver those units of measure?
- Are those deliverables connected to capabilities to do business? Or are they just requirements that have been met at the User Acceptance Test (UAT) level?
- Here's an example from a health insurance enterprise system of the planned delivery of needed capabilities to meet the business strategy defined by the business owners. This is some times called value stream mapping, but it is also found in the formal Capabilities Based Planning paradigm.
The End
When hear the notion that chaos is the basis of projects in the software world - run away as fast as you can. That is the formula for failure. When failure examples are presented in support of the notion that chaos reigns and there is no actual, verifiable, tangible, correctable Root Causes listed - run away as fast as you can. Those proposing that idea have not done their home work.
But the question of dealing with complexity on projects is still open. The Black Swans, that get misused in the project domain, since the term refers to the economics and finance domain through Taleb, may still be there. There are there because the project management process have choosed to ignore them, can't afford to seek them out, or don't have enough understanding to realize they are actually there.
So if Black Swans are the source of worry on projects, you're not finished with your project management planning, controlling, and corrective actions duties as a manager. Using project complexity as the excuse for project difficulties is easy. Any one can do that.
Taking corrective actions to eliminate all but the Unknowable uncertainties? Now that's much harder.
