Tag Archives: wbs

Use YOUR WBS to Build Team Strength

Use YOUR WBS to Build Team StrengthWe Build Strength (WBS). I realize you know that from a traditional project management perspective the correct words behind the acronym WBS are work breakdown structure. Now since you are going to follow best practices and create a WBS as you plan your project; why not consider using it as a team building exercise?

Team building exercises can be really fun and exotic. You can go learn how to country western dance to build your synergy as a team. You can expand your comfort zone by going sky diving or learning to race cars. Not every project team has the time or money for adventure. You can (and should) use regular project activities as team building events.

Consider the creation of the work breakdown structure (WBS). You know that you should not sit in your office constructing the WBS by yourself. Let the people who are doing the work define the work. Let them see how their deliverables begin to translate to assignable activities. This is an excellent opportunity for building trust and relationships through teamwork. Here are the steps you can take to engage your team in the creation of the WBS.

1.??? Invite the appropriate participants. This means someone from each group participating in the project. (Hint: It is not a bad idea for your key sponsor to observe parts of this activity so that they too gain an understanding of how the work gets defined.)
Note: This could be a very long work session or a series of work sessions. Schedule these sessions with an awareness of your team members availability and other work commitments.

2.??? Review the scope. If this is the first time the team is hearing the formal scope, this will result in lively discussion. Encourage questions and ?what-if? scenarios. If you discourage your team from openly discussing the scope, you have just shut down communications.

3.??? Ask individuals to work together to identify the key deliverables. Use the ?sticky note? or tear sheet approach. This means give the team post-it notes or similar pieces of paper that can be written and moved around. This allows the team to write deliverables (and next activities) on paper and position them at various locations on the proposed WBS.

4.??? Once the deliverables seem firm, have the team work on the lower levels. Have the group or groups that own each deliverable (or a portion thereof) use the ?sticky note? or tear sheet approach to break the work down. Encourage detail. You want the end result to be assignable and measurable work.

5.??? Make sure that good notes are taken during this session. What we construct during one meeting makes perfect sense at the time. Later, details may be forgotten.

6.??? Take some time away from the WBS and then revisit it. Walk through it again and make sure it still makes sense. Have team members present their sections to the rest of the team for review and discussion. This helps build an understanding of the entire work effort.

Now you have built a traditional work breakdown structure that the team understands and through your work together you have a built a stronger team. That is how you use your WBS to build team strength!

Work Breakdown Structure Training From Dick Billows

In line with my previous post about supporting other project management trainers who do good work, I bring you Dick Billows.

This video on the Work Breakdown Structure shows that his approach is in line with my philosophy.? It is in line with the training I provide through WBS Coach and pmStudent e-Learning.? I haven’t experienced his training first-hand, but based on this video I can tell the information you would get from Dick is going to be quality.

So watch this short video from Dick and check out his links below the video if you are interested in training.? Regardless of whether you choose my training or Dick’s, or anyone else’s, be sure you are getting trained by someone who knows what they are talking about and presents the training to you in a way that works for you.

http://www.4pm.com/classes/videoplayerwbs.htm

New Project Managers: How To Break It Down Into Manageable Parts

New project managers send me this question a lot, and I think some people struggle with this because they jump right to task definition with a leap directly over figuring out what to deliver first.

When you start a new project and need to break down the work into manageable pieces, how do you go about it and what are the things to watch out for?

In this video, I discuss the mindset I use when facilitating my teams through breaking down our work. ?If you want to learn more about my Work Breakdown Structure course, you find out more here.

Project management training for your ears

The audio book is now available.

Check out the product page and see if it’s for you. As always, you can email me anytime with questions.

http://wbscoach.com/audio/

Thanks!

Josh

P.S.? I shortened my email address to just “josh @ pmstudent.com” because my quirky last name was giving a lot of people trouble.

Free Report: Top 7 WBS Mistakes Project Managers Make

