WBS

A WBS is a logical breakdown (decomposition) and representation (hierarchical structure) of the “work” required by the project. A WBS can take one of two forms: graphical or outline. The graphical form is best for communicating the top three to five levels of work activity to senior management or customer stakeholders. The outline form is best for capturing the details needed for cost and schedule development.

A WBS shows the work and any interim deliverables that are required to produce the major project deliverables identified in the project definition process. In most cases, the WBS reflects the components that make up the final deliverables and the approach (methodology) used to develop, integrate, and validate them. In short, we can say, the WBS is an organized task list.

By creating a WBS, we employ the primary secret weapon of managing large, complex projects, which is break the work into chunks and manage many smaller components. Many organizations leverage standard WBS templates to ensure any new project includes the recommended work items.

Now a days many industries and organizations routinely use the following terms in an interchangeable fashion: WBS, project plan, project schedule, and work plan. But, these terms do represent different project management elements and should not be used interchangeably. However, as with all “less than-ideal” practices, there are reasons they develop. Understanding the reasons is always helpful, and, in this case, can provide additional insights as to why projects can get into a “troubled” state.

When you think about the process for developing a schedule, determining the work (detail tasks) that is required is the first step. 

After you have identified the work tasks, you can determine what resources are required for each task, how much effort each task will take and what logical dependencies exist between the tasks. At this point, you can begin to construct the first of several iterations of a project schedule. But if you project scheduling software such as Microsoft (MS) Project you might encounter a few problems. Here’s a common scenario:

·        You are told to build a work plan for the project.

·        You go to your desk and open up MS Project and start entering and organizing the tasks that need to be performed.

·        You enter estimated durations and start and end dates for some of the key or most visible tasks.

·        You present results to your supervisor for review.

Now my question is what did you present to your boss? A WBS? It does have work tasks listed. A project schedule? It was created in MS Project. A work plan? That’s what your boss asked for. Well, what you probably have here is a high-level WBS and an initial milestone schedule summary, at best. This example illustrates how an inadequate project planning and schedule development process combined with inadequate training on the project scheduling software can lead to “terminology” confusion.  You might be wondering what are the key differences between the WBS and the project schedule?

The key differences between the WBS and the project schedule include the following:

·        Task dependencies—WBS does not show them; a project schedule does.

·        Scheduled tasks—WBS does not show when tasks occur; a project schedule shows start and end dates for each task.

·        Task assignments—WBS does not show who is assigned to an individual task; a project schedule does.

Another question that comes to our mind is why don’t we directly prepare project schedule and skip WBS creation?

The Project Management Institute (PMI) considers the WBS the most important tool of the project manager. Why?

More than any other project management tool, the WBS provides the foundation for defining and organizing the work needed to fulfil the project objectives. Through the WBS, the work to produce the targeted deliverables is structured, assigned, scheduled, tracked, and reported. Through the WBS, the work of the project is effectively represented and communicated to all stakeholders. A well done WBS accomplishes the following objectives for the project manager:

·        Manage the pieces—It provides a mechanism to manage any project size or complexity. Through decomposition, you can manage the pieces (work packages) rather than the whole project.

·        Better work definition, fewer changes—It enables identification of all necessary work for the project and only the necessary work.

·        Better estimates, better planning—It improves the accuracy of cost, duration, and resource estimates.

·        Better control—It defines a baseline for performance measurement and control.

·        Clear responsibilities—It facilitates clear responsibility assignments at both an individual and organizational level.

·        Stakeholder buy-in on scope work effort—It facilitates understanding and buy-in of the project scope, the project approach, the work effort involved, and alignment between scope and work from each stakeholder.

·        Tighter management integration—It provides a mechanism to relate the work directly to schedule, budget, and resource allocation plans.

·        Better team performance—It enables each team member to easily understand how her work fits into the overall project, how it affects the work of other team members, and to stay focused on deliverables.

