|
|
Also Known As: Glass Case Plan, Detailitis Plan
|
 | "We can't get started until we have a complete program plan." |
| "The plan is the only thing that will ensure our success." |
| "As long as we follow the plan and don’t diverge from it we will be successful" |
| "We have a plan, we just need to follow it!" |
In many organizational cultures, detailed planning is an assumed activity for any project. This assumption is appropriate for manufacturing activities and many other types of projects, but not necessarily for software projects, which contain many unknowns and chaotic activities by their very nature. Death by Planning occurs when detailed plans for software projects are taken too seriously.
Many projects fail from either over-planning or under-planning. The generalization here is either of these with their variations. This focuses on delivering the project deliverables rather than a cost tracking exercise. This is based upon the assumption that it is a corporate necessity to deliver a project. As opposed to tracking effort as a bureaucratic exercise which wastes time for all concerned but the cost accountants. The variations can actually occur together, where a highly detailed plan is produced but then never tracked against due its complexity.
Often a plan is produced at the start of a project and never updated but always referenced as if it is an accurate current view of the project. This is fairly common as it gives the management a ‘comfortable view’ of delivery, often before the project starts.
However as the plan is never tracked against, nor updated, it becomes
increasingly inaccurate as the project progresses. This false view is often compounded by
the lack of concrete information as to progress. Often progress, or the lack of it, is
known
only after slippage of a critical deliverable.
Figure 1-1. Glass Case Plan
The picture shows the project plan that was created prior to project kick-off and the management assumes that because there is a plan then delivery will follow automatically, exactly as specified in the picture with no intervention (or management) necessary.
Sometimes the solution to effective delivery is regarded as a high degree of control via a continuous planning exercise that involves most of the senior developers, as well as the managers. This approach often evolves into a hierarchical sequence of plans, which show additional (an unnecessary) levels of detail. The ability to define such a high level of detail gives the perception that the project is fully under control.
Death By Planning involves thorough preplanning; regardless of unknowns
The Glass Case Plan symptoms are the first noticed in both it and the Detailitis Plan.
The symptoms usually include at least one of the following:
| Inability to plan at a pragmatic level. |
| Focus on costs rather than delivery. |
| Enough greed to commit to any detail as long as the project is funded. |
The consequences are incremental:
| Ignorance of the status of the project’s development. The plan has no meaning, and control of delivery lessens as time goes on. The project may be well ahead or behind the intended deliverable state and no one would know. |
| Failure to deliver a critical deliverable (the final consequence). |
Consequences grow incrementally until finally the project overruns with the usual options of
| Further investment. |
| Crisis project management. |
| Cancellation. |
| Possible loss of key staff. |
"Art for Arts Sake."
-- Howard Dietz
The symptoms are a superset of the Glass Case Plan:
| Inability to plan at a pragmatic level. | ||||
| Focus on costs rather than delivery. | ||||
| Spending more time planning, capturing progress and re-planning than on delivering
software:
| ||||
| Project developers break down their activities into tasks |
The consequences are intertwined and feed off each other:
| Each planner has to monitor and capture progress at the level shown by their plan and re-estimate. |
| Endless planning and re-planning causes further planning and re-planning. |
| The objective has shifted from delivery of software to delivering a set of plans. Management assumes that because effort and cost is being tracked, progress must be equivalent. In fact there is no direct correlation. |
| Continual delays to software delivery and eventual project failure. |
Typical Causes
In both cases, Glass Case Plan and Detailitis Plan, the primary cause is lack of a pragmatic, common-sense approach to planning, schedules, and capture our progress.
| No up-to-date project plan that shows the software component deliverables and their dates. |
| Ignorance of basic project management principles. |
| Over-zealous initial planning in an attempt to enforce absolute control of development. |
| A sales aid for contract acquisition. |
| Over-zealous continual planning in an attempt to enforce absolute control of development. |
| Planning as the primary project activity. |
| Forced customer compliance. |
| Forced executive management compliance. |
There should never be any exceptions to the Death by Planning AntiPattern.
The solution is the same for the Glass Case Plan and Detailitis Plan. A project plan should primarily show deliverables (regardless of how many teams are working on the project). Deliverables should be identified at two levels:
Deliverables include such things as:
| Business requirements statement |
| Technical description |
| Measurable acceptance criteria |
| Product usage scenarios |
| Component use cases |
The plan should be supplemented with validation gates for each component as well as the overall product. Such as:
| Conceptual design approval |
| Specification design approval |
| Implementation design approval |
| Test plan approval |
The deliverable plans should be updated weekly to ensure appropriate planning and controls that reduce project risks. This allows issues, risks, slippages and early deliveries of defined deliverables to be dealt with by appropriate timely responses.
Tracking is done on the estimated level of completeness. This sometimes means regressing the completeness that was input to the plan in a previous time period. Completeness should be gross measurements rather than fine measurements. Such as tracking in 25% steps rather than 5% steps.
A Gantt Chart can be effectively used to visually illustrate deliverables, associated dates and interdependencies. By tracking against a baseline plan the following states of deliverables will be immediately obvious:
| On schedule |
| Delivered |
| Early (with estimated new delivery date) |
| Late (with estimated new delivery date) |
Proper planning involves tracking of actuals and re-planning
It is essential to baseline early and rarely. Otherwise the ability to track changes is lost. Furthermore activities/tasks/deliverables should have dependencies set between them where they exist.
When estimating it is advisable to allow a contingency period for all those inevitable ‘unknowns’, such as:
| Requirements increase (creep). |
| Design dead-ends. |
| Third-party software workarounds. |
| Defect identification (finding the problem in a set of integrated components). |
| Defect correction (bug-fixing). |
It is also important to establish a minimum time frame in which to accomplish any activity. This -prevents such constraints as two days to code and test a "simple" program.
(A Note from Bill Brown) Some of the best estimates for repeatable tasks where there is no scientific ‘blue book’ of precise statistical measurement are made by housewives. My wife, Kate plans in her head both short and long term and daily implements these plans. If we as software engineers had her success rate in delivering dinner, clean clothes etc. (which involve a sequence of activities such as shopping and cooking or washing and ironing) then this book would be unnecessary.
The Death by Planning AntiPattern varies primarily by levels of detail, and can go from identifying major milestones, which are usually tied to funding/approval stages, to micro-deliverables within the project delivery stages for each team.
These variations are equally applicable to both the Glass Case Plan and Detailitis Plans:
Funding Variations: Funding milestones establish decision points for project continuation
The Glass Case version of the micro-deliverables plan only varies from the Detailitis Plan in that it is never updated. It shows very small deliverables which cannot be fully understood prior to starting the project. Therefore any estimates must by definition be incorrect based upon the lack of any real understanding of the software to be built. This type of plan is usually produced by technically gifted amateurs. Although the tasks need to be clearly understood, putting them in a plan usually only results in unnecessary planning and tracking, as opposed to doing.
Micro-deliverables plan
These examples are based on our own experience in learning "the hard way."
For this example, we’ll say a systems integrator decides to build a middle-ware component not yet available from any major vendors in spite of international standards issued over a year ago. The systems integrator agrees to a detailed delivery plan in advance of starting any project work in order to obtain a funding source. The plan has been based upon the view of staff who have not yet delivered software ‘in anger’. The plan is highly specific technically, and the estimates are very optimistic; it is continually referenced by the project manager, but never updated to reflect any actual effort. This leads to missed delivery dates. There is a general lack of knowledge as to real progress; the systems integrator is apprised of delivery date failure only after the dates have passed. The following plan is an extract from such an actual development.
Glass Case Plan Example
In an attempt to control development to ensure that full control is established, and end-user company produces a plan that has three levels:
The following plan extract indicates the complexity.
Detailitis Plan Example
Detailitis causes an inability to track against the plan without taking considerable focus away from actually delivering the system. This results in significantly reduced staff productivity. Plan management quickly becomes unrealistic due to the complexity.
The solution is to replace the detailed plan with one that shows key deliverables against dates, with dependencies and constraints. If a deliverable is missed, then something important has occurred. The prior plan attempted to track progress by effort which is unrealistic. Effort = staff * days elapsed. So what? E=MC2 , but the formula does not create nuclear power!
The Analysis Paralysis AntiPattern can exacerbate the consequences of Death By Planning. If the analysis phase runs over its allotted schedule, either a schedule slip must occur or inadequate analysis models are applied to downstream phases.
Death By Planning can not match the chaotic (white-water) nature of software development,because it creates a significant disparity between the management's planning models and actual development activities. Architects and developers often have to live double lives. On one hand, they must visibly cooperate with management's plan for the project; at the same time, developers confront the actual
status of the software which may not resemble the management model. For example, the plan may be used to pressure developers into declaring software modules complete before they are mature. This causes downstream problems in integration and testing.
|
� Copyright 2017 William Brown, Raphael Malveau, Hays McCormick, Thomas
Mowbray, and Scott W. Thomas. All rights reserved. |
