There is a potential train wreck out there. The trade press and peer-reviewed journals say systems development is in trouble. The much revered and equally reviled Standish Group’s Chaos Report states that only about 30% of systems development projects succeed, 20% outright fail or are canceled, and around 50% hobble along in some middle (between success and failure) state.
If you don’t like the Chaos Report, several academic studies (hundreds of them) show perhaps not as dire results but the same message—systems development is a blood sport. TA 2007 study of more than 400 projects in the United States and the United Kingdom. Hey, all agree that there is a fundamental flaw in building systems, and the project manager is caught in a real-life Catch-22 situation trying to solve the problem.
Titled “The Impact Of Size And Volatility On IT Project Performance,” it is a telling example. The study found that as the projected headcount gets larger, the underperformance risk increases. The larger the team size, the greater the risk of failure. A 21 Full-Time Equivalent (FTE) project is more than twice as likely to underperform as a 10-FTE project.
OK, you want to reduce project risk, and the plan calls for too many people on the project. What do you do? Well, one option is to spread the project out over time, thus requiring fewer staff. Figure 2 (from the same study) presents the risk level based on the project’s duration. It shows that the risk increases as the schedule extends out, with 18-month projects encountering twice the failure rate of 12-month projects.
The project manager can’t do much. As the same study shows, it doesn’t matter whether you thin the staff count and make the project longer or shorten the duration by adding staff; the devil is the project effort (person-months) required.
Thick or thin (many staff or few staff), long or short (long duration versus short duration), a 500-person-month project is twice as likely to underperform as a 25-person-month project. Put; Big is Bad.
If big is terrible, go small. That should be the end of this article, but making big projects small is not easy. Below are a few suggestions for accomplishing the small is a beautiful effect.
Out of one, many
The simplest way to reduce the risk of one big project is to make it multiple small projects. Slicing up the megaproject into bite-sized pieces is the best way of bringing in a large project. The result should be several subprojects or phases, each with its staff, project manager, goals, and deliverables. But exactly how significant should the subprojects be?
From the study’s findings, one could conclude that a good team size would be 5 to 15 staff and a reasonable duration in the 3- to 12-month coverage. Other authors have different but not dissimilar numbers. Reviewing more than a dozen research studies, one would not be wrong in considering the average recommended team size seems to be in the four to seven range with a duration somewhere between three and nine months. For simplicity, we refer to the four to seven staff and 3- to 9-month duration as the project sweet spot.
The project sweet spot has several advantages. Its small headcount minimizes the required communication overhead, while the short duration mitigates the honeymoon problem.
RELATED ARTICLE: Squandering the Honeymoon Period
The project sweet spot can be implemented serially, in parallel, or in combination. A serial implementation has the mini-projects or phases executed one at a time, one after the other. IT could theoretically use the same staff on each project if megaproject X is broken down serially into mini-projects A, B, and C. When A is complete, the team moves on to B, etc.
Parallel execution requires multiple project teams working on the different mini-projects simultaneously. Similar projects require various team members for each project—sharing staff across projects defeats the purpose of phasing.
There are several technical challenges to successful project phasing. Ost phasing is serial because it is often the easiest way to divide a project. However, parallel phasing becomes more desirable when there are significant schedule pressures. Communication. One of the reasons to break up a large project into smaller pieces is the overhead communications problem. As the number of team members increases, the time and effort needed to keep everyone up to speed on project activity rise exponentially. However, team communication is required, mainly if the phasing is parallel. While most intra-team communication is verbal, multi-team communication is often in writing, increasing communication costs.
Partitioning. Exactly how to carve up the megaproject into multiple smaller pieces called mini-projects, subprojects, or phases. To do it right, the project manager (or whoever is tasked with parsing the project) needs a good understanding of the finished system and the tasks to build it.
Figure 2 shows a sample application data flow diagram (DFD). PArrows show data flow (data in motion) to and from data stores and communication (data sharing) between processes. Processes or functions are depicted with rounded rectangles (A2, C1, etc.). Datastores or files (static data) are represented by open rectangles.
Selecting which processes to include in a mini-project is critical to development success. A phase or subproject should consist of operations where the communication (data sharing) is the highest. Phase boundaries should be defined to minimize cross-phase transmission.
In Figure 2, processes A1, A2, A3, and A4 have the most effective communication and are kept together as a subproject, while a similar decision is made about processes B1, B2, and B3.
Budget. Partitioning a large project into bite-sized chunks can hurt effort and schedules. Communication overhead was discussed above, but multi-phased projects often require more analysis time (as business users are interviewed and re-interviewed) and testing time as the various sub-systems are integrated. Project managers for the multiple mini-projects must incorporate additional effort and time into their plans.
Testing. Testing the individual subprojects is usually neither harder nor easier than pushing a similar portion of a megaproject. However, it can be different. If the megaproject is divided serially into phases, testing other than in the first phase might require revisiting previous stages. For example, imagine a megaproject divided into subprojects A, B, and C. If the subprojects are executed serially, testing subproject C might uncover changes needed to earlier complete subproject A. This problem is not limited to serially executed subprojects. Still, it can also occur in parallel subproject development and even in a big-bang approach where the work on the various portions of the system is completed at different times. However, it can be more prevalent and acute in serially developed subprojects.
Integration. A megaproject divided into components can require some effort to reintegrate once the mini-projects are complete. Not necessarily a difficult task, but one that needs to be considered.
Throwaway Code. Project phasing often requires additional non-application code not in the final production system. This code is necessary for proper testing and integrating phase components that will eventually need to interact with members in other, not yet developed phases.
RELATED ARTICLE: Don’t Throw Away That Throwaway Code
Slicing up what the user sees as a single project can present management challenges.
User management. Senior business managers are often suspicious of any “project” that delivers the actual result. They see a potential “bait and switch” where A, B, and C were promised, but they will only get A or B. Further, the additional time and dollars required for the phased system add insult to injury. To top it off, they are skeptical of the argument that partitioning will eventually cost less (no write-offs for canceled projects or increased maintenance costs for underperforming systems) while increasing the odds of getting what they want.
IT management. Some IT organizations face a significant systems development backlog, with needed applications waiting months or even years before project work can begin. Some senior IT managers pressure current project managers to move ahead as quickly as possible to free up resources that can be applied elsewhere.
Despite the cons and because of the pros, phasing a large systems development project into manageable sub-projects is the single best planning action a project manager can take to increase the odds of project success; despite the increased development costs and schedules, one of the cheapest.
This article is adapted from George Tillmann’s book Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes (Stockbridge Press, 2019). He can be reached at [email protected].
