The purpose of this article is to provide a Business Manager with an insider’s view of a 'successful' Software Project. This scenario is based on my industry experience of the projects I have participated in or observed. All the projects followed this scenario with only slight deviations, generally related to organizational structure.
The software development process is the primary subject of many books. In order to better address the target audience, a few definitions are provided in this section. I also abstract the typical phases of a Software Project into Planning, Implementation, and Verification.
A Development Group encompasses three teams. They are Program Management, Development, and Testing. The term Business Management abstractly refers to those who budget for and finance the Software Project. The Development and Testing Teams have generally well defined responsibilities implementing and inspecting the Deliverables. Program Management is responsible for planning, scheduling, managing the project. Consequently, Program Management generally owns the schedule and primarily communicates on behalf of the Development Group with Business Management.
More detailed definitions for these in the "Definitions" document.
Business Management determines that a Software Project should be completed utilizing the Development Group by a particular date. Business Management meets with Program Management to discuss general goals and feasibility. A general end date is discussed and agreed to and the Planning Phase begins.
Program Management takes significantly longer than anticipated to provide a rough feature set and project schedule. Development and Testing sign off on the rough and optimistic schedule with assurances that the feature set will be stable and well specified. The rough schedule is anxiously approved by Business Management.
Program Management then repeatedly postpones completion of their portion of the Planning Phase. Most Feature Specifications are not beyond medium stability and many are missing altogether. Program Management is compelled to end their portion of the Planning Phase, so that the Development and Testing teams can theoretically have enough time to meet their obligations.
Development and Testing attempt to create Test Plans and Implementation Plans from the incomplete Feature Specifications.
The end dates Implementation and Verification phases may be slightly postponed as a gesture to Development and Testing. However, the Implementation Phase begins with little consideration for the incomplete state of the Implementation and Testing Plans.
During the Implementation Phase, Features are added, modified, and removed regularly. The corresponding Feature Specifications, Implementation Plans, and Test Plans are not. The Development and Testing teams are unable to keep up with adequately assessing the cost of the changes, so no adjustments are made to the schedule. The Implementation Phase ends nearly on schedule because Development concentrates solely on implementing the most visible and verifiable portions of the modified feature set. Testing agrees to let Development exit the Implementation Phase with assurances they will not be blocked from executing the majority of their Test Plans.
The Verification Phase begins with a relatively low quality implementation of the modified feature set which is based on an array of largely incomplete and erroneous documents, augmented by e-mail and hallway conversations.
Testing begins filing Bugs against documents, Features, and functionality. Business Management becomes concerned about the high rate of Bugs being entered against incomplete and missing features. However, Business Management avoids determining or assigning responsibility in order to avoid demoralizing the Development Group. The Development Group concedes to works long hours for the remainder of the project.
Business Management concedes that the project is likely to slip significantly beyond the schedule end date. The exact length of the slip cannot be determined until the rate at which Bugs are being found trends downward.
Many features are being completed and augmented during the Verification Phase. Consequently the rate which new Bugs are found regularly spikes as new areas become testable. Business Management formally extends the projected finish date by a large margin, since the new Bug rate hasn’t declined significantly.
The Verification Phase takes two to five times longer than initially scheduled, compensating for the incomplete previous phases. The reasons for the deficiencies are proactively obscured from a complacent Business Management by the Development Group.
Finally, the project is completed, thirty to fifty percent beyond its scheduled deadline. Its completion is announced with great fan-fare. Business Management remains perplexed as to why it took so long, but is relieved it didn’t end in a worse scenario. Business Management is impressed by the Development Group’s final cohesive efforts.
This typical scenario reads like an adventure story. It has been repeated so often that many believe that it is a good story. It’s certainly defendable on precedent. It provides some comfort in its familiarity. The myriad of factors that contribute to this scenario are subtle, resilient, and resistant to change.
I have witnessed many attempts to avoid this scenario by requiring better stricter exit criteria adherence, formal processes, and even signed agreements between the teams. None of them ended well for the people driving them. Usually the resistance to such attempts created a seemingly worse scenario.
Typical internal Software Projects often conclude with a workable implementation. At issue is the cost inefficiencies of their development and maintenance, and the degraded quality of what was produced.