In project management, size does matter
There is a potential train wreck out there. According to the trade press and peer-reviewed journals alike, systems development is in trouble. The much revered, and equally reviled, Standish Group’s Chaos Report says that only about 30% of systems development projects succeed, 20% outright fail or are cancelled, and around 50% hobble along in some middle (between success and failure) state.
If you don’t like the Chaos Report, there are a number of academic studies (hundreds of them) showing perhaps not as dire results but the same message—systems development is a blood sport.
What they all agree on is that there is a fundamental flaw in how we build systems, and the project manager is caught in a real-life Catch-22 situation in trying to solve the problem.
A 2007 study of more than 400 projects in the United States and the United Kingdom
titled “The Impact Of Size And Volatility On IT Project Performance, ” is a telling example. The study found that as the project headcount gets larger, the risk of underperformance gets higher. 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 level of risk based on the duration of the project. It shows that as the schedule extends out, the risk increases, with 18-month projects encountering twice the failure rate of 12-month projects.
Figure 2 Risk of Underperformance Attributed to Duration
In fact, 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 simply, Big is Bad.
If big is bad, go small. Now, that should be the end of this article, but making big projects small is not so easy. Below are a few suggestions for accomplishing the small is 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 a number of subprojects, or phases, each with their own staff, project manager, goals, and deliverables. But exactly how big should the subprojects be?
From the study’s findings, one could conclude that a good team size would be in the range of 5 to 15 staff and a good duration somewhere in the 3- to 12-month range. Other authors have different but not terribly 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 a number of 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 or in parallel, or in any combination. A serial implementation has the mini-projects or phases executed one at a time, one after the other. If mega-project X is broken down serially into mini-projects A, B, and C, IT could theoretically use the same staff on each project. When A is complete, the team moves on to B, etc.
Parallel execution requires multiple project teams working on the different mini-projects at the same time. Parallel projects require different team members for each project—sharing staff across projects defeats the purpose of phasing.
Most 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.
There are a number of technical challenges to successful project phasing.
Communication. One of the reasons to break up a large project into smaller pieces is the communications overhead problem—as the number of team members increases, the time and effort needed to keep everyone up to speed on project activity increases exponentially. However, communication between teams is now needed, particularly if the phasing is parallel. While most intra-team communication is verbal, multi-team communication is often in writing, further increasing communication costs.
Partitioning. Exactly how to carve up the megaproject into multiple smaller pieces called mini-projects, subprojects, or phases is not always obvious. 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). Processes or functions are depicted with rounded rectangles (example: A2, C1, etc.). Data stores or files (static data) are represented by open rectangles. Arrows depict the flow of data (data in motion) to and from data stores and communication (data sharing) between processes.
Figure 2: Megaproject Divided into Three Subprojects (A, B, and C)
Selecting which processes to include in a mini-project is critical to development success. A phase or subproject should consist of processes where the communication (data sharing) between them is the highest. Phase boundaries should be defined to minimize cross-phase communication.
In Figure 2, processes A1, A2, A3, and A4 have the most significant communication between them 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 have a negative impact on effort and schedules. Communication overhead was discussed above, but in addition, 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 various mini-projects need to incorporate the additional required effort and time into their individual plans.
Testing. The testing of the individual subprojects is usually neither harder nor easier then testing a similar portion of a mega-project, however, it can be different. If the mega-project is divided serially into phases, then testing other than in the first phase might require revisiting previous phases. For example, imagine a mega-project divided into subprojects A, B, and C. If the subprojects are executed serially, then testing subproject C might uncover changes needed to earlier completed subproject A. This problem is not limited to serially executed subprojects, but 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 that is 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 taken into account.
Throwaway Code. Project phasing often requires additional non-application code that is not in the final production system. This code is required for the proper testing and integration of phase components that will eventually need to interact with components 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 some management challenges.
User management. Senior business managers are often suspicious of any “project” that does not deliver the entire end result. They see a potential “bait and switch” where A, B, C was promised but they are only going to get A or A, B. Further, the additional time and dollars required for the phased system adds insult to injury. To top it off, they are skeptical of the argument that partitioning will eventually cost less (no write-offs for cancelled 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 having to wait 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.
In spite of 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, and, in spite of 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 georgetillmann@gmx.com.
The post In project management, size does matter appeared first on SD Times.
Tech Developers
No comments