Introduction to the WBS

A Work Breakdown Structure is a results-oriented family tree that captures all the work of a project in an structured way. It is often displayed graphically as a hierarchical tree, however, it can also be a tabular list of "element" categories and tasks or the indented task list that appears in your Gantt chart schedule
Large, complex projects are comprehended by breaking them into smaller pieces until they are an anthology of defined "work packages" that may include a number of tasks.
A $1,000,000 project is simply a lot of $5,000 projects joined together. The Work Breakdown Structure (WBS) is used to provide the framework for organizing and managing the work.

In planning a project, it is normal to find oneself fleetingly overwhelmed and confused, when one begins to grip the details and scope of even a modest size project. This results from one person trying to understand the details of work that will be performed by a number of people over a period of time. The way to get beyond being overwhelmed and confused is to divide the project into pieces, organize the pieces in a logical way using a WBS, and then get help from the rest of the project team.

The psychologists say our brains can normally comprehend around 7-9 items simultaneously. A project with thousands or even dozens of tasks goes way over our ability to grasp all at once. The solution is to divide and complete. The WBS helps to break logically thousands of tasks into pieces that the project manager can understand and monitor. Preparing and understanding a WBS for a project is a big step towards managing its intrinsic complexity.

The WBS is commonly used at the beginning of a project for defining project scope, organizing Gantt schedules and estimating costs. It lives on, throughout the project, in the project schedule and often is the main path for reporting project costs. On larger projects, the WBS may be used throughout the project to identify and track work pieces, to organize data for evaluation, reporting, for tracking deliverables, etc.

History of the WBS

The WBS was initially developed by the U.S. defense establishment, and it is described in Military Standard (MIL-STD) 881B (25 Mar 93) as follows: "A work breakdown structure is a product-oriented family tree composed of hardware, software, services, data and facilities .... [it] displays and defines the product(s) to be developed and/or produced and relates the elements of work to be accomplished to each other and to the end product(s)."

It requires some mental discipline to develop a product-oriented or deliverable-oriented grouping of project elements adding up to comprise the entire project scope. Intuitively, we tend to start out with a task-oriented approach. This is Ok for very small projects where extensive project management controls will not be used. The task-oriented approach is easy to understand, because we can easily think of projects as collection of tasks. A task-oriented WBS can be developed by beginning with a simple "to-do" list and then clustering the items in a logical way. The logical theme could be project phases, functional areas, or major end-products.
If your organization will be collecting historical data to form a cost database, you should try to select a standard approach consistent with the organization’s long term data collection needs.

A sample WBS is shown in the figure below:

WBS Format for Application Development Projects

A WBS for a large project will have multiple levels of detail, and the lowest WBS element will be linked to functional area cost accounts that are made up of individual work packages. Whether you need three levels or seven, work packages should add up through each WBS level to form the project total.

Product or Process Oriented?

The WBS was initially defined as a product oriented family tree, however subsequent definitions have introduced more flexibility -- so a WBS can also be deliverables or process oriented. Your WBS can be built on nouns or verbs. If the results of your project are primarily verbs, then a verb based or process based WBS may make more sense. If your WBS is to be product or deliverable oriented, then you can start by thinking of the WBS as a parts list for the ultimate end-items of your project. These differences are not shown to tell you what is the right way for your project, but just to familiarize you with the distinctions, so you can think about them and choose what's best for your project.

WBS Numbering

WBS elements are usually numbered, and the numbering system may be arranged any way you choose. The conventional numbering system is shown in the figure. The shaded box shown in the above slide could be numbered 1.2.2.3, which would tell you it was in the second box in level 2, the second box in level 3, and the third box in level 4.

WBS Dictionary

If a WBS is extensive and if the category content is not obvious to the project team members, it may be useful to write a WBS dictionary. The WBS dictionary describes what is in each WBS element, and it may also say what is not in an element, if that is unclear. Here is a sample of a WBS dictionary description:
WBS Element 1.5.4.5. - Application Test Equipment Planning - This element includes the effort to identify requirements and specify types and quantities of test equipment needed to support Application Test process. It does not include the design or procurement of such equipment, which is covered in Element 1.5.4.6.

Mapping WBS for Cost Management

In a product-oriented WBS, functional categories of work may form "cost accounts" within a WBS element. Cost account managers are responsible for a functional area’s contribution to a WBS element. Cost accounts from several departments or functions may combine into one WBS element.