7-mistakes-imageThe Work Breakdown Structure is one of those tools in project management that in my experience gets used incorrectly quite a bit.? That might be due to how it gets glossed over in many textbooks, or how many people jump right into building one without understanding the fundamentals clearly.

It could also be due to illustrations in the PMBoK Guide text which display WBS Graphics that are completely wrong based on my experience.

Either way, I think it’s a big problem.

I just released a free report that relates heavily to my new training course, WBS Coach.? In the free report, I point out the top 7 mistakes I see other project managers make (and that I have made myself) and discuss them in detail.? There are other mistakes I’ve seen, but I hold myself back to just the top 7 for this report.

You can get access to the report here:

http://wbscoach.com/7-mistakes

P.S.? My materials are not made for test preparation of any kind; they are designed to teach proper WBS techniques and fundamentals, as well as tool-specific video demonstrations, etc.? My method most closely aligns with the DoD standard but is scaled for any size project.? Where I disagree with PMI or other institutions I point it out specifically in the materials.

Reader Q&A: The WBS and Cost

I wanted to share an email question I received through a Twitter contact of mine and my response.? Feel free to chip in with your own insights!

photo by Tracy O

photo by Tracy O

Question:

I hope you don’t mind me coming to you for advise and help with Project Management. I have this one question which I keep pondering on. In what way would you say that monitoring, planning and controlling project cost with a budget and organizing and planning a project using the WBS help or support one another?

Thanks!

My response:

Glad we connected on Twitter!? In my projects, the WBS is one of the key things that helps me with planning and monitoring costs.? The WBS is a prerequisite.? When I have a WBS, I can look at it and see where I should have charge codes set up for project staff, and where I should be reporting project costs.? Usually there is a specific level of detail that is relevant to various people.? The sponsor may want to see costs at level 3 of the WBS, and I may be interested in a little more detail at level 4, and the other project managers who work with me may be looking at level 5.? You may have specific stakeholders who only care about level 3 cost reporting for a particular element of the project, etc.

When putting estimates together, it’s important to first have a clear idea of what your scope is, and much of that comes from the WBS.? Bucket your basis of estimates this way, schedule, etc.? The iron triangle means that scope, cost, and schedule are integrated.

Monitoring and controlling your projects through status reports, EVM, etc.?? can really only done effectively by keeping in lock-step with your WBS structure.

Add your thoughts by leaving a comment for our reader below!

Lessons Learned from Anita Wotiz

Anita Wotiz is the guest blogger this week over at the UCSC Extension in Silicon Valley Project Management blog. She published great post titled “An unrepeatable success?” Read it here.

It was great to hear about the project, specifically the lessons learned and trying to relate them to my own experience.

I wouldn’t write the first set of factors off as things that can’t be duplicated. Sure, it’s easier in some cases because these things fall into your lap, but these can be influenced to some extent. Paraphrased:

  1. Good team (competent, cooperative) –A PM can sometimes influence who works on their project, and ensure they are competent. Cooperation and team spirit is largely influenced by the PM, in my experience.
  2. Exciting work –Not every project is glamorous on the face of it, but the PM can and should figure out how to position the product being created to the team by selling them on how much value it will add for the end users, and how their individual and team contributions make it possible.
  3. Full access/utilization of previous work –Again, this usually doesn’t fall in your lap, but it’s amazing to me how many project managers don’t spend enough time during the planning phases trying find previous work that can be re-used. Many seem to want to re-invent the wheel with each project.