·        Risk factors identified early—Through decomposition of the work, a more complete and effective risk analysis can be performed during project planning.

·        Confidence increases—When people see that the work of the project is structured, definable, and doable, their confidence level in the project increases.

Here I am ending this post. In the next post we’ll see how to create a WBS.

Project planning - Building a project plan

The first step in building a project plan is to validate the elements of the project definition document. Depending on the length of time between acceptance of the project definition and the start of detail planning, you might need to confirm that there have been no changes in the purpose, objectives, success criteria, and scope of the project with your key stakeholders.

• Validate project definition—This section should reference the project definition document and includes all required elements of a project definition document. The key task here is to re-validate the business case for the project. This is especially important if there has been a time lag between project definition and detail project planning, or if the planning exercise results in time and cost estimates significantly greater than originally estimated during project definition.

• Determine what needs to be done—This section should provide any additional details regarding the project approach (how this will be done),the targeted deliverables that will be produced, and all the work that is required to complete the project.

• Determine acceptance criteria—This information can be part of other components, such as deliverables list, WBS, project approach, or quality management plan, and might not be its own section. However, to validate that all required work has been identified and to improve the quality of
work estimates, it is best to clearly document (somewhere in the project plan) what the acceptance criteria is for each deliverable and for each project phase.

• Determine resource needs—Based upon the tasks and activities that need t o be performed, determine the type and quantity of resources needed. Resources include people (roles), facilities, and tools. These resource needs should be determined when developing the WBS with the team members who will be doing the work.

• To assist the acquisition and management of these resources, all resource needs should be documented (resource management plan). For people resources, document the role description and the prerequisite skills, skilllevels, and experiences. As part of the scheduling process, the timing of resource needs should be noted and finalized in the resource management plan. components, such as deliverables list, WBS, project approach, or quality management plan, and might not be its own section. However, to validate that all required work has been identified and to improve the quality of
work estimates, it is best to clearly document (somewhere in the project plan) what the acceptance criteria is for each deliverable and for each project phase.

• Determine resource needs—Based upon the tasks and activities that need to be performed, determine the type and quantity of resources needed. Resources include people (roles), facilities, and tools. These resource needs should be determined when developing the WBS with the team members who will be doing the work.

To assist the acquisition and management of these resources, all resource needs should be documented (resource management plan). For people  resources, document the role description and the prerequisite skills, skill levels, and experiences.

As part of the scheduling process, the timing of resource needs should be noted and finalized in the resource management plan.

Acquire resources—After the resource needs are documented, you can now begin the process of acquiring those resources. The key questions to be answered here are
• Will I be able to get the quality of resource requested?
• Will I be able to get this resource in-house or will I need to obtain it from an external supplier/vendor?
• Will the resource be available when needed?
• How will this impact my cost estimates and budget?

Estimate the work—After we know what all the work activities are, and we know what level of resource will be doing the work, we can now estimate the effort and duration for each activity.

Develop the schedule—Now that we understand the required resources and estimated effort for each work task, we are now in position to identify the relationships between these tasks and build a schedule to complete the work.

Update roles and responsibilities—This step has two parts. First, if any new role has been identified, then update the stakeholder-role description table with the name of the required role and the specific responsibilities that role has. After specific individuals are assigned to roles, the project role responsibility chart can be updated to reflect role assignments.

Second, for each significant work package listed in the WBS, map the responsibility level that each role has regarding that item. This mapping is routinely captured in a responsibility assignment matrix. This summary map is a powerful tool to help stakeholders clearly understand their roles and what is expected of them.

Update project organization—Also previously mentioned in the project definition document, this section lists all the individuals, business units, and organizations involved in the project, the role(s) each is expected to play, and an indication of how they relate to one another.

Determine project costs and budget—Now that we have our resource needs and a preliminary schedule, we can tabulate estimated project costs and a phased project budget.

