Project management within the scope of a project

When a football team underperforms, the president comes out with the famous saying “The position of the coach is not questioned. However, a  short time later, he is replaced by another trainer. With projects, the same happens with  project managers.

Large projects often fail

Every time, it appears that large projects fail. They will be delivered later than planned, are more expensive and suffer from quality problems. Research by the Standish Group indicates that large projects (> $ 10M) are successful in only 10% of the cases, compared to 76% for small projects (<$ 1m). So, making a project small gives no guarantee of success, but the difference is striking.

Of course there are several reasons for it and every case is unique. Moreover, finding the real root cause and then learn from it and improve is also time-consuming and labor-intensive, which is a major project in itself.

Need for large projects remains

There is still a need to execute large projects. Sometimes it is necessary to renew huge back-office systems or a drastic renewal of the infrastructure is required. Or there is a need to support a new business model. This may be the result of new legislation, but also of mergers, division, survival or growth. But how do you run large projects, then?

Traditionally, we create a User Requirements Specification which contains all the details. This goes hand in hand with making a business case, start architecture, a project plan and finding the right resources or subcontract using associated procedures. Some months will have already passed. The pressure is omnipresent and when trouble comes, the pressure increases.

We all know the sayings like “adding people to a late project makes the project late.” Research shows that it is possible to shorten the time of a project, but the cost increases exponentially. Furthermore, it appears to provide an illusion to deliver in less than 75% of the optimum time. This is graphically illustrated in the accompanying Putnam, Norden Raleigh Curve.

We have a number of paradigms to break. Put the whole thing on its head once.

What provides the biggest chance of success?

The only parameter that can successfully be adjusted is the scope. By reducing the scope and delivering fast intermediate results, adjustments will still need to be made. Conversely, delivering as time runs out and then reducing the scope is not possible. Therefore, the five following challenges need to be addressed:

  1. Handle a large project as a product or system that consists of many small parts or features.
  2. Arrange the components so that they can be built in a logical order to emerge into a growing system.
  3. Define a Minimal Viable product that consists of the parts that are minimal and necessary to be able to go into production.
  4. Keep the larger goal, but only work out on the parts that are sufficient for the short term.
  5. Deliver fast and frequent minor releases. Even if they cannot be taken into production. This is very motivating for both the business and IT. Moreover, it offers the opportunity to learn and to steer fast.

But there are conditions…

There are conditions to successfully achieve the above challenges:

  • Form teams that will work together for a longer period. Based on business needs (features), not based on technical skills. Co-locate teams. Bring close together the people who work on a same feature.
  • Management clearly indicates the direction (alignment): What is to be done, not how.
  • Give the teams themselves the freedom (autonomy) to come up with solutions but expect daily progress.
  • Make clear agreements of who feels responsible for what, but stimulate discussion and team results.

Project management tasks do shift. The project manager is no longer the bottleneck that tries to repair the damage, he facilitates collaboration, works on trust through transparency and looks ahead.