One post I’ve always wanted to do, is my reflections on the types of deadlines make the most successful projects out there. In my experience, these rules are inviolate if you want a successful IT Project. These are:
- There must always be a deadline, projects without deadlines go nowhere
- This deadline must be respected by all, a deadline that is acknowledged as “useless”and “not going to happen” is not a deadline. Reset your deadline.
- A deadline that has been passed is not a deadline, reset again for a new deadline after following some of the other rules below.
- One occasionally allowed exception, vague deadlines on farther horizon projects of lower priority. Be sure to firm up deadlines as they near.
- Deadlines must be agreed upon by the parties under pressure to perform by the deadline
- A deadline imposed on someone against their will is absolutely asking for trouble.
- A deadline suggested, coaxed or otherwise persuaded upon these people in any fashion is only a slightly lighter shade of grey, making a project person stand up to you may get you in trouble depending on the bravery of the people under pressure to perform.
- If there is a firm limit to how long a project can continue (budgetary constraints, etc.) do not mention it to the people under pressure to perform by the deadline. Let them estimate the project, then do battle with fitting the features you want within the timeframe you can afford. Do not “Timebox” the project by giving the people under pressure to perform the hours in budget and watch them get just within the amount of time in a subconscious desire to please those up ahead.
- There must be carrots for those who make it on or before the deadline and sticks for those who are late
- Bonuses and perks about for the early finishers, cuts in bonuses, pay, even termination in extreme cases for the latecomers, provided rules #1 and #2 above were followed.
- Some exceptions can be made if a project wasn’t completed due to no fault of the people under pressure to perform the deadline (acts of god, third-party developers, etc.)
- Retrospectives on every successful and failed project are key, one must learn from their history so that one shall not repeat it.
These rules are traverse any methodology (Agile, Waterfall, etc.), technique, etc. If these rules are violated, do not hold me responsible for your project failure.