Determine project control system—Specifically, we need to get agreement on how the performance of the project will be measured, how often, and how it will be reported. In addition, we need to determine how performance variances should be managed. Frequently, this information is documented in either the project plan itself, the project communications plan, and in the quality management plan.

Plan for change—All plans are subject to change. The difference with successful projects is that they anticipate the changes and establish procedures in advance to review, assess, and manage any request or any factor that affects the key performance factors (scope, quality, time, and cost). These procedures help to ensure that the right people are involved in the process and that the right people are informed of any “change”decision.

Plan for project information—There are two primary objectives of this step:
• Where will the project repository be located? Who can access it? Who controls it?
• How will changes to project deliverables be managed and controlled?

This information is frequently maintained in a configuration management plan.

Plan for issues—All projects have issues and action that must be taken to resolve them. The difference on successful projects is that they establish a process in advance to closely track these issues and establish a procedure in advance to escalate any critical issue to the appropriate management stakeholders.

Plan for quality—Another proactive management approach to determine the quality standards and policies that project deliverables and processes must meet. For planning, the significance is that additional roles, work activities, and costs will likely affect the project schedule and the project
budget.

Plan for communications—A proactive management approach to determine the information and communication needs of each project stakeholder. These needs should be determined as part of the stakeholder analysis. The work efforts associated with delivering project communications should be accounted for in both the WBS and the project schedule.

Plan for team management—Although we have already taken key steps to lay the groundwork for an effective project team by involving them in the planning process, establishing clear role descriptions, and scheduling clear assignments, there are additional steps to consider, including training needs and performance evaluation.

Plan for procurement—This step is closely linked to resource planning. If resources need to be obtained externally, then the work to manage the procurement process must be planned and added to the WBS, project schedule, and project budget.

Here’s a quick checklist that can help you to determine whether your project is planned properly and whether you are ready to proceed to execute your project:

• Have you answered all the questions in the section, “Important Questions Project Planning Should Answer”?
• Have you reviewed your WBS, work effort estimates, project schedule, and project budget against their respective checklists?
• Has the project plan been reviewed and approved?
• Was the project plan signed off in a review meeting? In person?

Project planning - questions project planning should answer

Although the process of defining a project answers some key fundamental questions to get us started, such as the following:

• Why are we doing this project?
• What is the project supposed to accomplish?
• Who are the key stakeholders? The sponsor? The customers?

It is the process of “detail planning” a project that allows us to answer the questions we need addressed to implement and manage the project. These important questions focus on both the work to produce the targeted deliverables and on the work to manage the project. Some of these key questions include the following:

• How exactly will the deliverables be produced?
• What work tasks must be performed to produce the deliverables?
• Who will do the work?
• What other resources (facilities, tools) will the team need to do the work?
• Where will the work occur?
• How long will it take to do the work?
• When will the work be done?
• How much will this project cost?
• What skills, skill levels, and experience are needed for each role? When do I need them?
• When do I need each resource? How do I get resources?
• Who is responsible and accountable for what?
• How will changes be controlled?
• How do I ensure acceptable quality in deliverables and in the process?
• How will I keep stakeholders informed, get their feedback, and what mediums are best?
• How will I track issues? How will critical issues be escalated?
• How do we handle variances? What is the threshold for senior management? What communication needs to occur?
• What risks exist? What are our response strategies?
• How will version control be conducted?
• How will project information be maintained and secured?
• How will I manage the project team? What training needs exist? How will their performance be  evaluated? How will I orient any new team member?
• If we are leveraging external resources (vendors, suppliers), how do we manage their performance?
• How will project performance be measured and reported?
• And ultimately, do I have a plan that will enable me to execute and control this project?

As we determine these answers, we capture them in the project plan. We can then review the project plan with our key stakeholders to ensure we have agreement and understanding. Next, let’s step through a typical project plan, review what each section is for, and determine how we go about getting this information.

Required Elements of Project Definition document 2

Scope

