Make a List of the Jobs to Be Done
How do you create an effective work breakdown structure? A Work breakdown structure (WBS) is a powerful tool for improving your project success. An effective work breakdown structure is an informed list of the jobs for your project. You can think of a work breakdown structure as a map of the jobs to be done to complete the project. You can use the map to guide yourself, guide your team, and guide your stake holders. You can use your work breakdown structure to help understand time and budget requirements. You can also use your work breakdown structure to get the right people on the project. Your can also review your work breakdown structure with a mentor to help you identify potential risks or surprises. In How to Run Successful Projects III: The Silver Bullet (3rd Edition), Fergus O’Connell writes about making effective work breakdown structures.
Key Take Aways
Here’s my key take aways:
- Your list of jobs is your project plan. It effectively shows the work to be done.
- Make a list of the jobs to be done to get to each milestone. Chunk it down so you can map out paths to each milestone and demonstrate incremental progress.
- The closer the milestone, the more detail. The jobs for the current milestone should be more detailed than the jobs for the later milestones.
- Identify serial type jobs. A job can be serial in nature where Job A must be done before Job B can start.
- Identify parallel type jobs. A job can be parallel in nature, where Jobs A and B can be done at the same time.
- Identify groups of jobs on the critical path. A job can be grouped in nature, where a number of jobs have to be completed before Job A can be considered complete.
- Use the list of jobs to steer the project. The list of jobs can help you map out a path to completion.
- Make jobs explicit. If you put them on the table, you can make better estimates and account for actual skills required.
- Your job list is a living thing. Evolve it as necessary.
I think Work Breakdown Structures are incredibly important. If you don’t know the jobs that need to be done, you’ll get surprised. If you don’t know the nature of the jobs, you won’t know the right people to have on the project team. The more you can understand the nature of the work for the journey ahead, the better you can respond to the challenges you’ll run into. Another beauty of a work breakdown structure is that you can review it with people that have made the journey before you and get their input. One of my mentors was very good at reviewing my work breakdown structure and finding things that would surprise me downstream.
I’m a fan of Wikis for building work breakdown structures. Wordocs and spreadsheets work well too. The key is to have something that’s easy to use, easy to share, and easy to update.
Map Out the Paths to the Milestones
According to O’Connell, you start by mapping out the jobs you need to complete to reach your milestones:
Projects are exactly the same. The very first thing you do when you start a new project is to make a plan. You may only be able to write down the first one or two tasks, but you’re already moving forward. Get yourself to that first horizon and then take stock of what needs to be done next. You will always know in quite a lot of detail what lies between you and that first horizon, even though there will inevitably be surprises. For the rest of the project it is enough that you have mapped out in broad terms the remaining milestones (horizons) along the way.
Postpone Predicting the Remainder of the Project
Postpone predictions about the later part of your projects as much as you can. O’Connell writes:
There will come a time when you have to predict the remainder of the project, but try to postpone that moment for as long as possible, until you have gathered as much information as you can upon which to base your decisions.
Use Your Plan as Your Compass
Your plan is your compass. O’Connell writes:
Your plan becomes the compass by which you steer the project. As you reach each horizon, you check the land and then push to the new horizon.
Write Down the Jobs You Know Have to Be Done
The most important thing is to write down the jobs that have to be done. O’Connell writes:
The list can be in any form. It can be an actual list, like a shopping list; it can be put on to a computerized project planning package — we do this for a lot of our software project; it can be a chart. Many large companies have a defined standard and layout for a project plan, and you may have to follow this. It doesn’t matter a toss what it looks like. It doesn’t matter that you don’t yet know all the jobs that need to be done. Write down the jobs that you know have to be done to get the project started and leave the crystal ball-gazing until you feel yourself better informed.
You Will Never Feel Entirely Happy About Your Predictions
According to O’Connell, you’ll have to make a lot of predictions that you won’t be comfortable with, but that’s the nature of the job:
You will never feel entirely happy about predictions when you are forced to make them. In some situations, for example in business or in the military, you may be forced to make predictions and know that in the first case, maybe your job is on the line, and in the second, lives are on the line. No doubt about it; a lot of projects are about serious things, and a lot of project leaders make decisions which do affect careers and/or lives.
Make Jobs Explicit
O’Connell suggests making jobs explicit:
One other thing about jobs: jobs must be explicit. Think through or write down the sequence of events that must happen for the job to be carried out. If you cannot do this, or if you fudge it, then the chnaces are you’re not being explicit enough. Often this is because what you are treating as one job is in fact a series of jobs. What you should do is to break it down further. Remember that jobs can be: (a) serial in nature — Job A must be done before Job B can start; (b) parallel in nature — Jobs A and B can be done at the same time; (c) grouped — Job A really consists of a number of jobs which all have to complete before Job A can be considered complete. (Watch these little guys — they’re the ones that will get you if you’re not careful.)
Checklist for Your Work Breakdown Structure
After you’ve drawn up your basic list of jobs, O’Connell suggest checking the following:
- Resources (equipment, products, services, facilities) required.
- Skills required and whether these imply hiring and/or training.
- That you have listed explicit, clearly identifiable milestones.
- Timescales, costs, and budgets — show how you arrived at your estimates.
- That you have explicitly stated what assumptions you are making.
- That you have explicitly stated what dependencies there are on things which are not directly under your control.
- That you show explicitly who is responsible for what.
- That you have given some thought to what the really high-risk areas are.
Write, Review, Rework, Sign-off
Writing your list of jobs is cyclical. O’Connell writes:
The familiar cycle of write, review, rework, sign-off is what you need. I try to make it a rule never to commit to delivering anything until the low-level design (LLD) is complete. Most customers are happy with this, or if they insist on a fixed-price, cast-in-concrete estimate sooner than that, you make it clear to them that they are going to pay a heavily-loaded price, so that you can allow for your own risk and exposure.
Your Job List is a Living Thing
Your list of jobs is a living thing. O’Connell writes:
Your job will will be a living thing, constantly changing to adapt to circumstances. New jobs will appear, jobs will complete, jobs will be found to be unnecessary and jobs will end up differently from what you originally envisaged (This is why a computerized project planning system is very useful.) All these changes are good, routine stuff. Your list will be highly detailed for the short horizon and less so for the longer one.
- Work breakdown structure (Wikipedia)
My Related Posts