Internal department planning for a cost account will be made up of individual work packages. A work package will typically have its own budget and schedule. Work packages should be small enough to be executed by individuals or small groups in a single department, and they should be of relatively short schedule duration. A small project might define a maximum work package size as two weeks of effort. Larger projects will assemble larger work packages that can be appropriately managed and monitored.

The project manager will have to decide to what degree employment of various details of WBS implementation will benefit the efficient management of the project. On a very small project, a formal WBS may serve no useful purpose, but it can become valuable if project size or complexity start to increase.

As an organization’s project management environment matures, or as larger size and complexity are encountered, application of the WBS concept can evolve from an ad hoc list of tasks, to time-phased activity lists, task lists clustered by project deliverables and services, or an end-product focused WBS fed by cost accounts and work packages.


If you are using MS-Project or a similar project management software application, you may encounter the WBS as a vertical list with indents to show structure. This will be compatible with the Gantt View data entry screens. While some software packages provide a separate WBS view, you could prepare your WBS in the vertical format using a word processor, and then cut and paste your WBS into your project management software package.

Organizational Standards

Your organization may want to decide on a standard WBS format or group of formats, use these across all projects, and communicate definitions widely so everyone will be speaking the same language. This can save re-learning project units and can lay the foundation for successful data gathering to aid future cost estimates.

WBS Implementation

When you have prepared a project WBS, think about how you will be using it later in the project. Try to consider how you will organize the WBS, schedule format, manager assignments, and charge numbers, in your early project planning. These days, the WBS in smaller projects ends up automatically being the indent structure in your Gantt schedule, so pay attention to those indents, and make sure that is the WBS you want for rolling up costs in your project. It will be helpful if you can map the charge numbers, managers, and task groups to each other. This will help you track costs and progress for each manager. If your project schedule will on MS-Project, you may want to insert "text" columns into your schedule (Gantt View) for project charge numbers and manager names.

If your project charge numbers cannot be linked to groups of tasks assigned to specific managers, you will have no way to provide performance measurement feedback to managers.

Some project management environments have distinct conventions for grouping items in a WBS. The best method is to have a WBS that works for your particular project and organizational environment. The WBS should be designed with consideration for its eventual uses. Your WBS design should try to achieve certain goals:

• Be compatible with how the work will be done and how costs and schedules will be managed,
• Give visibility to important or risky work efforts,
• Allow mapping of requirements, plans, testing, and deliverables,
• Encourage clear ownership by managers and task leaders,
• Provide data for performance measurement and historical databases, and
• Make sense to the workers and accountants.
There are usually many ways to design a WBS for a particular project, and there are sometimes as many views as people in the process. Experience teaches that everyone takes a slightly different slice of the apple, so make sure WBS arguments seeking metaphysical certainty are quickly brought to closure. Simple practicality combined with enlightened trial and error usually is the best approach. Good Luck..






project management training project management

project management webdesign

website design

webdesign

internet

Balancing Honesty and Goodwill

I've been on lots of projects, and some were very high-tech. When suddenly assigned as Project manager for a support team on a very large and complex web and software development project, I wondered if I would be able to incorporate the technology quickly enough to add value. After three months, I learned a lesson I would have learned before. No matter how technically advanced a project is, the hard part is not the technical part, it is the people part 

Projects need special people skills since they often involve people with conflicting priorities and high stress. It helps in such projects to have some reliable principles to rely on in dealing with people issues. Project leadership, especially in a matrix organization, requires that the project manager build informal relationships with the members of the project team. About 10 years back, when I had just started going with a new girlfriend, a professor told me that relationships are built through communication and consideration. Now whenever, I want to build a relationship, I consciously look for ways to increase the communication and consideration I am putting in that relationship.

Project environments sometimes require a great commitment to truth, and this is sometimes difficult to reconcile with the interpersonal demands of getting along. Such demanding environments call for the application of sound spiritual principles. Here is one such principle that I have found useful in project work.

I started thinking about the end of last year when reading the Gita from the beginning. I watched carefully to see the emergence of the spiritual message as it evolved from the first stage of spiritual discipline and obedience and then gradually grew to a larger sense of the spiritual principles of goodness. I was interested to see that some advanced spiritual principles appeared quite early in the text.
I was struck by the phrase "kindly and truly" that appears several times. Even four thousand years ago, it was deemed by some a worthy standard to deal with each other kindly and truly.

