There is a short eBook titled Dealing with Complexity in Software Projects that can be downloaded by clicking on the image to the left.
This book starts with the hypothesis put forth by Theory of Project Management: Explanation of Novel Methods, in which it is conjectured that traditional project management processes are now obsolete and new project management processes are needed. Agile of course is one of those suggested.
This theory is the basis of a product, Last Planner used in the construction business.
There are some fundamental flaws starting on page 1 of the eBook, where it is asserted Project Management can be divided into main components:
- Theory of Projects - why are projects important?
- Theory of Management - how are projects managed?
The first is nearly universal, projects are the basis of most business processes, other than production and even then, projects are used to establish the production processes. The second part is domain dependent. In the eBook, it is conjectured that the view of projects rests on the assumptions listed in the orginal paper:
- Tasks are independent, except for their sequential relationships.
- Tasks are concrete, with start and end dates.
- There is very little uncertainty regarding requirements and the tasks themselves.
- All work is possible to capture in a top-down breakdown of the total transformation.
- All requirements exist at the start and they can be decomposed just like the tasks.
First let's look at these assumptions from a theory testing point of view. If these assumptions are found to be flawed, then what follows in terms of seeking new ways, may be based on unfounded assertions.
- Assumption 1: Tasks are Independent
- Only if the work is not developing a connected and interoperable system made of of other system elements. That is the work is an assembly of parts with no interactions between the parts other than at their interfaces.
- This is rarely the case in software, hardware, people, or systems-of-systems.
- This would mean there are only linear connections between the work elements. No merge points or branch points in the sequence of work.
- Traditional project management processes deal with these merge and branch points through the technical and programmatic architecture of the project. The network of planned work has many to one and one to many connections throughout the project.
- Traditional project management processes deal with this quite well, starting with Capabilities Based Planning, moving to Integrated Master Planning, Integrated Master Scheduling, and then the establishment of the risk adjusted Performance Measurement Baseline.
- Assumption 2: Tasks are Concrete
- Only if you are pouring concrete or welding pipe, as the original paper suggests projects they are interested in do.
- If the components of the project being integrated have dynamic behaviours, modern project management methods deal with those through Interface Control Documents, that define both the static and dynamic behaviours of the component. This is the basis of object oriented programming, systems engineering, and most importantly the systems-of-systems approach take by modern project management methods.
- These interactions are modeled in tools based on sysML. CORE and CRADLE are two I use.
- The complex behaviours of these interfaces can be modeled. Their dynamic behaviours revealed along with the static - architecture. We use DoDAF as our starting point for architecture. The coupling and cohesion exposed by the tools and the model and most importantly the inter-dependencies documented through another tool - Design Structure Matrix.
- Assumption 3: There is Very Little Uncertainty
- This is not only naïve, it is wrong. Or perhaps better stated Pauli's quote, "Das ist nicht nur nicht richtig, es ist nicht einmal falsch!" - "It is not only not right, it is not even wrong,"
- All variables on projects are random variables, generated from the underlying statistical processes for cost, schedule, and technical performance.
- These variables are drawn from two classes of uncertainty.
- Reducible uncertainty (epistemic) - which can be reduced with time and money to protect the project from their impact.
- Irreducible uncertainty (aleatory) - which can not be reduced, so margin is need to protect the project from their impact.
- Modeling this combined uncertainty can start with Monte Carlo Simulation of that non-linear, non-stationary, stochastic network of work activities called the Integrated Master Schedule.
- Assumption 4: Work can be Captured Top-Down
- In practice, Capabilities can be defined top down and assessed by Measures of Effectiveness and Measures of Performance.
- These capabilities reveal the needed requirements in the upcoming capability release plan. This incremental and iterative process is the basis of DOD and NASA programs, so it should be straightforward for complex software projects to apply this as well.
- Assumption 5: All Requirements Exist At Start - is naïve at best and not factual at worst. These Program Management Handbooks show how to elicit requirements incrementally in an evolutionary manner:
- Capabilities Based Planning does not assume this
- DOD 5000.02 does not assume this
- NASA NPR 7120.5E does not assume
- You get it, requirements are avaiable up front is a veryt bad assumption.
So Now What?
With the basis for seeking a new and innovative project management process grounded in assumptions that are not actually correct, is there any reason to continue reading the eBook?
Yes, for one simple reason. To put into perspective the notion of chaos as the basis of any credible probability calculaton for the success of a project.
Let's review the assumptions that are suggested as the reason to abandon the current project management approach and move to something else.
- Tasks are Independent — no they're not. They're independent in only the simplest of projects. Dependencies are everywhere. And not just dependencies on logic, but also cost and technical performance. Projects are collections of interdependent networks of non-linear, non-stationary, stochastic processes.
- Tasks are Concrete — only if you're pouring concrete. Any nontrivial engineering development program has emerging and evolving drivers of cost, schedule, and technology.
- There is Little Uncertainty - a colleague has a saying the project and its plan is a complex situation adapting to an emerging solution. Behave accordingly.
- Work Can Be Captured Top Down — this would require clairvoyance and precognition on the parts of the project participants.
- All Requirements Exist At The Start — same clairvoyance and precognition needed.
Next
These assumptions — wrongly described — are then challanged by the Agile Communities approach.
- In Agile Software development we assume that requirements are not knowm in full at the start, and we further assume that they will change during the project.
- We assume that tasks have some sequence, but that the sequence should follow our beliefs regarding the value of each requirements or tasks, and not a possible work-sequence.
- We assume that the number of requirements will grow as we understand better the problem space, and that we will find novel ways to execute the initial requirements as we understand better how the software system behaves when in use by actual users.
Let's start with a framework, well developed in many domans - Capabilities Based Planning. In this framework, we don't start with the requirements. We start with the needed capabilities that will result from the project's outcomes. Let's look at the challanges above in light of Capabilities Based Planning.
- In Agile Software development we assume that requirements are not knowm in full at the start, and we further assume that tehy will change during the project.
- With capabilities, we can develop the needed requirements to implement the capabilities for the release of those capabilities to the production environment.
- In the above example, Demo Conversion Process, Member Reconciliation is a capabilities that can be put to work.
- With this capability we can start the next one. Integration of ERP Converted to Inventory
- The result addressed the emerging requirements issue, by freezing the capabilities long enough to produce a capability that can be put to work and start genertaing the planned value.
- If the requirements are emerging as we are developing, we'll never reach DONE on the planned day for the planned cost.
- We assume that tasks have some sequence, but that the sequence should follow our beliefs regarding the value of each requirements or tasks, and not a possible work-sequence.
- For the needed capabilities to show up on time, for the planned cost and the planned benefits, we will need to have a plan to perform the work in the right order.
- We assume that the number of requirements will grow as we understand better the problem space, and that we will find novel ways to execute the initial requirements as we understand better how the software system behaves when in use by actual users.
- The number may grow over time. But during the freeze period needed to produce the planned capabilities, on the planned date, for the planned cost, they had better be stable.
- Otherwise we have a death march project. One that can never seem to get to DONE, because we keep changing what DONE looks like
The End
Projects have lots of problems - symptoms actually - with root causes. But with the assumptions that are the basis of the paper and the eBook, one primary root cause is simple ...
BAD PROJECT MANAGEMENT
So do we move on to the next project management method before to assess the root causes of the current symptoms, fix the root causes and reassess if the current method has shortcomings? Let's hope not.
Here's the Principles, Practices, and Processes needed to increase the probability of project success. Apply these first, see if they are found wanting for the domain you work in. If so, assess then before abandoning them for others that must first be tested to improve the probability of success before jumping on that band wagon.
- Buy Beyond the Hype: Rediscovering the Essence of Management, Robert G. Eccles and Nitin Nohria, Harvard Business School. Read it and then ask the questions developed in the book to separate hype from Bad Management fixes.
- Take the contents of the briefing above and see if you can find the Principles, Practices, and Processes on your own project? If not, you may want to install them first before following the pided piper of the next new thing.
