Project Management Ideas du Jour

This is a repost from the same day a year ago. All of these still apply.

1. It is best not to share the project plan with the project team as it leads to unnecessary and usually incredibly stupid questions.

2. Mandate that team members submit task duration estimates as precisely as possible: two decimal digits (e.g. 17.36 days) are usually sufficient but some projects may require three digits.

3. Strive to disperse project team over multiple locations: it greatly reduces the time people waste mindlessly chattering with each other.

4. In this economy, everyone ought to be able to work harder. Schedule tasks based on 10-hour days.

5. Involve the Steering Committee in day-to-day running of the project. They will tell you how much they like it.

6. When briefing the Steering Committee, it’s a good idea to declare all nearly completed tasks as completed. Ninety per cent is awfully close to 100 per cent and the Committee Members will feel encouraged.

7. Try to surprise your Project Sponsor every now and then. Rescheduling the implementation date, firing half of the team or changing the vendor half-way through should all be considered.

8. Status updates clutter mailboxes, so avoid them.

9. Get rid of those team members who disagree with you. You are in charge of a critical project and the last thing you want around is some worm questioning your decisions.

10. Don’t waste any time trying to understand the business domain. It is unimportant and is not your job.

11. A list of typical project risks can be easily obtained on the Internet. Don’t waste precious time developing it; this is merely a formality.

12. Act professionally: don’t engage in unrelated conversations with your staff and certainly avoid socializing with them. It is important to maintain a distance.

13. Information Technology is an exact, predictable field. If your programmers cannot write code without any defects, replace them.

14. To speed up negotiations with vendors, just sign their canned contracts.

15. Details are unimportant; the job of the project manager is the overall supervision.

16. Once the scope of the project is determined, ensure that it is impossible to change it.

17. A lot of people may claim to be project stakeholders. Feel free to ignore those you don’t like.

18. Encourage team members to decide for themselves what their tasks should be.

19. The best way to gauge the skill of a fellow project manager is to ask them about the largest project budget they’ve ever been responsible for.

20. Plan to release the project team on the day of implementation, to save money.

21. (Bonus) Forget that it’s April Fools’ Day and start typing an angry letter to the Editor. Remember that it’s April Fools’ Day when you’re on the third page of it!

What is wrong with ITIL?

I recently answered this question and then thought it may be worth posting in the blog.

Question: What quality frameworks (ISO, CMMI, ITIL, etc.) have you used in your organization(s), and what pros/cons from each have you found in your experiences?

Answer: There are three key issues that I encounter time after time:

– Faulty belief that a framework (any of these) is a silver bullet for all and any problems. I have seen them applied to correct personality conflicts and dysfunctional leadership. I kid you not!

– Failure to customize. You gotta make it yours to work for you. An IT services organization I know lost customers because third line support found themselves compiling case documentation 80% per cent of their time. Resolved that, but not before some changes at the top.

– Falling in love with your methodology. This is not set-it-and-forget-it deal and you have to test your approach for relevance all the time. Is there a better way to do it? Are our assumptions still valid? A bank I know implemented user account management policies which require faxing (this was in 2008!) of a change form to the support centre. It takes 2-3 weeks to have a user set up. Meanwhile, the business has to put these people to work, so passwords are shared as a matter of standard practice. Formally, they have adopted ITIL. In reality, they are providing poor (if not dangerous to the business) service, having failed to re-evaluate their approach.