Saturday, March 29, 2008
Enterprise Architecture and Death by Planning
As long as we follow the plan and don't diverge from it, we will be successful...
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 many 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 over planning. Over planning often occurs as a result of cost tracking and staff utilization monitoring. The two types of over planning are known as the Glass Case Plan and Detailitis Plan. The Glass Case Plan is a subset of the Detailitis Plan in that (over) planning ceases once the project starts. In the Detailitis Plan, over planning continues until the project ceases to exist, for a variety of unfulfilling reasons.
Often, a plan produced at the start of a project is always referenced as if it's an accurate, current view of the project even if it's never updated. This practice gives management a "comfortable view" of delivery before the project starts. However, when the plan is never tracked against, nor updated, it becomes increasingly inaccurate as the project progresses. This false view is often compounded by the absence of concrete information on progress, which often is known only after a critical deliverable slips its schedule.
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 (and unnecessary) levels of detail. The ability to define such a high level of detail gives the perception that the project is fully under control.
Some of the symptoms you can find are:
| | View blog reactionsIn 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 many 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 over planning. Over planning often occurs as a result of cost tracking and staff utilization monitoring. The two types of over planning are known as the Glass Case Plan and Detailitis Plan. The Glass Case Plan is a subset of the Detailitis Plan in that (over) planning ceases once the project starts. In the Detailitis Plan, over planning continues until the project ceases to exist, for a variety of unfulfilling reasons.
Often, a plan produced at the start of a project is always referenced as if it's an accurate, current view of the project even if it's never updated. This practice gives management a "comfortable view" of delivery before the project starts. However, when the plan is never tracked against, nor updated, it becomes increasingly inaccurate as the project progresses. This false view is often compounded by the absence of concrete information on progress, which often is known only after a critical deliverable slips its schedule.
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 (and unnecessary) levels of detail. The ability to define such a high level of detail gives the perception that the project is fully under control.
Some of the symptoms you can find are:
- 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.
- A project that is late, low quality and requires further investment.
- Forced executive management compliance.
- Crisis oriented project management.
- Potential loss of key staff as they bail for greener pastures.
- Ignorance of basic project-management principles.
- Spending more time planning, detailing progress and re-planning than on delivering software.
- Tech leads plan the team's activities and the developer's activities.
- Continual delays to software delivery and eventual project failure.
