Planning the Analysis Phase: using a Work Breakdown Structure (WBS) and a WBS Dictionary

Featured
49919 Views
0 Comments
18 Likes

In order to plan the analysis phase of a project, the business analyst (BA) identifies all the analysis tasks and the associated risk, cost, time and resources. The BA then uses this information to develop a schedule for accomplishing the analysis. To assist in this planning, the BA can use a renowned project management tool: the Work Breakdown Structure (WBS).

The purpose of this article is to show how a business analyst can use a Work Breakdown Structure (WBS) for planning the analysis phase of a project; note, this is a follow-up article to my previous publication in Modern Analyst entitled: The Initial Conversation with Your Project Manager.

The WBS is a hierarchical structure used to decompose all the tasks associated with a project. These tasks are the basis for developing a project schedule, e.g., Precedent Diagram, PERT Chart and/or Ghant Chart. In addition, project managers use an Organizational Breakdown Structure (OBS) along with the WBS to map an organization’s resources with the tasks and to setup control accounts for the project. However, this article is limited to the WBS use by the BA in the context of planning the analysis phase.

Some History

The Work Breakdown Structure (WBS) originated with the United States Defense Department in 1957 and continues to be a Department of Defense (DoD) standard to this day. If you want a project contract with the US Government, a WBS is a most likely a requirement. Thirty years later, the Project Management Institute (PMI) adopted the WBS for planning all types of projects (public and private).

 The Work Breakdown Structure

 The WBS is a hierarchical graphic method for decomposing project tasks (parent-child tree branches) into small work packages of 40-80 hours of work. It has several design and guideline principles: 

  • Decompositions consist of at least 2 parent-child tasks. A decomposition with only one child is really the same as the parent.

Figure 1. Do Not Decompose a Parent Task into one Child

Figure 1. Do Not Decompose a Parent Task into one Child

  • Parent-child tasks do not have to be in sequence; the objective is to capture all the tasks – 100% rule. 
  • The lowest level parent-child tasks for each branch are work packages. These work packages are the basis for the schedule. 
  • Parent-child tasks are action oriented using an “action verb-optional qualifier-noun” format.

 WBS Decomposition Process

Figure 2. WBS Decomposition Process 

  • Risks are derived from task assumptions, constraints, and possible resistance to build a risk register 
  • Cost(labor and expenses) plus contingencies to develop a budget 
  • Duration (estimated work time to complete a task) plus contingencies to develop a schedule; note a schedule considers when resources are available to work tasks. 
  • Resources (types and number)needed to complete the task to develop a schedule 

Below is a partial generic WBS (Figure 3) for the top-level tasks of an analysis phase of a software project. Note that I started the reference scheme with the number 2.1; this was subjective. Most people would have used the number 1.1.If you are interested in a completed generic WBS see references[1].

 

Figure 3.Partial Generic WBS for a Software Project Analysis Phase

In planning the analysis phase of a project, the business analyst develops a Requirements Work Plan (RWP). The plan contains a schedule, cost, and resources needed to conduct the analysis. To help produce this document, the BA can utilize a Work Breakdown Structure (WBS). Just as the project manager develops the project plan, the BA uses a WBS. However, instead of covering all the project tasks, the BA covers only the analysis tasks; see Figure1.After the BA team develops the WBS and WBS Dictionary, the BA team constructs the analysis schedule which the project manager typically incorporates into the project plan. To facilitate this incorporation, use the same project schedule software as the project manager.

Figure 4 depicts the stages of developing the RWP. Note that the RWP includes an analysis risk register, budget, a proposed schedule, and resources needed for the analysis phase. The WBS and WBS dictionary are the basis for all this information.

RWP Development process
Figure 4. RWP Development process

The BA presents the RWP to the project manager and sponsor for approval. The main topic being the time and money required for the analysis phase. If the project manager and sponsor approve less/more time, money, and/or resources, the BA adjusts the analysis risk register and schedule accordingly. With approval, the project manager allocates the needed resources. The BA then adjusts the proposed schedule based on resource availability and proceeds with the planned analysis.


Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BP Messentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) International and the International Association of Facilitators (IAF).

Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst. He can be contacted via – www.baquickref.com.


1. http://monteleonepmp.com or http://www.baquickref.com/

 



 




Copyright 2006-2024 by Modern Analyst Media LLC