On Accelerating Projects

Introduction

Usually projects start with a POC (Proof of Concept) and then move on to a real project using some subset of existing resources and then if the project looks exciting, senior management will want it done faster and is willing to throw more resources at it.

In this article I’m looking at some of the problems this causes and some of the solutions to the problem.

Just Ship the POC

In the interest of Internet time, many companies are following the Lean Startup philosophy of shipping a MVP (Minimum Viable Product) early and then quickly iterating on this based on feedback from users. This has worked well for a number of companies, but it has also failed miserably as well. The big mistake is usually the Viable part of MVP and that the work to make the product viable is greatly underestimated.

This approach often leads to products shipped too early which receive a black eye or lead to very major re—writes (often called refactoring) that amount to starting over from scratch. Often this just starts you on a much bigger project that you need to ramp up for. This approach also tends to do away with a project management framework which then leads to various project dependencies blowing up into major problems.

Brooks’ Law

Brooks’ law is a principle in software development which says that “adding manpower to a late software project makes it later.” This is from Brook’s book: The Mythical Man-Month. The corollary of Brooks’ Law is that there is an incremental person who, when added to a project, makes it take more, not less time. And generally people that have worked on large projects know who that person is.

Some of the causes of Brooks’ Law are:

• Training Time. It takes time to bring people up to speed. Even if they are experts in the technology you are using, they still need to learn your product and understand the work that went before they joined the team. This also diverts productive resources from the project to conduct this training and then extra supervision and oversight are required to ensure they are up to speed.
• Communications Overhead. As the number of people increases the number of possible communication channels increases dramatically. Keeping people in sync and moving in the same direction becomes a real management challenge.

Another common comparison is that the way we put resources on a project is like hiring nine women and demanding that they produce one baby in one month.

Remedies

This might make it look like completing a large project on time or accelerating a large project are impossible. This conclusion is usually due to a number of misinterpretations of Brooks’ Law and to a number of older bad management practices. But ramping up a large project, although not impossible is still highly challenging.

First Brooks’ Law applies to projects that are already late. Ramping up the project earlier certainly helps. Then there is less code already developed to learn and we don’t take away resources to babysit and to train people later in the project. Having real schedules also helps, just having a schedule with no basis in reality is a problem with the schedule not with the project.

The quantity, quality and roles of the people added to the project is a major factor as well. One approach is to over hire for a project to compensate for the time taken for training and communications overhead. Adding high quality people and removing underperformers early can really help as well. Adding some roles like QA and documentation later in the project is not so harmful.

Modern development practices and supporting technologies can really help as well. For instance continuous integration, agile development and test driven development all help greatly by keeping projects in a complete state.

Good design patterns simplify the distribution of work, since then people know where they fit into the design framework and can do their part independently. Similarly if the project is well segregated so that small groups can work on independent parts of the project to greatly decrease the communications overhead.

Another aspect is the social and political climate of a company can have a big effect. Often small companies or projects can rely on a hero to carry the project to success. This model doesn’t scale to large projects, where lots of people doing repeatable work is required. Once projects get to a certain scale, all the work needs to be de-centralized and all the work needs to be delegated. Tightly controlled organizations with a lot of control freaks are going to have problems once they scale past a certain point.

A good Project Management framework within a company really helps as well. Things have progressed quite a bit since Gantt charts and if they have sufficient tools for good tracking and the power to organize dependencies, this can help greatly.

Things to Watch Out For

As you scale your project here are a few warning signs.

• Different groups doing the work differently. This indicates that the design patterns aren’t laid down properly or that people aren’t following them. This will lead to major problems quickly.
• Training time and individual ramp up time not being factored into the schedule. Schedules that are made around resources that are assume to be fully productive are going to slip. As people are added to a project, people need training, acclimatization and ramp up time. The schedule also has to allow for the time of trainers, mentors and supervisors of the new people.
• Watch out for high people turn over. If people are leaving the project or company in higher than normal problems, it usually means a project isn’t being run properly and people are unhappy working on it. Further replacing these people is expensive in recruiting, training and individual ramp up.
• Miscommunications. Often if a lot of communications problem are happening it means people are avoiding the communications overhead problem by not communicating and this causes lots of problems on its own. Managers and team leaders need to stay on top of this and make sure the necessary communication happens. There are a lot of new good tools for this like Wiki’s and group virtual meetings that can help.
• Watch out for bottlenecks. Often when you ramp up a project, one group might have been neglected and starts to be a bottleneck. Eliminating bottlenecks has to be a key role of the Project Management Organization (PMO). Especially watch out for self-imposed bottlenecks where people are taking on too much and refusing to delegate or distribute work. These sorts of practices just don’t scale.
• Watch out for project dependencies. The more dependencies in a project, the harder it is to manage. If the project isn’t designed to scale out independently, it isn’t going to work. Lots of dependencies between groups is a real red flag and a huge indicator that the project needs to be restructured.

Summary

Many companies want to take on ambitious large scale projects. With the current demands to do things in Internet time, there are a lot pressures to really accelerate projects. No one wants a train wreck like in the picture below, but we do have to use past experience from these to guide current projects away from the obstacles and to keep them on track.