Most programs I work are in trouble in some form - other wise they would not have hired us to help.
One quote we use to describe these situations is
What's the difference between this program and the Boy Scouts? The Boy Scouts have adult supervision.
But today I sat through an out brief from a government auditing agency on a $10B program and one of my colleagues made this statement
This program is like a house with 4 teenage boys, where the parents went on vacation and never returned.
When we encounter these situations, it is tempting to start providing solutions. This is a serious mistake unless we have done the Root Cause Analysis of the observed problem. It may turn out what is being observed is the symptom of a root cause that was not understood by the people that hired us.
This is a rookie mistake in the process improvement business. I see it all the time. Some self-proclaimed thought leader pontificates on what is wrong with the software industry. Makes blanket statements like the current software development methods have not made much difference in the general success in the software development - the software crisis. That is according to the much debunked Standish Reports.
The charts showing software project failures, challenged or otherwise, never seem to have a root cause of the failure or less than desired performance. Same is the case with those advocating that the Cone of Uncertainty doesn't match how the work proceeds on their projects.
Why? Why are you seeing what you're seeing? What are the possible causes of these observations?
Like most voices pointing out obvious difficulties in writing software for money, without identifying the Root Cause, the proposed solutions have no basis for testing their fix will actually fix anything.
Most of the time when we come onboard to put the project back on track, we find missing processes, missing data produced from those processes, and most of the time people behaving badly. Now you could make the case that it starts with the people. Which is a noble conjecture and could possibly be true.
But the naive notion that people can operate on a non-trivial in the absence of a process is just that - naive.
One place to start is Identifying Acquisition Framing Assumptions Through Structured Deliberation
