Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Top 10 ways to have your project end up in court

David Taber | Aug. 10, 2015
David Letterman may be off the air, but his Top 10 List format remains in the comedic canon. In his honor, here’s David Taber-man’s Top 10 list of these worst practices for agile projects.

You've got to focus on the big picture of making your business more profitable, so you don't have time to get into the niggling details of this software project. Besides, business processes and policy decisions are boring and can be politically charged. So when some pesky business analyst asks you to validate the semantic interpretation of a business rule, just leave that mail in your inbox. It'll keep. Later, when it comes to testing and reviews, just send a flunkie with no decision-making authority to check things out.

6. Blatantly intimidate your team

Review meetings should be an expression of your personal power, prestige and authority. Change your mind endlessly and capriciously about details. Change the subject when substantive issues are brought up. Discuss how much your new shoes cost. Punish any questioner. Trust no one (not even your own team members), and make sure that trust never gets a chance to build within the team. Make sure team members know to hide bad news. Use blame as a weapon.

5. Focus on big-bang, slash cut projects with lots of dependencies

Crash programs are the way to get big things done in a hurry. Incrementalism is for wimps and weenies without the imagination to see the big picture. Since complex projects probably involve several vendors, make sure that nothing can progress without your direction and approval. Do not delegate or if you do, don't empower the delegate to do anything. You wouldn't want to lose control!

4. Switch deadlines and priorities frequently

If the generals are right in saying that all your plans go out the window as soon as the first shot is fired, there's no point in planning realistically in the first place. Make sure to have deadlines for things with lots of dependencies, and then move those deadlines three or four times during the project. This'll ensure that the project will involve inordinate waste and overhead but hey, that's the consultant's problem, not yours.

3. Have no contingency plan and no tolerance for budget shifts

It's pedal to the metal nobody has time for insurance policies. You can't afford to run two systems in parallel, validate live transactions or reconcile variances before full production use. Make sure you dedicate 100 percent of your budgetary authority to the vendors, so there's no way to reallocate funds...let alone have a buffer to handle the unexpected. This works even better when your company enforces a use-it-or-lose-it financial regime.

2. Squeeze the vendor as early in the project as you can

Get your money's worth. It's never too early to start squeezing your vendors to get the most out of them. Their negative profit margin is not your problem. Show 'em who's really boss. As the project nears its end-game, start modifying the production system yourself, and begin phase-2 work before phase-1 work has been signed off. Configuration control is for weenies.

 

Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.