A Todo List Is NOT Plan.
Project managers go through stages in their personal evolution, and they can stall at any stage, as any of us can. However, many of the project managers I have reported to in recent years have stalled at a stage where they believe that everything will work out as long as they have a GANT chart.
Everything will be fine, they seem to believe, as long as I have a record of the tasks that have to be performed and an understanding of how these tasks depend on each other. Nothing could be further from the truth. The GANT chart is just the beginning.
A GANT chart is a comforting tool because everybody understands it. A project manager can quickly show where the project is stalling, and show the impact of the stall on the deadlines. A work breakdown is NOT a plan.
The following analogy may make this clear. If I gave you a grocery list, and I asked you to buy me some food, you might have trouble completing the task. You may not even know where you can buy the food I need.
When you return with canned peas, I might have to explain that I really needed frozen peas. I might wave my recipe in your face and fault you for getting the wrong type of peas. As a frustrated project manager, I might never realize that I never shared my recipe with you before sending you out.
In the simple example I give above, the list tells a project manager what he has to plan, but it is not a plan. Many project managers stop when they have their list. They have something to say for themselves if the people they report to ask them how things are going. That is all that matters. This approach is insuffient.
Two and half years ago, I worked on a project with a tight deadline. My manager took care of ordering food for members of the team who worked late. She organized rides for people who depended on public transportation. She never started by asking us how things were going, but she asked us what we needed.
She understood that overtime was necessary, and she agressively removed any barriers that would have made it hard or unpleasant for us to work late. She motivated us to work hard by staying behind with us, and she even brought us coffee. Thanks Lan!
She provided input when asked, but otherwise she stayed out of the way and waited for her scheduled updates. She asked for estimates, and held us to them. She always said thank you. She gave us the credit even though she deserved a fair share of it herself.
If a requirement was unclear, she led the charge to get us the answers we needed. She never left us hanging. Microsoft Project was used to communicate and track our progress, but she planned based on the chart. The chart was not the plan.
When we were going to deploy a new database, she asked the following questions:
- Do you have access to the server?
- Do you have the passwords?
- Is there an approval or a review phase before the database can be deployed?
- Who are you dealing with in the database group?
- What are the risks associated with this deployment?
- How can we be proactive to avoid these risks?
Tasks on a todo list tell what you have to plan, but the list itself is not a plan. Planning and preparing start with the task list. It should be clear that is does not end withthe work plan. Here is another project management resource you may find useful.
Protecting The Guilty
Microsoft Project is a great tool. Many of my government clients use it. But, it is no substitute for good project management.
To protect the guilty, I will mention no names, but I will state the following.
- Do not just assign deadlines. Ask developers to plan and map out the work and provide estimates.
- A todo list is NOT a proper plan.
- Manage people not lists.
- Build a team, and the software will build itself.
- Screenshots are not requirements.
- Developers need to understand the requirements and the business to do a good job.
- Quality is not an accident, and it is not the work on any one person.
- The fish rots from the head.
I want to speak to the first point today.
A team will rarely meet a deadline that was set by a project manager who has not asked the team for an estimate. For one thing, the date is meaningless because, at best, it represents some managers best guess. As a group, developers do not respect uninformed opinion, and that is how they regard dates that are picked out of the air.
It is difficult to motivate developers to meet these dates if you disregard their expertise. When developers are treated as replaceable cogs, you can see the lack of faith and commitment on the faces of each developer at every status meeting. Nobody speaks up.
Members of the team share neither speak about enthusiasm nor doubt. They come in, do their work, and go home. Apathy rules the day. As I have heard one person say, “Government cheques don’t bounce. That’s all that matters.”
Basically, developers need to buy-in to the deadline. When I provide an estimate, it is a matter of pride to accomplish the work in the time I have forecast. I have not excuse and I know it.
Many of the managers I have dealt with in my recent government work have not wanted to even ask the question. They believe that developers, especially consultants, will pad the estimates. Therefore, they provide a due date, and assume an adversarial stance from the word go. The work often takes longer because they micromanage or change the project plan to make up for lost time.
In my next few entries, I want to reflect on project management on some of my recent projects. For useful information, and real insight into project management, visit the Project Management Hut.
I’m Alive!
Times are busy – always will be. The down side of starting a series on Jython and DB40 is finding the time. Writing is easy, but time for hacking is limited. I may have to incorporate an awareness of this into my process when I choose blogging topics. Thanks for your patience.
While you wait, here is some interesting and extremely useful information about Nginx, a beautiful little web server I am falling in love with. I use it to run my Django based site, using FastCGI. If you are getting ready to setup Nginx, this is a great source of information. Nginx (prounced engine X) is fast – give it a try, if you are curious.
I will probably say more about Nginx in months to come.