There’s an interesting phrase in the PMBOK Guide (Guide to the Project Management Body of Knowledge, 4th Edition) when it comes to the amount of time activities take to get done. It uses the term “work periods” instead of hours, days, weeks or months. This intentionally broad term is there for a reason. (Though the PMBOK Guide does seem intentionally obtuse sometime.)
The reason it’s so broad is that every project and every general type of activity has its own time period that makes sense for it. Some activities get done in hours, some in days, some in weeks.
By keeping the term broad, the PMBOK Guide gives us discretion in choosing the time period that makes the most sense for our project. It recognizes the difference between the units of effort required for different activities, and in doing so, emphasizes that no matter what type of activity, project management processes can help. That is, the body of knowledge of project management has something to say about every type of activity, regardless of the length of time it takes to do it.
This is also a heads up that picking the right unit for the time periods on our projects is an important part of the planning and scheduling process.
That’s what a friend who heads the client service group at an interactive agency complained about over lunch. He wanted to know how he could stop his implementation team from being late.
I asked how they currently communicate.
“For each implementation we submit a ticket through a home-grown Microsoft Sharepoint based system. The ticket has the date submitted, the general scope of work and the due date. They then let me know when an implementation is ready to go. Or, I have to pro-actively call to find out the status of an implementation. Then, inevitably, I have to call the client and tell them their launch is going to be late.”
I suggested putting together a short work plan that described the steps the implementation team goes through to prepare for a launch. In his case, there are generally 5 major steps, each with around 10 sub-tasks. To start with, skip the sub-tasks. Make a bullet-point list of the five major steps. This will give you and the implementation team a single point of reference to gauge the progress of the project.
Instead of touching base only when it is due, you can touch base at each of the 5 major steps. This will bring more visibility into the process. It will also give you early warning of when an implementation is starting to run late, before it is actually due, so you can do something about it.
This is a first step.
This also sets the foundation for more sophisticated and accurate planning using start and due dates for each step and estimating hours, as well as being able to scale the process through resource planning and project templates. But that can come later. The first step is to map out the implementation process in easy, big block steps that become a basis for meaningful communication.
The first, and often hardest, step to starting with project management is creating a task list. Many people try to think of everything that goes into a project or job, write that down, then want to capture the changes between one job and the other by tracking which were the specific tasks that were different.
The idea behind this is that people want to better visualize their process so they can track how different reality is from the plan, where delay’s happen and where they can improve things. The problem with this approach is that no two jobs are ever the same. No two, super-detailed lists are ever going to be the same. You’ll spend more time changing the plan then recording data.
Read the rest of this post »
