In project management, size matters

There’s a potential train wreck there. According to the trade press and peers-peer-reviewed journals, systems development is struggling. The highly revered, and equally reviled, Standish Group’s Chaos Report says that only about 30% of system development projects succeed, 20% fail outright or are cancelled, and about 50% hobble in an intermediate state (between success and failure).

If you don’t like the Chaos Reportthere are a number of academic studies (hundreds of them) showing perhaps not such disastrous results, but the same message: system development is a blood sport.

What they all agree on is that there is a fundamental flaw in the way we build the systems, and the project manager is caught in a real catch-22 situation trying to fix the problem .

A 2007 study of over 400 projects in the US and UK entitled “The impact of size and volatility on the performance of IT projects”, is a telling example. The study found that as project headcount increases, the risk of underperformance 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 are you doing? Well, one option is to spread the project over time, which requires less staff. Figure 2 (from the same study) shows the level of risk as a function of project duration. It shows that as the timeline gets longer, the risk increases, with 18-month projects experiencing twice the failure rate of 12-month projects.

Figure 2 Risk of underperformance attributed to duration

In fact, the project manager cannot do much. As the same study shows, it doesn’t matter whether you reduce the number of employees and lengthen the project or reduce the duration by adding personnel, the devil is the project effort (person-months) required.

Thick or thin (many employees or few employees), long or short (long duration or short duration), a 500 person-month project is twice as likely to underperform as a 25-person-month project. people. Simply put, Big is Bad.

If big is bad, go small. Now that should be the end of this article, but making big projects small isn’t that easy. Here are some suggestions for making the small is beautiful effect.

On one, many

The easiest way to reduce the risk of a large project is to make it into several small projects. Cutting the megaproject into bite-sized chunks is the best way to do a big project. The result should be a number of sub-projects, or phases, each with its own staff, project manager, goals, and deliverables. But what exactly should the size of the subprojects be?

Based on the results of the study, one could conclude that a good team size would be in the order of 5 to 15 employees and a good duration in the order of 3 to 12 months. Other authors have different but not very different numbers. Looking at more than a dozen research studies, it wouldn’t be wrong to consider that the average recommended team size seems to be between four and seven with a duration between three and nine months. For simplicity, we refer to the four to seven employees and the term of 3 to 9 months as sweet spot project.

The project’s sweet spot has many advantages. Small headcount minimizes communication overhead required, while the short duration alleviates the honeymoon problem.

RELATED ARTICLE: Wasting the honeymoon period

The project sweet spot can be implemented in series 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 serially broken down into mini-projects A, B, and C, IT could theoretically use the same staff on each project. When A is finished, the team passes to B, etc.

Parallel execution requires multiple project teams working on different mini-projects at the same time. Parallel projects require different team members for each project – sharing staff between projects defeats the purpose of phasing.

Most phases are serial as this is often the easiest way to split a project, however, the parallel phase becomes more desirable when there are significant schedule constraints.

There are a number of technical challenges to successfully phasing a project.

Communication. One of the reasons for breaking a large project into smaller pieces is the problem of communication overhead – as the number of team members grows, the time and effort required to keep everyone up to date project activity increase exponentially. However, communication between teams is now necessary, especially if the phasing is parallel. While most intra-team communication is verbal, multi-team communication is often in writing, which further increases communication costs.

Partitioning. It’s not always easy to know exactly how to break down the megaproject into several small pieces called mini-projects, sub-projects or phases. To do it right, the project manager (or whoever is responsible for analyzing the project) needs a good understanding of the finished system and the tasks to build it.

Figure 2 shows an example of an application data flow diagram (DFD). Processes or functions are represented by rounded rectangles (example: A2, C1, etc.). Data stores or files (static data) are represented by open rectangles. Arrows represent data flow (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 the processes to include in a mini-project is critical to development success. A phase or sub-project should consist of processes where communication (data sharing) between them is highest. Phase boundaries should be set to minimize communication between phases.

In Figure 2, processes A1, A2, A3, and A4 have the most important communication with each other and are held together as a subproject, while a similar decision is made for processes B1, B2, and B3.

Budget. Breaking a large project into small pieces can negatively impact efforts and schedules. Communication overhead has been discussed above, but in addition, multi-phased projects often require more analysis time (as business users are surveyed and re-surveyed) and testing time to as the various subsystems are integrated. Project managers for the various mini-projects should incorporate the additional effort and time required into their individual plans.

Test. Testing individual sub-projects is generally no harder or easier than testing a similar part of a mega-project, however, it may be different. If the megaproject is divided into several phases, then testing other than in the first phase may require revisiting previous phases. For example, imagine a mega-project divided into subprojects A, B, and C. If the subprojects are run in series, testing subproject C may reveal needed changes to previously completed subproject A. This issue is not limited to serially executed subprojects, but can also occur in parallel subproject development and even in a big bang approach where work on different parts of the system is completed at different times. However, it may be more prevalent and acute in serially developed subprojects.

The integration. A megaproject divided into components may require effort to reintegrate after the miniprojects are completed. Not necessarily a difficult task, but one that must be taken into account.

Disposable code. Project phasing often requires additional non-application code that is not in the final production system. This code is required for proper testing and integration of phase components that will eventually need to interact with components in other phases not yet developed. .

RELATED ARTICLE: Don’t Throw Away That Disposable Code

Slicing what the user considers a single project can present management challenges.

User Management. Senior business leaders are often wary of any “project” that doesn’t deliver the full end result. They see a potential “bait and switch” where A,B,C was promised but they will only get A or A,B. Plus, the extra time and dollars required for the progressive system adds insult to injury. ‘insult. To top it off, they are skeptical of the argument that partitioning will end up costing less (no write-offs for canceled projects or increased maintenance costs for underperforming systems) while increasing chances of getting what they want.

IT management. Some IT organizations face a significant system development backlog, with needed applications having to wait months or even years before project work can begin. Some senior IT managers are pressuring current project managers to move forward as quickly as possible to free up resources that can be applied elsewhere.

Despite the disadvantages and because of the advantages, breaking down a large systems development project into manageable sub-projects is the best planning action a project manager can take to increase the chances of success of the project and, despite the increase in costs and development times, one of the cheapest.


This article is adapted from the book by George Tillmann Project Management Scholia: Recognizing and Avoiding the Biggest Project Management Mistakes (Stockbridge Press, 2019). He can be contacted at [email protected]