The Project Plan as a Foundation
3.0 Introduction to Projects
The first management model we will examine is the project or program management role. Let us define a project as the aggregated activities required to create a new product or to significantly revise an existing product. It can be just a few people working together to create some end product, or it can be a large-scale undertaking with thousands of people working to create a complex system. I arbitrarily define a program to be a grander scale of project, perhaps made up of many projects. I will use "project" and "program" interchangeably in this book because in fundamental terms, the scale defines the only difference.
Starting here seemed to make sense for several reasons. First, most start-up companies begin as single projects. In a single-product Enterprise, the project relationships tend to define the organization. Second, the relationships required to successfully plan and execute a project include virtually all disciplines and interfaces in an Enterprise and thus provide a good model for discussing these issues.
This chapter will examine the project planning process and the relationships involved. The next chapter will deal with the project management roles and relationships among the various types of managers in the enterprise. In the process we will build a more specific image of the integral management environment.
3.1 Projects and Plans
In today's competitive environment, product technologies intended to meet a market need --with the possible exception of buttons and wire nails -- require an initial development phase with a subsequent transition into a production environment with a minimum of problems and expense. The total set of activities for creating the design, processes, facilities, and materials needed to reliably produce the product at a profitable cost is often called a project, and the orchestration of those activities is project management. The more complex the product, the more complex the project.
The foundation of the integrity of any project is project planning. The project plan defines the anatomy of the project, and is a fundamental tool for communication between the project management team and all the project participants. As such, planning evolves as decisions and strategies are selected, and continues to evolve in response to events as the project progresses.
When a new project is begun, usually those who will later implement production have great difficulty coping with the ambiguities of limited development definition. Much inter-action is required between the definers and the future producers for the project to get the level of definition needed and avoid gross error in scope. If the project plan is not done thoroughly as part of the pre-commitment process, grave danger lies ahead. The type of commitment needed and its attendant risk to buyer and seller is an important subject that will be treated in detail in Chapter 12, Contracts.
3.2 The Project Plan: Its Purpose and Content
A project is like an auto trip on a holiday when all the gas stations are closed. Suppose we want to drive from Syracuse to Boston. What routes can we choose? How much fuel will we need? When do we need to arrive? When are we ready to leave? How fast can we drive? If there's an accident on the thruway, is there an alternate route? What if it snows? The fuel required is analogous to the cost of the project. The route and the transit time define the plan and the schedule. Your time to market is when you need to arrive in Boston. If you can't get there by then, there is no sense in making the trip.
A project or program plan is the basis for common understanding of the tasks required to accomplish all parts of the project. It is therefore the basis for commitments on cost, schedule, and performance of each part of the project.
The plan answers the questions: What is to be done, how it will be done, when the various elements of it will be done, who will do each of those elements, how many of what are needed, how much effort it will take, and why is it being done as planned?
3.2.1 When is the Project Plan Needed?
The initial project plan is needed not only before the project begins, but also before any firm commitments about it are made. While the production process for an ongoing product is repetitive with well-defined and understood processes, a new project involves redefining everything and traversing uncharted territory in many cases. New orders for an existing product can rely on an excellent database, and the innovations are usually limited to carefully controlled tweaking to avoid inadvertent change. The organizational tasks for new orders of an existing product are therefore well defined, and the planning is already in place. Note that an existing product is one currently being produced, or in inventory. It is not one that has been produced before, but is not currently being produced. (That category, which can get you in considerable trouble, lies somewhere in between.)
3.2.2 Who Should Create the Plan?
The ideal answer is that the people who have to execute the plan should create it. In complex projects with many interacting activities, integration is required. Therefore, a master schedule is generally needed with some ground rules to be used for common planning. The plan, then, is really a hierarchy of plans, which also shows the inter-dependency among them. Those who will make the commitments and perform the work for each of the activities should help create the plans for those activities.
3.2.3 How is a Project Plan Different from a Business Plan?
A program or project plan is complementary to a business plan and provides the basis for validating it. The business plan, however, is normally aimed at the financial rationale for doing the project and the investment versus return on that investment, taking into account factors such as the market, the time value of money and risk etc. The project plan provides the data to validate or change assumptions about assets and resources needed, and time to break even in the business plan.
3.2.4 Relation of Plan to Specifications or Other Requirements
A specification defines what is required in the end product. The spec, whether a buyer's document or a seller's document, is normally a requirements document invoked in the contract of sale. The plan, on the other hand, defines what activities will be required to provide the product that meets the spec and how it will be provided as a function of time. The plan is normally not a contract document. It is rather a description of intended approach that faces two directions. It tells the customer what the basis of quote was and therefore what to expect, and also tells those doing the work the approach that was assumed when the job was quoted. As such, the commitments made to the plan are internal contracts within the project. Because it is valuable for both purposes, some contracts may require delivery of that plan just for information. However, it is a living document that should be modified as the work progresses.
3.3 The Planning Process
Figure 3-1 maps the process of a typical project aimed at turning a market need into a cost-effective quality product. We start at the upper left of the chart where the need for the product is identified. Of course, getting to that defined need is itself a non-trivial process and a subject of separate study.
3.3.1 Product Synthesis and Definition
Here, we take it as a given that there is a need for the product with some desired attributes defined at least in principle. We move across the top of the chart to define the requirements for the product. What are the measures of goodness or effectiveness for the product? What are the attributes that maximize those measures? As shown by the arrows going both ways, this process is an iterative one.
The key word here is "tradeoffs." Remember that what we are after is customer satisfaction, and that means meeting the need at an attractive cost to the buyer. What must the product deliver as a minimum? What is additional capability worth? Operations research skills can be especially important here to evaluate the sensitivity of customer mission and cost requirements to the capabilities the company is able to offer. What can we provide? Is it feasible to make this product for the selling price the marketing experts say is needed? Do we have a distinguishing product concept? What is the competition able to deliver? In this critical phase of the project we are doing preliminary straw-man designs and straw-man project plans -- checking feasibility and refining requirements. This is the phase where euphoria is a danger. When overly optimistic assessments are made, and the voices of reason are drowned out, bad things follow.
3.3.2 Defining the Approach
In Figure 3-2, the detailed project planning process, which is critical to success, starts at the upper right of the chart and flows down the diagonal to the lower left where a go/no-go decision must be made. Note that this planning process is also iterative and is going on in concert with the product definition. At the end of the planning process we know what our product strategy is; what the design approach is; what activities must occur; when they must occur; what facilities and resources will be needed to accomplish the plan; and we have a pretty good estimate of the cost and time it will take. If done collaboratively and with integrity, it is a plan that can be implemented. If this plan meets the criteria of the market need and is feasible as judged by the team and the final decision-maker, the project is launched.
3.3.3 Getting Buy-in
At this point more people generally join the team, and a major danger is that the newcomers have a tendency to disclaim all that has gone before, and reinvent the whole thing. How do we prevent this lack of ownership?
The answer is simple, but not always easy. It is to get buy-in during the planning and concept phase from those who will implement the project. One effective way to do this is with what is currently called an integrated product team (IPT). The IPT concept and concurrent engineering are discussed in more detail in Chapter 4.
The key concept for successful IPTs is to get empowered representatives of all the disciplines that add value during the creation of the product working together from the outset to define both the design and the plan. This includes the requirements definers, the design engineers, the test team, the buyers of materials and components, the manufacturing team and subcontractors, and the quality assessment, maintenance, logistics, and distribution folks who have to get it to the market. Make sure that they have a stake in the outcome. That is what ownership is about.
3.3.4 People Are the Key and They Are Only Human
It should be evident that the most important ingredients in any project are people and how they interact to plan and execute the project. Since all of us have strengths and weaknesses, one key to successful projects is to bring the strengths together and compensate where there are weaknesses.
The engineering activity is central to both the definition of the product and the planning for any successful product development, but engineers often suffer from one or both of two weaknesses. First, engineers are generally trained more to deal with things and ideas, not people problems. Second, many engineers don't like to commit to a plan until they have finished the engineering. The "I'll tell you when it's ready" approach may give the engineer a feeling of security, but it is anything but collaborative. If you are the person who has to provide the manufacturing tooling by a certain time, or the building where the product will be manufactured, you can't accept that answer. The effective process is to consider all of the other members of this collaborative team as your customers. For a plan to be realistic and successful, commitments must be made and then met. In short, both the design and the planning must have integrity.
3.3.5 Optimum Usually Isn't!
Beware of people who bring you "optimum" solutions or plans. Optimums are a mathematical concept with limited use outside that field of study. This is an important admonition that applies to projects, designs, organizations, and almost every other facet of life. What you are usually offered with this engaging adjective is a sub-optimized plan or solution that ignores some important parameters. Check it out!
3.4 Implementing the Plan
Even the best planning cannot anticipate every eventuality. That is why a plan is a living document that will be modified several times during the execution of the project. This modification must be done in a controlled fashion so everyone involved is reading from the same page, so to speak. An effective way to do this is to use program baseline designations such as "A", "B", "C" for major block changes. Interim decisions or incremental changes can be documented via individual coordinated memos. When significant re-planning is required, a block change to the baseline can also incorporate the incremental changes.
Project implementation management roles and relationships are discussed in detail in Chapter 4. Later chapters address the specific disciplines that are required to implement a project.
3.4.1 If It Can Happen, It Will! If It Can't Happen, It Also Will!
As this suggests, sometimes, in spite of the best-laid plans and good execution, something unexpected and ugly occurs that demands decisive corrective action. Suffice it to say here that if you are the project manager, while the team focuses on executing the plan, you must be looking ahead, watching for trouble and asking yourself where the risks are, and "what if? " Some contingency plans and back-ups can be implemented for only $1.98 more, figuratively speaking. They can often save you many times what they cost.
First-hand experience in project management inspired some wag to define six phases of a typical project, shown here. These phases often apply -- even to very successful projects, which may have plenty of bumps and surprises along the way. By the way, somewhere between phase three and five is where the project manager gets replaced.
SEARCH FOR THE GUILTY
PUNISHMENT OF THE INNOCENT
PRAISE AND HONORS TO THE NON-PARTICIPANTS
These are the times that test the courage and integrity of managers. Management by wishful thinking can't get you there. It helps to maintain some sense of humor and irony at those times. Here are a couple of apt one-liners I have come across
"Today is the first day of the rest of the trouble" - author unknown
"I only dread one day at a time" - Charlie Brown to Linus at the wall in "Peanuts" by Charles Schultz.
Just be sure these don't become your real philosophy.
3.5 Estimating the Impact of Program Changes
We know that funding, whether internal or external to the enterprise, is the fuel that shapes the program plan. The development of the details of a program baseline plan involves a great deal of effort in task and resource planning by all members of the implementing project team. These detailed plans and the means to monitor performance against them are discussed in chapter 8 on cost management. Given that detailed baseline, when program changes are required, it is almost always necessary to estimate the impact on cost and schedule before doing a detailed re-plan. The following discussion offers a method for assessing these impacts by using the current well-defined baseline as a point of departure.
Figure 3-4 shows a sample program funding profile by fiscal year along with a cumulative funding curve. Proposed funding profile changes are also shown. We can evaluate the effect of a funding reduction or increase in any given year. The example shows a reduction in FY '03, which is not restored until FY '06, as shown in the lower curve against its scale on the right side of the chart. The upper curve with its scale on the left side of the chart is the cumulative funding of the project. The dashed curve shows the effect of reduced cum funding and allows evaluation of how various milestones will be approximately effected based on the principle that the cum funding up to the time of that milestone determines when that milestone can occur. We can see in this example that key milestone 1 in FY `04 will slip 6 months and key milestone 2 in FY '05 will slip 9 months.
Figure 3-4 Funding Change Example
This technique as the first step allows a rebalance of all tasks in the project to determine the minimum overall impact, but does not account for the cost effects of moving effort downstream or the effects of constraining labor profiles both in-house and at suppliers. Once step one is done for each portion of the project, the effects of time-shifting of resources can be determined as described in Figure 3-5.
The methodology of these two charts is what I call the principle of optimum baselines, which premises that a baseline program has been planned and is being implemented in efficient fashion and any change which does not reduce scope is a perturbation which will have an adverse impact.
Figure 3-5 Effect of Slips on Resources
A slip in a key milestone can occur either due to a funding limitation, or a problem in a prior activity that forces a delay in downstream tasks. The two cases shown in Figure 3-5 have different effects because they occur at different phases of the activity. In case one, the slip has occurred during the buildup of headcount on the project. In this case, when the slip is initiated, headcount is frozen at the level on board in house and at all suppliers at the time the slip occurs. As a result, less funding is required during the last half of the fiscal year `01, and in fiscal year `02, represented by the difference between the original labor profile (the solid curve), and the dashed shifted curve. This funding must be added back in subsequent years as reflected by the six-month shift in all downstream effort, remembering to account for escalation associated with the shift in resources to later years.
However, reassignment and rehiring, shortages from prior delayed work and other disruption factors will cause the work accomplished during the 6-month slip as a rule of thumb to be only 50% effective toward meeting future milestones during this period. In order to prevent the overall remaining activity from further slippage, this 50% lost productivity must be added to the total funding and specifically in the period immediately following the slip -- FY '02 in case one.
Case 2 provides a different situation where the slip occurs during the tail-off of labor. Since the effort to complete requires the same area under the “to go” curve after the slip, the headcount must again be frozen at this level when the slip begins. In this case, the same rule of thumb applies where the added effort during this time will be 50% effective toward accomplishing downstream milestones and therefore only 50% of this added effort during the slip will increase total project cost. As before, the pricing of shifted resources must also account for escalation associated with the time shift.
I believe that the recipe for success in managing a project is summarized as follows. The elements are simple and obvious, but that doesn't mean they are followed. It always amazes me how uncommon common sense really is. Your job as an "integral manager" will be to practice these principles consistently and encourage them in others.
Remember, as a manager, you will not be the only one who makes the project succeed; the people who work for you will. You don't have to master every technical discipline involved in creating the project; you don't have to review and approve every single action in the course of development; but you must create an environment where people are empowered to do their jobs with integrity. Communicate your expectations of them as clearly as you can, give them the authority to do the job, and hold them accountable. Coach them, lead them, make decisions when necessary, but let them help make the whole team succeed.
THE SECRET FORMULA FOR SUCCESS
MAKE TIME YOUR ALLY, NOT YOUR ENEMY: PLAN!
GET TEAM OWNERSHIP OF THE PLAN
YOU MAKE LUCK. IT ISN'T SOMETHING THAT HAPPENS TO YOU.
EXPECT THE UNEXPECTED. YOU WILL RARELY BE DISAPPOINTED
FOLLOW YOUR CONVICTIONS, BUT ASK "WHAT IF?"
In this chapter we have discussed the underlying philosophy of sound project management. In the next chapter we will examine the details of management interrelationships when a project or program becomes large enough to involve multiple organizations within a larger Enterprise. At that point we will see how some of these principles are implemented.
Copyright © 2001 L. David Montague. All rights reserved.