White Book

Project Rescue

How to rescue your technical project? Free guide

A broken project? A project poorly accepted by users? A schedule that gets out of hand too much? The reasons for the problem (s) can be numerous: design errors, resigning or incompetent service provider, imprecision of the need, etc.

Receive this white paper

Couverture du document "Project Rescue" de TCM, The Coding Machine. Nicolas Peguin et Jean-Guillaume Dujardin, avril 2016.

In this guide, discover:

How to make a diagnosis?
Rescue methods
Some practical cases
Our recommendations

This white paper proposes a new classification of risks and a more precise methodology to try to save your project.

Introduction

A fascinating subject!

The Coding Machine has often had the opportunity to help clients in difficulty with their project. These critical situations have enabled us to understand the origins of these slippages, to find solutions and to implement them.

“Project Rescue” is a fascinating subject for several reasons:

It requires mobilizing a very wide range of skills: human skills, to objectively distinguish the real problems from those that are fantasized, technical skills, in order to be able to dive into the heart of the applications, and finally creativity to imagine or find the good solutions.
It is a demanding activity: client expectations are high. These missions require a significant amount of energy to be deployed at the start in order to convince the various stakeholders and to put in place the right corrective actions.

Difference between “risk” and “failure”

A risk is likely to be managed: it is possible to take preventive or corrective actions. Failure is often an accumulation of problems that independently of one another could have been solved. In other words, it is a succession of unmanaged risks which often results in an overall blockage of the project. The difference between the two is not obvious. The natural tendency is to take action to try to correct problems that arise over time. Sometimes, having your head in a project, it is not uncommon to lose your lucidity. A problem that may seem very serious may not be, and vice versa. So, if you are wondering if your project is failing or if you are just managing risk, you are certainly at a crucial stage in the development of your project.

Worrying is a good disease. Because the later we realize the problems, the more serious it is. In other words, the more risks we accumulate as the project progresses, the more difficult the rescue will be!

This white paper is there to provide you with a summary of our experiences, the pitfalls to avoid, and explain the methods we have applied. If you feel that your project is on the wrong track or in turmoil or if, more simply, you want to deepen the notion of risks on a project, this white paper is for you.

Note: This white paper is the result of our experience. You may find flaws there or raise limits. Please let us know. On the other hand, we are convinced that we still have not covered the subject, you have the right to be creative!

Make a diagnosis

Your project is evolving in a hostile environment, you need to make a precise diagnosis

The dangers that await you!

Successful rescue of a project requires delving into the heart of the problem in order to draw an objective picture of its state. What are the problems? Can they be resolved quickly? By whom and in what way?

On each facet (organization, technique, etc.) and at each stage, dangers await you but do not panic! It is only those who do nothing who do not take risks.

Some preliminary remarks:

Risk can be endogenous or exogenous: poor monitoring will be at least in part the responsibility of the client and therefore an internal risk; while an incompetent provider will be an external risk. Try to be objective about the situation!
Often the risks are cascading. For example, choosing the wrong technical architecture when launching a project might mean wrong decisions later. Thus, the launch stage, that is to say how to structure your project and the choice of service provider, are key stages in limiting the risks. You will need to pay special attention to it.

SCOPE CREEP

A very common symptom: from the very start of the project, a very broad scope is defined, or increasingly complex needs are expressed as the project goes on.

This often happens when the client wants to launch a new business. Offering many features gives the reassuring impression of providing a more complete service to the end customer, and therefore a more “sellable” one. In reality, it is often the opposite. As a rule, it is better to define the smallest possible scope, test quickly and redefine the need based on feedback from users or beta testers (“Pave the cow path”).

Defining a very broad scope also gives the misleading impression that it will cost less than developing in several stages. This is not true: if many features end up unused, the cost of these unnecessary developments and the effort needed to build them can lead the project to failure.

Scope creep can also be the result of poor project management. A provider in a weak position, for example because of a major delay or a staffing problem, may accept additional developments in the hope of keeping a good relationship with its client. This does the client a disservice: by piling up delays and new requests, the project drifts further and further.

THE BAIT PRICE

The price offered by the provider is deliberately low in order to “hook” the client. The provider deliberately underprices the work to win the contract. As the project progresses, two situations will arise:

Development continues because you accept many change orders,
The project is blocked because you do not want to (or cannot) keep paying.

This “fake price” is likely to seriously damage your relationship with your provider as the project moves forward.

However, it is important to distinguish between a deliberate act (a provider baiting a client) and a scope that changes and grows abnormally along the way.

PROJECTING YOUR FEARS (OR MAKING ASSUMPTIONS)

Strictly speaking, this is not a risk. A lack of knowledge about projects can create irrational fears. We have already been called in on a project that was actually going rather well! It is therefore important to set up, from the start, a governance framework to measure progress, manage risks and decide on changes: anything that helps stakeholders feel comfortable with the project and its progress.

These measures (time spent, progress, etc.) should give the whole team an objective view of the state of your project. They make it possible to put action plans in place to manage certain risks or reschedule parts of the project.

THE TUNNEL EFFECT

The tunnel effect means developing for a long period without involving users. In the end, the solution may not meet users’ needs or expectations. Acceptance testing, long and therefore tedious, is then likely to be rushed, as users do not necessarily have the time needed to complete it.

THE NUMBER OF BUGS

This question comes up often: does a large number of bugs during acceptance testing mean a project is failing?

In most cases, no! This misconception needs to be put to rest. The more bugs there are, the more your users are testing the solution. It is when the solution is not tested enough that problems can arise in production. So, counter-intuitively, this indicator is rather a sign of quality.

The first technical acceptance phase should fix most of the basic bugs. If it does not, a reset may be needed to avoid wearing users out during testing.

Another nuance is whether the fixes are effective. Performance problems that cannot be fixed may point to major design issues.