Project Objectives and the Work Breakdown Structure

I talked earlier about a Work Breakdown Structure (WBS), but this is such an important subject it is valuable to revisit.

The WBS should accomplish several things:

It is the mechanism that takes the project's requirements and turns them into manageable project tasks

It is used to communicate project objectives to the project team and other stakeholders

Its output is used to build your first plan and schedule

In David I. Cleland's Book "Project Management: Strategic Design and Implementation. Second Edition" he states that:

In general the development of the WBS provides the means for:

Summarizing all the deliverables , resources, and activities of a project

Relating work elements to each other and to the total project

Building the matrix organization for the project by cross referencing the work elements to the organizational resources responsible for their completion

Addressing all contracted resources required for the project.

Estimating costs, simulating project scenarios, and conducting risk analysis

Providing information to define, budget, schedule, perform, and control work packages

Definition: "Work Package" - A deliverable at the lowest level of the Work Breakdown Structure.

Keep in mind a complex WBS isn't' required for most small and medium sized projects. Many times a simple deliverable-oriented tree of activities that graphically displays the work to be done will suffice. By that I mean a structure similar to an organization chart with the project name on the top row and the second row consisting of some elements of your project methodology.

For example, for an IT project the second row headings might be:

Analysis

Requirements

Design/Procurement

Coding/Installation

Test/Acceptance

Close-out.

The best way to get started with creating a WBS is to gather the team (always done with the team) and write down the project tasks on Post-It Notes. Then, use an available wall to post the tasks in the appropriate places under the headings of your WBS's second row.

Project Management Boulevard

Another good Project Management site with an extensive, usable library of White Papers.

Project Management KnowledgeBank

Here is a link to a site I use quite often. It contains lots of links to other Project Management sites that have some useful information. Project Management KnowledgeBank

Project Management and Disaster Planning

Had you been a Floridian this past week living on the southwest Gulf coast like I was, you would have quickly realized that Disaster Planning was something you should have completed months if not years earlier. It turned out that Hurricane Charlie was a major disaster for thousands of families in our area. I wonder how many might have lessened their troubles if they had done some disaster planning prior to this tragic event.

As my wife and I scrambled around the house on Thursday night taking pictures and recording serial numbers of our possessions, I quickly realized I should have prepared a disaster prepardness plan long ago.

As most of us know, one of the most important things to have when planning for any project is a scope statement. My scope statement for this hastily started project was simple: "keep my family safe and protect our property". I live in a new house, and with the strict Florida building codes that were enacted over the last several years I felt we were safe staying in our home. But, like most projects, my plan was full of risks, and I needed to perform some serious Risk Mitigation. Did I have fresh batteries for the flashlights, a portable radio, a designated safe area of the house to escape to in case things got bad?

On Thursday evening the kids filled the bathtubs with water (in case we lost our water supply), we made sure there were candles and matches (in case the electricity went out), my wife took the time to ensure the propane tank for the gas grill was exchaged for one that was full, and she went to the store and purchased plenty of canned goods and bottled water. To further mitigate risk, my wife and I filled our cars with gasoline and began clearing the yard and lanai of objects that could become flying missiles in a strong wind.

Having said all this, it would have been much better to have had a well thought out plan, or checklist prepared ahead of time so that no important task would be left undone. While our immediate area wasn't impacted much by the hurricane, the lesson learned from this experience is that early planning is not only important, but it can save a lives!

God Bless the families impacted by Hurricane Charlie!

Will the real Project Sponsor please stand up?

In my experience most projects don't have a real project sponsor. A project sponsor is the senior manager or executive that champions the project in the organization. The sponsor provides support for obtaining resources, provides strategic direction, and acts as the decision point for questions outside of the project manager’s authority.

Every project that crosses functional lines of authority needs a project sponsor to remove barriers, assist in resolving conflict, and mediate negotiations. The sponsor can also act as a mentor and coach to the project manager and team members.

The project sponsor is usually chosen by senior management, but sometimes the sponsor volunteers because the project directly impacts their resources or budget the most.

Typically Project Sponsors are responsible for:

Providing project direction
Monitoring project progress
Assisting the Project Manager to define the Project Management process for the project
Approving final scope, project objectives, schedule, resource assignments, roles and responsibilities
Providing accurate, relevant and timely communications in writing when appropriate
Approve scope changes
Obtain or resolve issues surrounding resources (people, money, equipment)
Setting project priorities and removing barriers to project success

Project Management Truths

I found these "Project Management Truths" several years ago on the Internet . Here is a partial listing, I will post more later.

The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.

Any project can be estimated accurately (once it's completed).

The most valuable and least used WORD in a project manager's vocabulary is "NO".

The most valuable and least used PHRASE in a project manager's vocabulary is "I don't know".

Nothing is impossible for the person who doesn't have to do it.

You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.

At the heart of every large project is a small project trying to get out.

If you don't stand for something, you'll fall for anything.

The more desperate the situation the more optimistic the situatee.

Six Steps to Political and Project Success

Assess the Environment

    Who are the relevant stakeholders?

    Who are the most important stakeholders?

    Where does the power lie?

    Whose actions will impact the project most (Negative or Positive)?

Identify the Goals/Needs of the Stakeholders and Sponsor

    What are the stakeholder's/sponsor's work and/or organizational motivations?

    What are their psychological motivations?

    What is their overt motivation?

    What is their hidden agenda?

Know Thyself

    What are your strengths and weaknesses as you perceive them?

    How are you perceived by others?

    What are your personal values related to your workplace?

    How can you compensate for your weaknesses (actual and perceived)?

Define the Problems

    What are all the relevant facts?

    What are the underlying assumptions (both True and False)?

    What is Reality?

Develop Solutions that Work

    Avoid premature solutions that don't account for the four steps above

    Obtain user buy-in to the solution

    Obtain Sponsor buy-in to the solution

Test and Refine the Solutions

    Initial solutions are tough and usually difficult to sell

    Continually refine and test your solution

    Get sign-off from all relevant stakeholders and your sponsor

__________________________

PROJECT MANAGEMENT FACT

A solution that does not take the realities of the political environment into account will fail.  Don't be naive when it comes to internal politics.

Quality Guide - Welcome to Managing for Quality

Quality Guide - Welcome to Managing for Quality.

Here is a site that has some great information regarding Quality Management.

Michael Greer's 20 PM Actions/Results

Michael Greer's 20 PM Actions/Results

This looks like a good site for general Project Management Information. Give it a try and let me know what you think.

Good Requirements Management = Increased ROI

What of the biggest areas of concern in the IT Project Management field is Requirements Management.  It has been said that reducing requirements errors can have the biggest impact on delivering a quality software project on time and on budget.  How do you as a Project Manager help to reduce requirements errors while not slowing down project progress? 

Before we answer that question lets look at some industry statistics. 

According to the Standish Group (over 352 companies reporting on over 8000 projects):

• 31% of all software projects are canceled before completion
• 53% of all projects will cost 189% of the original estimate
• 9% of projects are delivered on time and on budget (in large companies)
• 16% of projects are delivered on time and on budget (in small companies)

The reasons given for the above are:

• Lack of user input or participation - 12%
• Incomplete Requirements and Specifications - 12.3%
• Changing requirements and Specifications - 11.8%

To answer our question stated previously, what can a Project Manager do to reduce requirements errors? 

Try the following:

• Structured  requirements gathering meetings
• Walkthroughs and reviews of requirements with end users and customers
• Better organization and documentation of requirements
• Improved project progress reporting
• Improved requirements-based testing and requirements tracability

If you will implement the above suggestions you can reduce requirements errors by 20% or more.  Any reduction in requirements errors will help to significantly reduce project cost and schedule overruns.

The Project Management Office

Many companies are implementing a Project Management Office (PMO).  If you or your company are thinking about starting a PMO there are a few critical things you must consider. 

First, there is no right or wrong model for a PMO.  The issue is which PMO type is right for your organization and have you done the proper planning up front before implementing a PMO. 

Before you decide on the type of PMO that is right for your company consider the following:

Do you have a Mission Statement for your PMO?

Do you have a Vision Statement (can be covered in the Mission Statement)?

What are the PMO's Principles (what statements will guide how the PMO will achieve its Mission)?

Who are your Customers?

Who are the Stakeholders (those people or groups that will be impacted)?

What are the Goals of the PMO (what does the PMO hope to achieve)?

What are the Objectives of the PMO (must be S.M.A.R.T)?

Note: S.M.A.R.T Objectives are (S)pecific, (M)easurable, (A)ttainable, (R)ealistic, (T)imebound

Other things to consider are what Products, Services, Roles and Responsibilities will be offered by the PMO.

Once all of the above items have been finalized you are ready to build a Workplan that outlines the activities to make the PMO a reality.

What is a Work Breakdown Structure?

A Work Breakdown Structure (WBS) is a deliverable-oriented grouping of project elements that organizes and defines the total scope of the project work: work not in the WBS is outside the scope of the project. 

The WBS is often used to develop or confirm a common understanding of project scope.  Each descending level represents and increasingly detailed description of the project elements.  What does the WBS look like?  Work Breakdown Structures s are communicated and organized in many ways. 

The two most common ways to communicate a WBS is either a hierarchy diagram or a table of contents (TOC) layout.  In some cases both formats are used to gain understanding and define the work to be performed.  Typically, complex projects with a large number of internal and external stakeholders respond better to a hierarchy diagram. 

However, to understand and accomplish the specific work tasks, the project team responds better to the TOC layout.

To view more information about a WBS and see an example of a WBS click here

Common approaches to Developing the WBS

The two most common approaches to developing the WBS are the top down approach and the bottom up approach.  Some find a combination of both beneficial.

Top-Down Approach

The top down approach uses a predefined product development lifecycle, or a WBS template, or a WBS from a previous similar project as structured models to define the WBS from general to specific.  This approach involves using a model and reviewing the major project deliverables which have been subdivided into smaller, more manageable components until the deliverables are defined in sufficient detail to support future project phases (planning, executing, controlling, and closing).  

Bottom-up Approach

The bottom up approach uses a planning group to brainstorm the work elements that are needed to deliver the major deliverables of the project.  A planner then groups the output from the brainstorming sessions into phases, activities and tasks.   The bottom up approach involves using a small group of people (5-6) who have some subject matter expertise to plan the project. 

The technique uses the brainstorming method to identify the work needing to be performed to deliver a specific thing.  When the project is large or complex, the brainstorming activity is focused on a major deliverable or end product instead of the broader scope of the project.   The results of the brainstorming session, generally are the pieces of work or tasks that the group knows needs to be done.  It is similar to creating a “to-do list”.  One of the planners then takes this information and groups the related work. These groups may then be grouped again to build up to the highest level of definitions.  The information is reviewed with the original group and they modify, fix, and add any missing pieces. 

Project Estimation

As stated so eloquently by Bob Lewis in his book "IS Survival Guide", There is no way for you to successfully estimate projects. Take that as a given. It can't be done, and for a very simple reason: Every one of your projects is one-of-a-kind. Mr. Lewis makes a very good point, however in my experience, I have yet to have met a manager that will let me get away with saying "I can't estimate this project".

SO WHAT IS A PROJECT MANAGER TO DO?

I like to call the solution to this problem rolling-wave estimating. By that I mean when the project is in the initiation phase and you have very little information your estimate should reflect that fact. This means very early in the project your estimate(s) could be off by as much as +200/-75% (or more). As you progress through the project planning phase you will breakdown the project into smaller, more manageable pieces of work (decomposition). This process helps to narrow the range of your estimates.

Do not be fooled into thinking that because you have broken down your project into phases and/or small manageable pieces of work that you can just add up the estimates and have a total overall project estimate. Many times, especially on IT projects, there are integration issues that are difficult to estimate and are usually ignored in the planning phase. Do not forget to add time for these critical integration activities. Also, while padding of estimates is a no-no, don't forget to account for Risk in your project estimates. PMI advocates for contingency and management reserves to account for risk events, but I have not worked in an environment where these exist so I have to plan for Risk in my estimates.

Be smart when estimating and realize that in the IT world estimates are always wrong and tasks are always underestimated.

Managing a Project in Steps

Everyone should know that for an initiative to be considered a project it must have an actual start and end date. Additionally, the project must needs a scope statement, budget, and resources.

The work in a project is considered to be unique. There may be similarities to previous projects, but no two projects are exactly the same because you will always be dealing with different circumstances and resources.

There are many different ways to manage projects and organize the work. We want to manage projects in an organized fashion using a methodology that has either been tested by others, or created for our own environment.

Step I use to manage a project are:

1. Define the Work (Concept Documents, Business Case, Charter)
2. Create the Plan (WBS, MS Work, Project, Excel)
3. Manage to the Plan (Earned Value)
4. Manage Issues
5. Manage the Scope (from the Scope Statement)
6. Manage Communications (Status Reports, Meetings)
7. Manage Risks (Risk Management Plan)
8. Manage Documentation (Document Management, Intranet/Internet)
9. Manage Quality (Quality Plan)
10. Manage Metrics (Status Reports, Earned Value)

It is important to remember as the complexity of your projects increases you will need to delve deeper and deeper into the Ten steps listed above. An excellent resource that explains how to use the above process steps is http://www.tenstep.com.

Commitment

While getting ready to leave for the day I was reminded of a quote by Tom Peters, "Commitment, not authority produces results". All project stakeholders need to be committed to seeing that a project's objectives are met, but more importantly they need to be open, effective, and honest when it comes to their communications with the other team members and management.

To support the project team and ensure their success, management must provide the best people to participate on project teams, and have a deep seated belief that the people on the team are intelligent, creative, and have the capability to succeed.

The entire project team and all levels of management involved must have the attitude that they will do everything possible to ensure that the customer (end user) is satisfied with the product of the project.

The number one measure of Project Success is Customer Satisfaction. Having a set of "shared values" will help a project team increase customer satisfaction for every project they support.

More Project Management Communications Information

According to the Project Management Institute (PMI), "Project Communications includes the processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information. It provides critical links among people, ideas, and information that are necessary for success. Everyone involved in the project must be prepared to send and receive communications, and must understand how the communications in which they are involved affect the projects as a whole".

What does this mean in the real world? Keep those that need to know informed. Use face-to-face meetings, phone calls, e-mails, status reports, project status web sites, meetings, and other ways to keep users abreast of project progress, issues, and concerns.

Be aware that on many projects there will be stakeholders that are out to sabotage your project. Sometimes these actions will be obvious, and sometimes the signs will be subtle. Occasionally the saboteur doesn't even realize the damage they are doing. It could be just the way in which they go about doing their job. They may be confrontational with everyone they work with and they may not care what others think. Be prepared to gently confront these stakeholders and escalate through the management chain if necessary to keep your project's communications effective and relevant.

PMI considers Project Communications to be very important. It is one of the nine knowledge areas as defined by PMI's PMBOK (Project Management Body of Knowledge). It is an area of knowledge you must master to be a successful project manager, and if you hope to pass the Project Management Professional certification exam.

Project Communications

Good communications are a necessity if you want to have success on your projects. You need continual, effective communications among all team members during the life of the project if you want to minimize problems with stakeholders.

Agreements must be made early on regarding goals, how problems will be addressed and solved, how resources will be managed, and how the expectations of stakeholders will be satisfied. Project Communications are conducted throughout the lifecycle of the project. When the customer creates a business case or project request they start the communications process and the activities that follow (Project Charter, Statement of Work, Work Breakdown Structure, etc) support the project's communications effort. All project teams need to keep in mind the four major communication areas they must support.

RESPONSIBILITY: Each member of the team needs to be aware of their role on the team and their responsibilities.

COORDINATION: Information among team members is shared and each member works to carry out their assignments in the time allotted.

STATUS: Progress is tracked, issues are identified, and action is taken to remedy any problems. Project status reports are distributed to all project stakeholders.

AUTHORIZATION: Team members must be kept informed about decisions made by customers, vendors, sponsors, and management personnel that relate to the project.

Initial Posting

As a project manager working for a County Government I am faced with challenges everyday that I didn't often experience in the private sector. Hidden agendas, internal politics, and silo mentalities make for an environment that has many pitfalls, but also many rewards.

In the seventeen years I have been a project manager I have prided myself on my ability to work with others towards a common goal. I feel that a project manager's greatest attribute is his or her communication skills and the ability to be flexible when presented with a challenge. My goal in creating this BLOG is to pass along some of my thoughts and learnings, which will hopefully help you to avoid repeating the mistakes I have made over the years.

Stephen Seay, PMP