As for the other factors, paraphrased:

  1. Don’t constrain the project to a preconceived solution –Three points; I see this so many times, where the sponsor and stakeholders have a preconceived notion of what the solution should look like before they even fully understand the problem! Granted, sometimes there are real constraints that are necessary. I think it’s human nature to start coming up with possible solutions very early in the process, and difficult to avoid. Personally though, I’ve found the best results come from forcing yourself to focus strictly on the need/problem during early planning, including the charter, preliminary scope statement, and initial requirements gathering processes.
  2. Good WBS creation and decomposition, bottom-up estimating –Bingo! This agrees completely with my experience about what helps make a project successful. I’ve had a lot of luck in the past using a delphi-style method of estimating, where we go through each task in a room with the experts who will be performing them, and each person writes down an optimistic, likely, and pessimistic point estimate. I take all the estimate sheets afterwards and roll them together, ask about any outliers, and can usually come up with pretty good ranged estimates with a solid grasp on standard deviation and confidence levels.
  3. Management cost/time buffers available –I agree that it’s critical for the sponsor/customer to realize that buffers are there for a reason…they are not just downtime or waste, they are crucial components of a good project that can handle the inevitable risks that will arise.
  4. Collaboration –It sounds like Anita was able to get the whole team to collaborate on scheduling by using post-it notes on the wall. I think that is excellent, although alternative methods may work just as well to have the team collaborate on schedule and task dependencies.
  5. Iterative Development –This is a benefit I’ve used and seen in my projects too. If you can push out iterative releases that are functional, you can start getting feedback from the customer and make subsequent development based off a real foundation, instead of a theoretical one. Writing code to specs is one thing, but if you can immediately test it against an initial release of the pieces it has to integrate with, you’re way ahead of the game.


project management basics

Project Objectives and Deliverables (Or “how to WBS”)

Lately I have been working on thinking about the best way to go about project planning, especially in terms of objectives and deliverables. Based on my experience at several companies and some independent research, here are my current thoughts on the subject.

Hierarchy

I’m fairly convinced that in most cases, this is an effective hierarchy to observe:

Objectives >> External Deliverables >> Internal Deliverables >> Activities

Additionally, I have seen some people classify their deliverables by type:

  • Project Deliverables
    • Usually deliverables to external stakeholders
  • Planning Deliverables
    • Management plans, scheduling and budgeting, project artifacts, etc.
  • Activity Deliverables
    • Status reports, meetings and reviews, etc.

I’ve never done this before. Usually in smaller projects the only deliverables that get identified are the “Project Deliverables” specified in the first bullet. I can certainly see the benefit of explicitly identifying the other types though, and differentiating them. It would certainly help when monitoring the health of the project to have these identifying markers available. After all, not all deliverables are created equal. If you miss a status report, it may not be a big deal. If you miss a project deliverable however, you are probably in hot water.

Traceability

Full traceability is important to ensure that the following possible errors do not occur:

  • Activities that do not support a deliverable (drop the activity or add/redefine a deliverable)
  • Deliverables that do not support an objective (drop the deliverable or add/redefine an objective)
  • Objectives with no supporting deliverables (drop the objective or add deliverables)
  • Deliverables with no supporting activities (drop the deliverable or add activities)

There are many ways to develop and maintain traceability. Tools exist such as Telelogic DOORS, etc. Alternatively, you could use an Objective-Deliverable Breakdown Structure (ODBS?) to represent this graphically. I’ve used something like this in a spreadsheet format before, but you could easily create a more graphic representation.

Figure 1 is an example of what this might look like. First is a spreadsheet representation, and second is the same structure represented graphically. You can see there are 4 project objectives. All of the project objectives have at least one external deliverable, except PO-4. That objective apparently has no deliverable with an external stakeholder. My guess is that would be internal project management processes, such as management plans, etc.

Most of the external deliverables have an internal deliverable that supports them. PD-05 is an exception. This external deliverable requires no extra internal deliverables to support it. This may be a fairly independent external deliverable that only requires one set of activities to produce, without handing off an internal deliverable from one segment of the project to another.

Figure 1

Traceability should go down to the activity level, even if the links are in the background or tools and not displayed on artifacts like these.

Process