• Does project scope indicate boundaries among impacted processes, systems, and organizations?
• Is project scope defined clearly enough to show when scope creep is occurring?
• Have any external process or system interfaces that will be impacted by this project been identified?
• Has the process workflow between business units or business functions been properly considered?
• Have the organizational and geographic boundaries been clearly defined?
• Does project scope include related items that are out of scope?
• Does project scope include any other organizational or technology-based initiative that is needed to fully support the project objective?
• If project scope includes any requirements, have the requirements been properly validated?
• Have any and all project constraints been identified?
• Have any and all project assumptions been identified?
• Are there any known policies, regulations, or standards that apply to this project (such as   procurement, quality, security, regulatory compliance, and so on)?

Stakeholders

• Has the project sponsor been identified and engaged?
• Is each affected business unit and business process step represented on the project team?
• Is each customer group represented on the project team?
• Are all stakeholders identified in a project organization chart?
• Are the reporting relationships indicated in the project organization chart?
• Are project roles described and assigned to each stakeholder?
• Have we identified which stakeholders form the core management steering committee?
• Have you identified which stakeholders need to review and approve any requested changes to the project definition?

Project Approach

• Does the recommended approach explain why it is selected over the alternatives?
• Are the proposed technologies, strategies, and methodologies documented?

Other

• Are the project definition elements documented?
• Is the Project Definition document under configuration management (version control)?
• Have high-level risks and planned responses been identified?
• Have the preliminary timeline and budget been stated? Are the supporting reasons and assumptions documented?

Acceptance

• Have all stakeholders reviewed, agreed upon, and approved the Project Definition document?
• Have the project and the project manager been officially authorized?

As with all project documents, make sure you have a way to control changes to the Project Definition document and that you have proper backups of it.

Required Elements of Project Definition document 1

Required elements

Here are the must-have informational elements that should be included in your Project Definition document:

• Purpose—This section should answer the “Why?” question and clearly communicate the expected business value. It should reference the organizational objective being supported, the business problem being solved, and its relative priority level. 
• Goals and Objectives—This section is derived from the Purpose and communicates the targeted outcomes for the project. It should answer the “What are you going to accomplish?” question. 
• Success Criteria—Closely related to Goals and Objectives, this section should list the measurable, verifiable results that determine the success level of this project. This section is often referred to as Critical Success Factors.
• Project Context—Documents how this project relates to other projects within the product program and within the organization as a whole. This section should also describe how the project fits within the organization and business process flow.
• Project Dependencies—Closely related to Project Context, this section clearly documents any dependencies that could affect the results or success factors of this project.
• Scope Specifications—Clearly designates the organizational, process, systems, and functional specification boundaries for the project. This section should be a high-level breakdown of the Goals and Objectives.
• Out-of-Scope Specifications—Clearly indicates the high-level work items that are related (or associated) to this initiative but that are not part of this project to better communicate what is considered to be “in scope.”
• Assumptions—Clearly communicates the underlying basis or things to be considered true in regard to any other aspect of this document. In most cases, the Scope, Out-of-Scope, Assumptions, and Constraints sections combine to clearly define what work will be performed by this project. 
• Constraints—Lists any business event, schedule, budgetary, resource, or technical factor that will limit the options available to the project.
• Risks—Lists any uncertain event or condition (risk) that, if it occurs, could have a negative effect on one or more project success criterion (schedule, budget, quality, and so on). For each risk, it is good to list the related causes, the perceived negative effects, the likelihood it will occur, and the planned response strategy and action items.
• Stakeholders—Lists all the individuals, business units, and organizations involved in the project, the role(s) each is expected to play, and an indication of how they relate to one another. A Project Organization chart and a Stakeholder-Role Description Table is highly recommended here.
• Recommended Project Approach—Highlights the recommended approach to getting the work of the project done and why it is selected over any other options as a way to better describe the intent of the initiative. This section should note any key strategies, methodologies, and technologies to be used.

Apart from the above mentioned elements, there are informational elements that might not always apply, but if appropriate, are recommended additions to the Project Definition document. These are:

• Alternative Project Approaches—This section lists the approach details for any alternatives that were considered. 
• Organizational Change Issues—Because most projects result in a change to the status quo, and the most common oversight in projects is not adequately realizing, planning, and preparing for the “change” impact to current customers, business processes, and personnel, it is highly recommended that this area be a focus from the start of the project.
• Policies and Standards—Given the priority that standardization, compliance, process improvement, security, and quality have in most organizations, it is highly recommended that any policy, regulation, or standard that will be applied to the project or the results of the project be identified from the start of the project.
• Preliminary Cost, Schedule, and Resource Estimates—Generally, there is some preliminary “ballpark” expectation for the cost, timing, and resource needs of this project. In many cases, these will be noted as either project objectives or as project constraints. The most valuable information here is not necessarily the date or the dollar amount, but an explanation for what is driving the figures presented.
• References to Supporting Documents—For any situation, where the results of a preliminary or related project served to define the need or details for this project, always include a reference to those supporting documents. Common examples would be a Business Case, Cost-Benefit Analysis, Assessment Results, Requirements Document, and Business Process Engineering Studies.
• Visual Scope Summary—For most projects, a visual summary of the project scope can be an invaluable tool for communicating the objectives, boundaries, and “change” elements of the project. It can help validate the definition of the project, identify potential risks, and greatly improve the common understanding of the project stakeholders. Especially for any project that is introducing significant change, the effort to create this visual summary is one of the best investments you’ll make. The creation of a visual scope summary definitely falls into the “art” part of project management—there is not a single way to do this. The specific tool or medium used can vary depending on skill set and tools available. The specific approach depends on the nature of the project. For product and construction projects, a prototype or visual drawing of the target can be used. For projects impacting business processes, a variant of a flow diagram (process, data, system) showing current state and proposed future state can be very effective. There is no right answer—you just need to be effective.

Project Definition Checklist

A project definition checklist can help you to determine whether your project is defined properly and whether you are ready to proceed to the next iteration of detailed planning. If you find that your project is not properly defined, you have the following options available:

• Resolve any gaps with appropriate stakeholders before moving on to the next phase.
• If the project has already been defined, work to resolve these gaps during the detail planning phase.
• If gaps cannot be resolved, then handle as project risks or issues (whichever is appropriate for the specific gap).

General

• Is it clear why this is project is being undertaken?
• Is there a clear picture of the desired results of this project?
• Is there a clear picture of how this project fits within the organizational landscape?
• Is there a gap between available and needed funds?
• Have the success factors been identified? Are they complete? Are they SMART?
• Have any future state performance targets been defined as success factors? Are they SMART?
• Is the gap between the current state and the desired future state clearly documented and understood?
• Has the expected “change” impact on existing business processes, customers, systems, and staff been clearly documented?
• Do you understand who is funding the project initiative?

We'll cover some more required elements in our next post.

How to properly define a project?

This is most important stage because it builds the foundation for all other project management activities and sets the stage for our eventual project success (or failure).

The irony of this is that depending on your organization and industry, you (the project manager) might be the primary agent in getting this done, or you might not be involved at all until after project definition is complete.

In either case, you need to know how to properly define a project and how to evaluate if a project definition performed by others is complete before starting any detailed project planning efforts.

With all this in mind, in this post we will review the critical importance this step plays, the key questions that must be answered and agreed upon, the “must-have” elements of your Project Definition document, and the success criteria for the project definition process.

Setting the Stage for Success depends on getting the key project participants to agree on the answers to these seven basic project definition questions:

• Why are we doing this? (Purpose)
• What organizational level goal(s) does this project support? (Goals and Objectives)
• How does this project fit with the other projects that are going on? (Scope, Project Context, Project Dependencies)
• What is the expected benefit from this project? (Expected Benefits, Business Case, Value, Success Criteria)
• What are we going to do? (Scope)
• Who is affected by this and who must be involved? (Stakeholders)
• How will we know when we are done and whether the project was successful? (Success Criteria)

