Top Posts & Pages
Join 2,897 other subscribers
formerly of Professional Project Services, LCC
Announcing the release of Leveraging Business Analysis for Project Success, a new book by Vicki James, PMP, CBAP, PMI-PBA.
Only 39% of project today are successful. Nearly half of the projects that fail, fail because of “poor requirements management” (PMI 2014). Leveraging Business Analysis for Project Success explores the role of the business analyst in setting a project up for success. It informs and educates project managers, sponsors, and organization leaders on what is necessary for project success. It goes beyond requirements management in exploring the how the business analyst can contribute to increased profitability through project selection, scope definition, and post-implementation evaluation. The reader will learn about the history of business analysis, professional organizations and resources to support the profession, and what to expect from the business analyst at each phase of the project lifecycle as presented in a case study throughout the text. Project leaders will better be able to support the business analysis needs of the project by understanding the skills, expertise, tasks, resources, and time needed to do business analysis right and maximize the return on investment for each project.
Leveraging Business Analysis for Project Success is available on electronic or print format on Amazon or directly from the publisher, Business Expert Press. Educators may request an evaluation copy through the publisher website.
Please contact Vicki at firstname.lastname@example.org if you would like more information regarding this publication.
There is an ongoing confusion in the world of project management regarding the Work Breakdown Structure (WBS); should it be deliverables based, activities based, or a mix? For instance, Microsoft Project refers to line items as tasks and assigns a WBS number to each task, yet according to the Project Management Body of Knowledge (PMBOK) it is “…a deliverable-oriented hierarchical decomposition of the work to be executed…to accomplish project objectives and create required deliverables…” (PMBOK 4th Edition, page 116). I have found many reasons why a deliverables based WBS is preferable to provide benefit to project planning.
You must first define what you need before you can define what you are going to do. All tasks that we perform are in support of a specific deliverable. I’m going to use the analogy of cleaning the kitchen to make my point. You can ask your (kid, significant other, housekeeper) to “do dishes”. However, you are likely to be disappointed in the end result if the dishes are clean yet the counter and floors are dirty. Going back to our PMBOK definition, a WBS for the intended result may look more like:
1. Clean Kitchen
1.1. Clean/stored dishes
1.2. Clear and clean counters
1.3. Clean Floor
* “Clean” and “clear” are used as adjectives in this context
From here we can go from the WBS to defining and planning the activities that will provide the expected outcomes (or deliverables).
A complete WBS will help ensure that all deliverables are defined and agreed to by the sponsor. Think of the software development project where the deliverable of a training program is not articulated as in, or out of, scope. If it is not listed as a specific deliverable in the WBS then it is not in scope as it was not purchased by the sponsor.
A WBS presented at the appropriate level is a much more concise way to agree on the work of the project team. Take a second to review the Clean Kitchen WBS above. How many tasks can you identify in order to ensure a quality deliverable? I can list about 10, however, none of these add value to scope definition itself, but they will help the team ensure quality delivery of the product. A task of “drying dishes” helps the team guarantee that stored dishes will be dry and free of water spots.
With the mention of “team” I want to make sure I discuss the development of the WBS. This is not something that the Project Manager and/or Sponsor can do in a vacuum. While the highest level of the structure may come from the sponsor’s scope definition, it takes full team participation to get all of the team’s deliverables defined. Some completed items may be presented directly to the sponsor, but many will delivered only within the team (test plan, design document, etc). When working with teams to develop WBS’s I ask team members to think about their personal deliverables to support the overall project. Next I ask them to think about what deliverable they need from others. This isn’t done as a brainstorm, but rather individual lists. The lists are then compiled and reviewed as a team. Some items will be found in duplicate and additional items will be identified as all team members review the context. Team members can ask for and provide clarification on the expectation and need for each deliverable and finally identify dependencies amongst the items. This information provides a complete basis for task identification, sequencing, estimating, and schedule development.
Another excellent WBS Article, with special mention of WBS Chart Pro, an awesome tool – http://projectsolversblog.com/2011/07/05/benefits-of-the-work-breakdown-structure/