Here is the process in more detail:

  1. Define Project Objectives
  2. Identify External Deliverables, linking to Project Objectives
  3. Identify Internal Deliverables, linking to Project Objectives(required) and external deliverables(case-by-case)
  4. Find gaps or orphans using the links between objectives and deliverables described above
  5. Make any necessary changes based on gaps or orphans found
  6. Identify high-level Activities (groups of work packages) for each deliverable
  7. If activities will be required that do not trace to a deliverable, evaluate if a deliverable must be added to accommodate
  8. Any added objectives, deliverables, or activities must trace up and/or down the hierarchy
  9. After all of the objectives, deliverables, and high-level activities are well established, then it is time to start defining and estimating work packages, dependencies, resource utilization, and other scheduling concerns.

Please let me know what you think! How do you go about this on your projects?

Point 11 – Attribute Results to Processes

This may be the most controversial point, but in my opinion it is aligned with the rest of Deming?s philosophy nicely, and I agree with this point totally. In the US especially, Management By Objectives (MBO) is very much the status quo. I?ll give a short explanation of my opinion from an operational standpoint first before relating this concept to project management.

In MBO, standards are set for a particular process with the intention of evaluating employee performance by them. Performance in relation to the standard weighs heavily (and is sometimes the only factor) in merit increases, bonuses, etc. A standard example would be handle times in a contact center environment. If the standard handle time is set to 3 minutes, and you are taking an average of 4 minutes, it is said the employee is performing poorly. This paradigm assumes that the measured metric (handle time) is the full responsibility of the employee. Pros and cons of this management philosophy:

Pros

  • Easy to set expectations
  • Easy to quantify
  • Easy to base performance evaluations on

Cons

  • Tends to move the focus to being ?at? standard
  • No focus on process variability
  • Tends to make the standard the ?only? performance measure
  • Provides little incentive to improve processes when the standard is being met
  • When defining standards, operational leaders tend to lean towards lower standards in fear of not meeting them
  • Propogates the ?carrot and stick? approach where fear usually wins out as the strongest motivator
  • Discourages educated risk-taking and experimentation with processes, because it might throw people ?out of standard? temporarily
  • Discourages employees from helping each other by encouraging detrimental internal competition
  • Forces employees to try and acheive contradictory goals (?I want to provide great customer service and spend the time the customer requires, but if I do that the way I know it really should be done, I?ll miss my standard and get written up.?)
  • Employees and managers may be motivated to skew results so their numbers look better
  • Moves focus from customer satisfaction to ?covering my butt.?

You can probably tell that I don?t like Management by Objectives. To me it seems like the easy way out, and very much the wrong approach. Deming would say that 90% of defects in any situation can be related to poor systems or the lack of systems in place. Most people want to do a good job and will follow a process when it is well designed and they have the ability to provide input for it?s development and improvement.

Let us discuss this point in terms of estimating project tasks for duration and cost. In the MBO paradigm, what usually happens is that a project team member is given a piece to plan and estimate. Many times there is no process for them to follow in making their estimates. The project manager assumes they are the SME and know how to estimate. The PM may not really have a good idea of how much time they will be able to devote to their project work, alongside all their other projects or daily duties. In many cases an experienced team member is going to throw on a lot of slack time because they are in fear of missing their estimated deadlines. In any case, an MBO mindset is going to lead everyone to blame individuals for mistakes. It doesn?t necessitate a focus on improvement.

What would a Deming approach change? First, there would be a process in place to help guide estimates, evaluate performance to planned estimates, and go back to figure out why estimates were wrong. Another option might be to change the resource load so that a team member can devote all or most of their time to a project for a limited period of time, thereby reducing the cycle time on their deliverables (for your and other projects) and allowing them to more easily estimate in terms of effort required. Part of the process may be to train and guide them in doing a lower level of WBS to break things down into 4-16 hour chunks. It is going to be important in a Deming approach to evaluate tasks that took longer or shorter than anticipated. Not to place blame on the individual who did the estimate, but to find ways to enhance the process of estimating to make it more accurate in the future.