It seems we have not always remembered the simple realism of dealing with one another in this way. We often hear people justifying their positions by saying, "Well, I was just viciously honest. I told them just the way it is. I can't lie." And they think this is somehow a recipe for success. It turns out that honesty and good-will need to be balanced together to bring success to our dealings with others.
Our practice of truth and love go together. Our love isn't really love if it isn't true. And the truth doesn't have the positive affect we want unless it is also loving. I learned a few years back that being brutally honest can be, well, how do I put this - an act of viciousness?

Someone once said, "I want neither unloving critics nor uncritical lovers." That reflects the reality that truth and love need to go hand in hand. We value honesty as an ethical principle, but we need to couple honesty with good will. If we have only honesty without good-will, we simply end up as a "whistle-blower" in our organization or as an abrasive "Chicken Little." This may be ethical in one sense, but it is not the sign of a healthy, progressive organization. Success is achieved when we make sure our honesty is balanced with good will and that our good will is really true. Only in the combination of these we can make genuine advancement.

You might think of these two forces as vectors, and the success vector is the resultant of good-will and honesty exercised in balance (as shown in the figure). It is not our exercise of one or the other, simply trying to be nice to people or being viciously honest, but the vector sum of these two factors that is a solid principle for success. The resultant vector is a cross-product of honesty and good-will. There is a good reason for calling this a cross-product, since while either one by itself may be relatively easy, increasingly exercising the two in balance can be a real struggle.

These spiritual principles can be communicated in the work place by simply holding up the standard of honesty and good will, dealing with one another kindly and truly, and best of all, by acting this out ourselves.






project management training project management

project management webdesign

website design

webdesign

internet

The Spiritual Side of Project Management

Having spent many years in both spiritual pursuits and project management, I have been intrigued to see how a number of areas overlap. Because spiritual principles seem to have a bearing on running projects successfully, it seems that there ought to be ways to communicate these spiritual principles to make them accessible and practical in the work place.

Some years ago, I was impressed by a need to more completely embody and act out some spiritual principles with which I had been growing increasingly familiar. It was almost a bolt from the blue to me, because I had been thinking that my spiritual inspirations would just eventually cuddle my actions. I got to the point where I realized I must simply stand up on my mental hind legs and do it.

Later, I was talking about spiritual things with someone, and they said, "When I hear you say those things I say, 'Yes, I know, I know', but I want them to be more real to me." My response was that they most often become more real to you after you do them. As we act out our spiritual principles we gain a growing perception of their reality.

Not long ago, in my project management work, I was brought into an on-going information systems project. I asked if they had applied some basic principles of project management, like "first understand and clearly document the requirements." The people around me said, "Yes, we know that is what we are supposed to do, but we didn't do it, because we were too busy and the requirements changed too often."

As the project progressed, this team became even busier, because they hadn't understood and clearly documented the requirements. The project was restarted, and then it dragged out for months longer than it should have.

When the next similar project came along, I put special emphasis on clearly understanding and documenting the requirements, and reviewing it with the customer for approval. Then I put these requirements under informal version identification and change control process and managed any changes methodically and majestically. It was not easy, and it took persistence to nail down all the indistinct issues and get agreement. The result was that project went much, much more smoothly than the previous one, and it was a widely acknowledged success.

In considering what I brought to that project, I realized I didn't tell them anything they didn't already "know." I simply did it.

The difference was in being a doer of the word and not a hearer only. I am still trying to describe that quality, because it is so fundamental to success in my area of work. The only word that seems to fit is "guts," which to paraphrase my Webster's is "common sense, actively applied." It seems that the "actively applied" is the hard part. It involves paying attention, discipline, belief and understanding.

I think understanding doesn’t just know something; it is standing up for something. Until you stand up for something you don't really understand it at all.

It is interesting that in the Gita (The Holy Indian Epic), some of the verses that speak of this quality use building projects to illustrate the principle. See if you don't think the first few phrases of the second verse sound a little like your project environment.

"Therefore whosoever hearth these saying of mine, and doeth them, I will liken him unto a wise man, which built his house upon a rock:
And the rain descended, and the floods came, and the winds blew, and beat upon that house; and it fell not: for it was founded upon a rock.






project management training project management

project management webdesign

website design

webdesign

internet