If your blueprint says you need 20 people, six months, and $500,000, your problems start when those things are given to you. If you come back in week 27 and say you are behind schedule, need another couple of programmers, and another $50,000, you are over budget and have three strikes against you. If you discover that their plan is going to be compromised this early on, you have two options:
♦ Accept the limitations of staff, time, or money.
♦ Explain the danger and redraft the plan.
Failing this, the only honorable course is to withdraw from this particular project. In the end, no one is going to remember how many times you fail, but the one time you win big. So, if you have to withdraw from the project or abort it later, treat it as a learning experience. You haven't lost when finances force closure. You haven't lost when your staff goes over to your competition. You haven't lost when your program takes a dive. You have only lost when you say you have.
However, even with faith in yourself intact, it still takes courage to stand down the troops, especially when they are all eager for the fray. It is infinitely wiser to disengage than be driven into the ground. Acting early is likely to conserve a portion of your resources that may later form the basis for a better springboard.
In addition, if you have good reason to shut down, everyone around you will understand, provided you call them in, explain the situation frankly, and allow them to ask questions and talk through the situation so that they can see for themselves that there is no other choice.
Common management reasons for one third of all IT projects aborting include the following:
♦ Costs outrun budgets
♦ Failure to complete
♦ Lack of adequate personnel
On the programmer's side, there are equally valid though less widely understood reasons for failure:
♦ Lack of management confidence
♦ The financial precariousness of the firm (if the project doesn't come in on time, it could take the company down)
♦ The absence of any budget or plan
♦ Too many technical hurdles
All of these can be valid reasons for curtailing a project. If you are worried, discuss the situation with a colleague privately. It is not an indication of failure. It is a sign of profound concern and responsibility to the company, the project, and everyone involved.
Was this article helpful?