Teaching Teams About WBS

A simple and effective WBS instruction session before every project is, I believe, crucial.

When team members do not know what a task is or should look like, the project manager gets to spend hours sifting through Gantt charts and a) giving their best guess at what a vague task description means, b) calling team members to define a task and wasting precious company and personal time, or c) incorrectly understanding the task description and thus perhaps incorrectly assigning time and resource allotments. You can easily see how this could become a problem, and a huge time-consuming waste of effort.

I spent a lot of time on the last project determining what "Permits" was to mean (Business permit? Fire permit? HazMat permit? Wastewater permit? Building permit?) , "Business cards" (Price out? Create? Purchase? Print? Distribute?), and of course multiple tasks with the exact same description (Three different "Obtain Boeing approval for process" tasks in various settings - at one point the function owner - and author of the tasks - said to delete them, seeing them as duplicates, until I realized they were intended to b associated with different processes).

In order to avoid this issue, I would like to spend a half hour in our orientation session with the team members to train them simply on how to construct a WBS - or more to the point, how to create tasks. (A WBS is a more complicated procedure and the Project Manager can consolidate tasks into that, if necessary.)

Hands-on experience is always the best teacher, so we would bring props and require interaction.

Props: Coffee pot, filter, beans, grinder, cup, milk & sugar.

1. Determine the scope of the project: Are we going to (a) Make a pot of coffee, or (b) Serve a cup of coffee? (Latter)

2. Brainstorm necessary steps (i.e. purchase coffee beans, grind beans, plug in coffee pot, turn on coffee pot, fill with water, fill with beans, turn on, let percolate, pour cup, add milk, add sugar). Depending on the size of team, you could use any number of different brainstorming steps. For a large team, I would suggest going around the circle one at a time throwing out ideas, and writing these on a board, until all ideas are exhausted.
For a small team, you could have them fill out blank index cards in a given time limit of, say, three minutes, and then collate and through the authors' participation and consent, remove duplicates. You may find that, right off the bat with this method, people will realize how vague some of their descriptions are.

3. Now, have entire team look at the steps on the board, and one at a time have them interactively convert them into deliverables. i.e. for "Coffee Beans", you can ask them, what does this mean? No doubt the author will say, "Buy coffee, of course!" while another person will say, "Probably means add coffee to the pot." Use this time to help them understand what a deliverable is: Something you can actively do, phrased in verbs. The task would now read "Purchase coffee beans".

Tip: Do not make the tasks too short - such as Get up from chair, Open door, Go to Car, Go in store, Choose beans, Pay for beans ... etc.... A rule of thumb is, no less than a day, on average. On the flip side, do not make them too long - for instance, "Grow coffee beans". A task this large may entail several months to several years! It might even be its own project! The length of a task varies from project to project, but most PMs feel that anywhere from more than a week to more than a month is too lengthy for one task. You may need to play your tasks by ear.

4. Once the tasks are all on the board in terms of deliverables, you can either (a) put them onto index cards and re-arrange them until they are in approximate chronological sequence, or (b) if it is a small group, put them into MSProject immediately and allow them to re-arrange them into order.

Learning by doing is always the best method ... And expand on #3 to whatever length you deem necessary, to make sure your team members walk away from this exercise knowing a few important things:

1. Frame EACH task as a deliverable (using verbs).
2. Do not make them too small, or too large (you will need to define the time range for your project tasks) .
3. Do not allow any two tasks to be phrased exactly the same way - separate from the schedule, they should all be recognizable and understandable.
4. Make the wording clear enough that somebody outside the project (although perhaps not outside the industry!) could understand what it meant.

The Triple-Header

Rule of thumb that every Project Manager lives by (or should live by): Never triple-constrain a project!

How do you communicate that to the project sponsor?

Still working on that one ...

In our project at Company X, I would say the project is pretty close to being triple constrained.

1. Cost: The company outlet is severely restricted in how much corporate will allow them to spend. However, this is the constraint that I see giving the most.

2. Quality: They manufacture airplane parts and as such, certifications, quality standards, FAA approval, Boeing/Goodrich approvals, and so on and so forth down the line, are not optional. However, this constraint does give in aspects such as repainting, purchasing new equipment, etc, due to time and cost respectively.

3. Time: When the lease for the old place is up, it's up. The building will be reclaimed by the landlord and Company X must be gone.

Working on a project with so many high-risk constraints brings some greater measure of stress, but also an opportunity for the Project Manager to shine.

Thus, my work partner and I have been using the juggle-swap-cut-insert method to keep priority tasks in the forefront, to keep team members focused and motivated, and to convince function managers to stop sliding tasks out (they used up all the available slack in the first three months of the move, much to our chagrin, and contrary to our advice and urging).