Gaining consensus on these questions is paramount to managing the organizational-level factors that get projects in trouble (such as alignment with organization and management support) and to controlling key project-level factors that impact project success: stakeholder expectations and scope
management.

Defining a project is part of the project planning process, however, it is important to make the distinction for several reasons:

• Before you develop a detailed and complete project plan, you need to know the parameters and boundaries for the project.
• You need to know the key stakeholders are in agreement with the project mission (project purpose, goals, objectives, and success criteria) before proceeding.
• The work to properly define a project is often not trivial. In fact, many process-focused and disciplined organizations handle “project definitions” as separate projects. Common examples include business case development projects, cost-benefit analysis projects, selection projects, and assessment projects.
• Detailed project planning and general project management are inefficient, and difficult at best, if project definition is not performed.
• Effective execution of the project definition process enables the organization to leverage portfolio project management processes. This enables the organization to better invest its limited resources in initiatives that offer the greatest return.

Now the question comes "how do we get the key project participants to agree on the answers to the seven basic project definition questions discussed above?"

We write down the questions and get everyone to formally sign off on this document. We will refer to this document as the Project Definition document. There are many different names for the Project Definition document. Some of the most common alternative names are Project Brief, Project Charter, Project Initiation, Scope Statement, and Statement of Work. We'll review both the “must-have” elements and “good-to-have” elements of the Project Definition document in our next post.

Project planning - project planning principles

A project plan is an all-encompassing document that is used as the basis for controlling and executing a project. In defining a project, we ensure that we agree on what we will do and who will be involved. In planning a project, we focus on how the work will be done.This involves both how the deliverables will be developed and how the project will be managed.Thus, project planning involves the traditional areas of work tasks, resources, schedule, and costs, and it also sets the stage for managing project changes, project communications, project quality, project risks, project procurement activities, and the project team. Each of these factors directly impact stakeholder expectations and our ability to successfully control and execute the project.

Unfortunately, there are many misconceptions about project planning, and often it is performed incompletely or incorrectly. In the coming posts we will review the key principles of project planning, how to properly plan a project, the key planning questions that must be answered and agreed upon, the “must-have” elements of your Project Plan document, and the success criteria for the project planning process.

Let's look at key project planning principles:

Purpose—The purpose of project planning is to develop a plan that enables the project to be executed and controlled, as shown in figure below:

Multiple passes required—Project planning is not a one-time activity performed at the beginning of a project. For starters, it generally takes several iterations to get to a comprehensive plan given the multitude of inputs that must be integrated and the number of stakeholders that need to agree on the plan. In addition, as things happen and we learn more, plans will need to be adjusted and details ironed out as the project moves along.

A project plan is NOT a Microsoft Project file—Before we go any further, let’s make sure we are clear on a few key terms. A project plan is not a project schedule or a Work Breakdown Structure (WBS).

Project control- The planning exercise and the planning team must have control over one of the traditional project success factors (scope, time,cost, or performance). Senior management can set all but one of these factors, but at least one must be left to the project.

Proactive project management- Effective planning enables a proactive project management approach. Before the execution of the project gets underway, we ask the questions and determine the approaches we will take to manage the project and stakeholder expectations regarding project
communications, stakeholder responsibilities, quality management, risks, responses to specific performance variances, procurement management, and project team management. Change control, communications, risk, and quality project management are excellent examples of proactive project management.

Stay down from the mountain - Project planning is not the time for the top-down, Mount Olympus approach to management. Project planning is the time for questions, facilitation, interaction, and feedback.

Specifically, you need to conduct a stakeholder analysis on all your management and customer stakeholders to validate the project definition elements, understand their expectations and communication needs, and review procedures for dealing with critical issues, risks, change requests,
and performance variances.

In addition, the team members who will be doing the work should be heavily involved in defining and estimating the details of the work to be performed.