“Common Project Risks and Agile Mitigations, Part 3, Planning & Estimation” from an Old Blog
Many years ago, I had a blog where I commented on a number of things related to software process largely with an agile-related slant. I got directed to that blog a couple days ago and I thought I might present them here and see what people think. I have not updated them in any serious fashion because I am happy to have them criticized in the light of current thinking.
So, from October of 2009 here is the twenty-sixth:
Part 2 covered issues related to requirements as the number one issue plaguing projects. This part will address two of the next most frequently mentioned category of issues that can lead to project failure: planning and estimation. Planning was the next most frequently mentioned category, but estimation, which is highly related to planning, was also high on the list. Therefore, these two have been combined to be discussed together.
Planning & Estimation Related Issues
As with requirements, the fact that planning is a problem area should come as no surprise. Making plans, getting agreement to them, managing the project using the plan, and making changes to a plan all involve substantial effort. Later, project management will be discussed. But, for this post, the focus will be on creating a plan.
The particular issues related to plan creation/initiation mentioned in the various survey sources include:
- Allowing a plan to diverge from project reality, or to be created which diverges from that reality in the first place, due to lack of estimation experience, estimation under pressure, rejection of reasonable estimates (usually resulting in underestimation), ignoring the obvious (e.g., back-of-the-envelope calculations), and/or not revising plans if scope changes.
- Failure to plan, adequately or at all, to consider all project activities, to address risk management, or to inadequately document decisions and commitments (leading to later disagreements, disappointments, and costly rework).
- Infrequent project milestones (i.e., project “chunks” too large), allowing too much time to elapse between opportunities to validate that work done meets intended needs.
A telling comment from Watts Humphrey (as quoted in [May]) is that “any plan [project managers] put together won’t meet the [desired release] date, so they can’t plan.” Additionally, May asks states, “It is unfair to call a project a failure if it fails to meet budget and schedule goals that were inherently unattainable. Attempts to circumvent a project’s natural minimum limits will backfire. This problem occurs any time someone ‘makes up a number and won’t listen to anyone about how long other projects took,’ said Capers Jones.”
There are also famous quotes (mostly from the military) about planning and what happens when plans start to be executed such as “a battleplan never survives contact with the enemy” and “plans are not important, but planning is everything.” Interestingly, the formality, rigor, and hierarchical control structure of the military is classic, but the military also realizes how important it is for the people on the front lines to be prepared to inspect and adapt. Remember Clint Eastwood’s comment as Gunny Highway in “Heartbreak Ridge” regarding plans and response to situations in the field: “Improvise. Adapt. Overcome.”
Applicable Agile Values and Principles
As with the requirements category, most of the Values and Principles also seem to apply to planning and estimation.
The key in Agile-based planning (as with requirements specification) is simplicity born of close collaboration with the stakeholder(s) and frequent validation that work is meeting needs. Because of the iterative and incremental nature of an Agile approach, detail is reserved for the near-term with progressively less detail the further out the planning goes. This approach is taken to reduce the initial cost of detailed plans which, in all likelihood, will be changing anyway.
Because of this willingness to change plans if stakeholder needs and priorities change, Agile planning (and validation of the planning), as an activity, occurs frequently (i.e., daily, every few weeks). In this way, the plan will not diverge far from reality, can be adapted easily when changes occur, and will not consume significant effort to maintain. Most importantly, all planning is based on the regular, frequent delivery of working functionality as the basis for assessing the validity of the development activity.