My first real job in IT was as manager of a large, multi-million dollar, put-the-business-at-risk ERP project. This being my first real introduction to IT, I learned a lot (usually through a series of mistakes) about managing IT projects. When we delivered the project on-time and on-budget, I was punished by being named the company’s CIO. Because the lessons I learned about IT project management were fresh in my mind, I wrote what I considered to be the definitive guide to IT project management. My plan was to use this guide as I trained by newly-inherited staff on project management skills and tools. It took several weeks to finish my masterpiece. It was a thing of beauty. 71 pages of clear instructions on not just what to do but also what to avoid. (Even now I tear up a little when I think about it.) I scheduled an all-day meeting so that I could share my enlightenment with my staff. The day before the big unveiling, I took one more look through my treatise. I got through the first few pages when it occurred to me that my entire approach was wrong. Rather than a masterpiece, my guide was a set of handcuffs. I was, in effect, telling my staff to turn off their brains and just manage projects the way I thought was best. I took some long, deep breaths and redid my definitive guide to project management. I replaced my 71 pages of detailed instructions with a half page of guidelines. These guidelines are just that, things that I have found work. Because they are guidelines, they are flexible enough that my project managers can adapt them as needed to fit the situation.

This month and next, I would like to list and describe some of my project management guidelines. I am hoping that you will also share the methods and guidelines that you use.

One of my guidelines is that IT can own project costs but the sponsoring business function owns the project benefits. The project benefits typically come from changes in how the business does its work. Try as we might, IT cannot ensure that those changes will not only be planted but be sustained. However, the business function can. This guideline allows my project managers to figure out how best to design, organize and govern the project so that we manage scope and costs but the business delivers the benefits. I have also found that when the project sponsor has to sign up to deliver the benefits, their estimates are more realistic and they are much more engaged.

Another of my project management guidelines is the two-day task limit. In other words, no single project task should be allotted more than 2 days on the schedule. If a task takes longer than 2 days, break it down into components that can be delivered within 2 days. I learned the value of the 2 day task limit the hard way. My project DBA volunteered to create a set of tables. He estimated this would take 10 days. Every couple of days, in our project stand-up meetings, the DBA reported that everything was on track. On the eighth day, I asked him privately how it was going. He confessed that he had not yet started on the tables but expected he would still meet his deadline. He didn’t and the project lost 8 days. Breaking project tasks into 2 day increments not only reduces this risk, it also generates interim deliverables that the rest of the project team can use to advance their tasks. Because my 2 day task limit is a guideline, I never require that the Gant chart be broken into 2 day chunks nor do I tell the project team how to break longer tasks into increments. I have just found that this thought process benefits the project.

I ask my project team members to provide me a weekly status report. The status report has three sections – Progress, Plans, and Problems – and should take no more than about 10 minutes per week to complete. Progress describes what I accomplished during the week. Plans describes what I hope to accomplish next week. Thus, this week’s Progress should map to last week’s Plans. Problems describes where I need my leader’s help. As a project manager, I use my team’s status reports to make sure that my team is focused on accomplishment (not activity) and that we are getting things done. Using the status reports also lets me focus our more frequent face-to-face meetings on decisions and not reporting.

On a weekly basis, I compile the highlights of my team’s status reports and create my own that I send to the project sponsor. My report follows the same Plans, Progress, and Problems format. With this report (which I also distribute to my project team) my entire world knows what we are getting done, not getting done, and what problems we are working to solve.

Next month, I will continue with my guidelines for project duration, concurrent tasks, simplicity, and prototyping.

Related Links
Check out our template for a 10-minute status report for your team members. Learn what it takes to create a reasonable work breakdown structure—not too much, not too little. Project sponsors do more than sign the charter and take the credit. Here's our take on this critical project role.

Comments

Niel, I share your view about the project manager being the guide and an analogy I often use to support this assertion is that ‘a project is a journey’.

I am also a fan of the three P’s style status reports which I learnt from Doug Kennedy, formally of Intel and who now leads Microsoft’s Partner Marketing. Nobody likes doing giant status reports and a good manager should not have to manage anything beyond Projects, Progress and Problem summaries and so avoiding any micro issues.

Great...