Introduction
All projects are authorized and funded by stakeholders who are looking for specific results. These stakeholders have specific requirements for the project outcome. They want results that will in some way contribute to the success of the enterprise. The desired results may be an improved process, a more efficient facility, a new product, or a new management information system. It is the project manager's responsibility to achieve those results for the stakeholder and the enterprise.
The project manager must analyze the requirements and develop a project plan to meet them. The project plan is essentially a top-down plan that says this is what must be done to meet the stakeholder's requirements. Elements of the plan include a definition of the scope of the project, the authorized budget, the required schedule, and any other requirements imposed by the stakeholder. The problem is, often this top-down plan is not connected at the bottom of the project hierarchy where the actual work of the project is performed. The requirements flow down, but there is no mechanism to connect the detailed work to the requirements. This paper will propose a mechanism to make the connection—the missing link, if you will. That mechanism is the Work Package.
The Work Package is at the lowest level of project planning, control and reporting. The challenge in developing work packages is to connect all of them to some element of the project scope so that all the work required to support the stakeholder requirements is planned, authorized, allocated, tracked, and completed. When all of the work packages are completed, the project is completed. The project plan is decomposed into work packages. The completed work packages flow up to meet the project objectives. The requirements and the desired outcome(s) are connected—what a concept!
The presentation of this paper will conclude with an in-class exercise to demonstrate the concept—the preparation of a sample work package.
Initial Requirements—Top Down
There are two levels of top-down requirements to consider at the initiation of a project. The first is the requirements flowing down from the enterprise-level stakeholders to the project manager and the project leadership team. Projects are authorized and conducted to accomplish an objective or objectives of the enterprise. (Projects are conducted to either make money or save money. Even a project conducted by a nonprofit organization has an objective to be completed at the lowest possible cost.) The enterprise must do an effective job of communicating its requirements to the project team if they expect to accomplish the results they are seeking. (A word to the wise project manager, often it is left to the project manager to “ferret out” the requirements when an enterprise cannot clearly articulate them to the project team. It would be unwise for any project manager to accept a project without a clear understanding of the requirements and desired outcome.) Exhibit 2 illustrates the first level of “Top Down.”
What is most important to an enterprise is profitability. When you think about it, projects are not usually directly responsible for producing profits for the enterprise, but projects produce the products that enterprises sell. They also improve the processes that enterprises use to produce profits (or save money, which is in effect, increased profit).
Time to market is very important to an enterprise. Thus, the enterprise wants products and services developed as quickly as possible. Return on Investment (ROI) is also important and ties back to profits. If an enterprise can develop a product at a lower cost they can pay back the investment cost sooner and start making a profit.
Exhibit 1. Top-Down/Bottom-Up Project Management
Exhibit 2. Enterprise Requirements
Exhibit 3. Project Requirements
Exhibit 4. Project Execution Phase
If an enterprise can implement an improved process sooner, it can start saving money sooner. (Remember, Ben Franklin said: “A penny saved is a penny earned.”)
Next level of “Top Down” is the project manager to the project team. As illustrated in Exhibit 3, it is project management's responsibility to interpret and translate the enterprise requirements, and communicate them in the form of project specific requirements down to the project team when a project is initiated. The key element is the required scope of the project. Schedule and budget are also important, but scope is the thing that drives the schedule and the budget. Any specific goals or objectives the enterprises or the project manager may have for the project must also be communicated. If the project team decides upon additional goals or objectives for the project they must also be communicated down from the project manager to ensure that everyone on the team knows these are now part of the project requirements. (We will get to the Work Packages later.)
The project manager must also lead the project team from the top down. (As an aside, the project manager must lead by example. Unless he or she is willing to do whatever is required to successfully complete the project, the project team will likely not follow.)
Initial Requirements—Bottom Up
Refer back to Exhibit 2. In order for this concept to work, what goes down must come up. Flowing up to the enterprise from the project manager at the initiation of a project is commitment. The project manager commits to meet the enterprise requirements and produce the required Product of the Project. He or she commits to the enterprises to develop the product or improve the process on schedule and within the approved budget. (It is a big commitment comparable to that of the pig to the bacon and egg breakfast.)
Exhibit 5. Project Management Tools
Similarly, what must come up from the project team to the project manager at project initiation is commitment to the project requirements. Look back at Exhibit 3 to see that what comes back up from the project team is task management plans, detailed scope (work) statements, supporting schedules, and estimates. The project team commits to the project manager to perform to the project plan. Only then can the project can commence.
Project Execution—Top Down
The execution phase is primarily the responsibility of the project manager and the project team. In the project execution phase there may still be requirements flowing from the Top Down, but the project manager must guard against the “Scope Creep” and ensure that any changes pass through a formal change management process.
If we examine the top down flow from the project manager to the project team we see leadership again. (We better see leadership again. That is what we do.) The next most important factor is change management. A famous project manager once said; “If you don't manage change, change will manage you.”
Then there are the somewhat intangible guidance and encouragement—another important part of our job.
Project Execution—Bottom Up
Here it is all the project team performance. They do the work required of the project by the enterprise as directed by the project manager to the project plan. The project team performs to the targets, schedules, and budgets. It sounds like it is all connected, but is it really?
The Single Integrated Thread
The question is; “How do we as project managers ensure that all requirements are known and are being met?” There needs to be a single thread from the top-level requirements down to the people doing the work. And, it needs to be integrated so that when all the work at the lowest level in the project is complete, the whole project is complete.
Exhibit 6. Sources of Work Package Data
In classic project management, we learn to decompose the work of a project down to “manageable” elements. We call this approach Work Breakdown and put the results into a Work Breakdown Structure—the WBS. The lowest level of work breakdown is the Work Package Level. At that point we have a clearly defined element of work to be performed that can be assigned to a responsible individual to do or manage.
In Top-Down/Bottom-Up Project Management we take this valuable concept further and decompose all of the project elements—not just the work. We decompose the project objectives, requirements, targets, schedule, budget, and any other key elements down to the lowest level of the WBS. This decomposition, when done in an orderly and comprehensive manner, ensures that all of the key elements of the project are flowed down (Top Down) to the level where the work is done—the Work Package Level. Thus, there is a single thread from the top-level requirements imposed by the enterprise down to the level where the work is done.
Project Management Tools
The project manager has many valuable tools available to assist with the management of projects and project teams. Unless there is a clearly defined project management process in place within an enterprise, the project manager decides which tools to use to manage each project. Exhibit 5 shows several of the tools available.
We have master schedules, Earned Value earning rules, budgets, work statements, targets, risk management, and Work Packages flowing Top Down from the project manager.
The project team reports the status of their efforts from the Bottom Up in the formats dictated by the project manager.
What is missing is integration. There are disparate sources of planning information and direction. A team member could examine the schedule to see where their task is required to be completed. They could also check the project budget to determine the funding assigned to the task at hand. Their work statement could be extracted from the project work statement. In other words, there are many different sources for planning and direction and it is up to each individual work package manager to gather all the elements required to manage his or her task.
There is also an element of risk associated with each work package manager gathering their own requirements and planning data. There is too much opportunity for errors of both commission and omission. Further, it is likely that there will be differing levels of requirements that do not correlate to one another. For example, the schedule may be built down to the third level of the WBS, but the budget is only at level two and the work package at level four. How would the work package manager know when his or her work must be done and how much is budgeted for it? It is the responsibility of the project manager to communicate all of the requirements to the work package manager. The way to do that is to have all of the requirements flow down to the work package level so that the people doing the work know what is required of them.
The Work Package
In the Top-Down/Bottom-Up Project Management approach, the work package is not just a concept defining the lowest level of the WBS. It is a real project document and the mechanism used to implement Top-Down/Bottom-Up project management. It authorizes work. It defines requirements. It dictates when the work needs to be completed to support the overall project schedule. It provides authorized budget from the overall project budget to perform the work. It clearly states who is responsible to complete the work. It tells the Work Package Manager everything needed to know about the work and how it fits into the integrated project plan. When all of the work packages are complete, the project is complete.
Exhibit 7. Sample Work Package
The Work Package document answers the key “reporters questions”—What, Where, When, Why and Who (and also How Much).
Sample Work Package
Let's examine a sample work package by looking at Exhibits 6 and 7.
