To Kill A Project

To understand this title, you might need to watch To Kill A Mokingbird! Anyway it is only about title. The article which I read with same title is quite simple. It talks about basic project management fundas and how they are over-modified by today’s managers.


The discussed fundamentals are quite true about IT Service Industry where the managers follow theory of “false urgency”. The project deadlines are falsified and shown to the team as quite earlier than actual deadline. Then the team is pressurized to meet those deadlines by hook or crook. Most of the times, somehow team happens to meet them while some of the team-members break-down in this process. Although the project is delivered before time and customer is made happy but then customer never comes to know why some of the members shifted to other projects and some others left the org. The outcome of “false urgency” might benefit in shot-span of time but its aftereffects always haunt down the projects and the teams.

Theory of “false urgency” isn’t bad if right measurements are taken to reach at the appropriate shifting parameters and aren’t very unrealistic (which doesn’t happen in most of the failed projects).


These precautious steps can work as miracle for both kinds of projects – maintenance and start-up, if followed properly:


  • Assess the business drivers behind the need:
    • Is there actually a fixed time line associated with the need?
    • If there is a fixed timeline, what additional costs can you support?
      • Additional budgetary costs?
      • Additional resource costs?
    • What consequences can you live with?
  • If your requirements are reasonably complete, request a conservative estimate from the project manager.
    • Did he ask his technical leads?
    • Did they account for QA and bug fixing?
  • If their estimate is unacceptable you have one of three options:
    • From the beginning provide whatever additional resources they need to complete the project.
    • Cut functionality down and plan future feature releases.
    • Start planning for the disaster recovery, because your project will fail.

Leave a Reply

Your email address will not be published. Required fields are marked *