It's good that summer is in full swing, vacation customers, and you can theorize. Today we have an article on what a WBS project is and why it is needed. Experienced RMs - skip, nothing new will be there. Beginners - read without fail.
What is a WBS Project
The WBS of a project (aka Work Breakdown Structure) is the division of a project into specific results that must be achieved to achieve the goals of the project.
As a rule, the project itself is indicated at the top level, under it (at the first level) - the main results, each of which, in turn, is detailed, that is, the next level is always less than the previous one in terms of work and, as a rule, includes 2 or more packages of work. At the same time, different branches of WBS can have a different number of levels depending on the desired degree of detail.
In words, as always, little is clear, so a favorite example with repairs (the picture is large, for a detailed view of it it is better to open in a new tab):
At the end of the post there will be links to download this and other WBS examples!
It is important to understand that WBS collects the results of work, and not the tasks that need to be performed to obtain these results.
In the classical approach, all WBS blocks (the so-called Work Packages) are numbered, but in my life I have seen such responsible RMs literally several times. As a rule, I myself do not want to be lazy to number - I just do not see the point, since after the planning is completeD, I use WBS as an operational management tool, and when numbering it becomes more difficult to maintain the correct integration in the project.
Why you need WBS
WBS is an extremely useful thing in project planning and here's why:
WBS is, if not the only, but definitely the most effective way to visually reflect the entire scope of the project.
WBS focuses not on the process but on the expected result, and creates the necessary "message".
Ideally, the customer or his representative and the entire team participate in the development of WBS, which allows a) to ensure a common understanding of the results of the project and its scope b) to see the importance and contribution of individual elements to the overall result
With the help of WBS, you can clearly justify the need for finance or human resources, since it is much more difficult to object to a specific described volume than to "yes, what is there to write a system, put a programmer and that's it."
WBS helps to prevent risks and changes or at least significantly (very significantly!) reduce their probability and impact, since this is where many previously non-obvious things will surface and "and we wanted something completely different" (and so it should be, for this the tool is intended).
At the WBS level, it is already possible to define and agree on project milestones (both for decisions on the continuation of the project after the next stage, and for controlling the cost of human and financial resources).
Already at this stage, it would be good to convey to the customer your position "If there are no tasks in WBS, they are not in the project".. Firstly, everyone will try a little more when developing or when agreeing, and secondly, you will have a good leverage over the future.
WBS Grouping and Decomposition
The first question that arises at the beginning of the creation of WBS is how to group the elements of WBS, according to what principle?
The method of grouping, as a rule, is chosen depending on the project, the main criterion here is to make it clear to you and the team.
Classic WBS grouping options:
- According to the stages of the project life cycle (for example, the results of the planning, analysis, development, acceptance phases, etc. are separately described) - this is the simplest and most popular approach, especially if the project goes according to the approved process and everyone understands what should be at the output of which phase.
- According to the high-level results of the project (the project is divided into key results, for example, a ready-made system, trained users, developed regulatory documentation, coordinated use of the system with government agencies, etc.) - I most often use this option, I like to see specific results of the project and, in my opinion, this format is better understood by the customer.
- According to the organizational structure (for example, you, the customer, the contractor (s), etc.) - this option is convenient when you need to strictly delineate responsibility for the results of work.
- About deadlines (for example, by quarters) – if binding to deadlines is critical for the project.
- By technical areas (production, marketing, procurement, etc.)
- By sources of financing (what part of the results is achieved for what funds or for the budget of which year, for example).
- By country (I once saw this on just one of the international projects, and it seemed extremely inconvenient).
- In a word - you can come up with any of your own options, if only it were convenient.
The second favorite question of a novice PM is to what extent should WBS be detailed? It's funny, but there is no right answer to this question. The degree of decomposition depends on both the size and type of project, as well as the amount of time you can spend working out.
Therefore, the answer is very simple – when planning a project and developing a WBS, you just need to decide how much work at the lower level is acceptable for you so that you can control it. Too large tasks are bad, since there will be no understanding of the real picture, too small ones are also bad, since it will become more difficult to find time for control (for example, if you monitor the result once a week - there is no point in beating the task for one-day results, you can still check only in a complex).
When preparing for the PMP, the following average recommendations are given in the book of Rita Malkahi:
- For small projects – 4-40 hours,
- For medium-sized projects – 8-80 hours
- For large projects - depending on the scale, but preferably no more than 300 hours.
- In life, such an ideal balance cannot always be found, so WBS includes both small tasks, the result of which is critical for the project, and large ones. So, for example, in the example with repairs, there is both "closing the contract with the current housing and communal services" lasting a maximum of 30 minutes (I have a housing office on the 1st floor sitting in the next entrance), and plaster on the beacons, which will take several days (but I am comfortable with this, since I still cannot control the intermediate result or somehow seriously affect the drying rate of the plaster).
In my work, I personally try to focus on the bar "8 hours at the lower level of WBS".
The simplest criterion by which you can check that you have reached the "bottom" of WBS is the ability to assign a specific task to one performer to perform a specified package of work. If there are several performers and it is impossible to single out a single responsible among them, then it means that it is necessary to decompose further.
By the way, decomposition can go either from the top down (we detail high-level results) or from the bottom up (we have a disparate understanding of individual tasks, and we assemble them into higher-level ones to facilitate understanding and management).
The third question that reflects the trends of the time is what to do if the project is performed according to an agile methodology and you get the results iteratively?
There is no correct answer either, but there are options:
- Reflect iterations as a way of grouping (each iteration or sprint goes as a separate block in WBS) is useful if the results of sprints are known in advance.
- Breaking each of the results into iterations is convenient if you do the entire volume at once, and in the future only improves and details (but here you need to understand the scope of the project very well, which is not so often with agile)
- Use a regular WBS and refine it for each iteration (that is, the number of WBS will eventually be equal to the number of iterations)
- Just use regular WBS and limit yourself to that level of detail.
- Any other option that gives you the right degree of understanding and detail.
WBS Development Tools
The only rule here is to develop in what is convenient. If you have some kind of charting tool – great, if not – any other one will do, for example, Mind Manager, Excel, MS Project, Visio or any online analogue.
Over the past couple of years, I have moved from diagrams to mind maps, in my opinion, it is very convenient to form the structure of work there because of the flexibility of the tool. The most unfortunate choice, in my opinion, is Excel or MS Project, since they reduce the creation of WBS to working with lists and do not give the necessary visibility.
A typical mistake of those who do WBS in MS Project is to simultaneously try to describe the results and indicate dependencies (in the most severe cases, also labor intensity and resources). The goal of WBS is to get the full content of the project, not to close the planning task in one fell swoop. And it is so easy to miss something, since the presentation in MS Project is not visual.
WBS Dictionary
WBS Dictionary (aka IBS Dictionary) is a description on the A4 page (or more) for each package of works, including the code of the package of works, its name, a detailed description of the result, the criteria for acceptance, responsible (this is probably the most valuable in the dictionary), limitations and assumptions and in general everything that seems useful to you.
I myself in my life used it literally 2 or 3 times, too time-consuming thing, especially in very dynamic software development projects. In some construction or energy sector, probably, there is nowhere without it.
That's probably all you need to know about creating and using WBS to get started. Good luck!
P.S. And yes, an incomplete, insufficient and not quite correct WBS is still much better than its absence.
You can download a package of examples of real WBS from various projects for only 199 dollars. After payment by e-mail, you will receive an archive with WBS for three real projects and – a bonus! - WBS of the post's repair example, which already has convenient formatting set up to build your version. The package includes WBS for projects of different types - creating a new IT system from scratch, finalizing an existing system and migrating from one system to another. They also have a different focus and a different level of detail so that, after reading the WBS examples, you can make your WBS the one you need.
All WBS files are presented in both the original mmap format (opened in Mindjet MindManager) and high-resolution jpg in case you do not have MindJet installed. Take advantage of other people's experience and save your time, it costs much more! Download examples, study them and start building WBS for your project based on best practices right now!
No comments:
Post a Comment