In project management, size does matter

by Joseph K. Clark

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 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.

project management

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, ” it is a telling example. The study found that as the projected 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 the risk increases as the schedule extends out, with 18-month projects encountering twice the failure rate of 12-month projects.

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 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 own 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 in the range of 5 to 15 staff and a reasonable duration somewhere in the 3- to 12-month coverage. 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 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 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 megaproject 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 various 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 several 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 required, mainly 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. 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.). Datastores or files (static data) are represented by open rectangles. Arrows show data flow (data in motion) to and from data stores and communication (data sharing) between processes. 

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 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 hurt 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 multiple mini-projects need to incorporate additional effort and time into their individual 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 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 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 some management challenges.

User management. Senior business managers are often suspicious of any “project” that delivers the actual end result. They see a potential “bait and switch” where A, B, C was promised, but they will only get A or A, 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].

Related Posts

Leave a Comment