Bid to Win: A Guide to Pursuit, Capture, and Management of Unprecedented or High Technology Projects by Evin Stump - HTML preview

IV Design Your Project

Chapter 9—Use modern programmatic design techniques

We have defined something we call “project design” to include both programmatic design and product design. Product design of course is the design of the product that you will deliver to your customer if your proposal is accepted and you are awarded a contract. We will have much to say about that in subsequent chapters. Our concern in this chapter is programmatic design.

Customer requests for proposal typically have a lot to say about what is desirable in terms of product functionality, and sometimes about what they can and cannot afford. Sometimes they are much less instructive about how you should run the project. Still, most customers are interested as a minimum in having a “warm and fuzzy feeling” that you will manage efficiently and that you will not fail. Programmatic design is the way you try to provide this assurance.

As a bare minimum, programmatic design should respond directly to every single programmatic goal formally stated in the request for proposal, and generally also to ones stated informally by authoritative customer voices unless you have extremely good reasons to ignore them.

A number of “best practices” have grown up in recent years with respect to project planning and management. Not all of them are appropriate for every project. It will be helpful to begin by discussing what a project truly is as a means for understanding why some of these best practices make sense. Then we can discuss the best practices themselves.

The nature of projects

Webster’s New Illustrated Dictionary gives the following primary definition of “project.”

“Something proposed or mapped out in the mind, as a course of action, a plan.”

An Internet dictionary site provides this definition:

“A plan or proposal; a scheme.” Also, “an undertaking requiring concerted effort.”

Clearly, the notion of a project is closely associated with the notion of a plan. The notion of a concerted effort also rings true. Implicit in these definitions, but not clearly enunciated, is the notion of goals. You are not likely to decide upon a course of action or a concerted effort that goes nowhere.

To further flesh out the definition, consider that a project is an agent of change. Its purpose is to change something that already exists, and often to create something entirely new. In a project, that which exists may be replaced, enhanced, or eliminated, or some combination of these.

We bring the notion of change agent into the dialogue because our instincts should warn us that attempts to institute changes can have unforeseen outcomes. Projects of all sizes and shapes are inherently risky to some degree, larger ones generally much more than smaller ones. Therefore, to effectively manage a project requires some understanding of how to manage risk. Some people go so far as to say that project management is project risk management, because without risks, project management could be turned over to the project team, or nowadays even to computer programs that remind everybody what to do next, once the plan is set in motion. We don’t go that far, but we do believe that management of risks is much of what a project manager should be doing, and also a considerable part of what his team should be doing.

The “concerted effort” mentioned in one of the above definitions calls to mind that pursuits and resulting projects virtually always require a mustering of the resources needed to conduct them. The needed resources are seldom standing idle and available where and when the pursuit / project team (PPT) needs them. Resources needed by the PPT that must be mustered include time and money, of course, but also people, materials, equipment, data, information, facilities, and infrastructure.

This mustering and subsequent release of assets to do a one-time job is a key characteristic that distinguishes projects from routine operations in business or government.

A reasonable analogy for the role of projects in human affairs is the operation of an aircraft. Getting the aircraft airborne is a project. Once it is airborne, it flies more or less uneventfully (most of the time!) to its destination, and the resources used to get it airborne are diverted to less stressful pursuits, like drinking coffee and taking naps, assuming you have a co-pilot. A second project is required to get the aircraft safely back on the ground. You should note that common knowledge among pilots is that the most dangerous parts of a flight are the takeoff and the landing, especially the takeoff. By analogy, projects are generally riskier than routine business operations.

Projects begin with the perception of a need for change. Typically, some “project champion” (a person or a group) sees an important unmet need or opportunity, and the project is born. The first step after recognition of the need for change is to define the project’s positive and negative goals. A positive goal is some new state of nature that someone wants to create. A negative goal is a constraint someone does not wish to violate. Typical negative goals are caps on costs, limitations on project duration, environmental constraints, avoidance of undesirable secondary consequences, required practices and processes, licenses, clearances, permissions and the like. Note that the coexistence of negative and positive goals is inevitable in any project, and that this stress assures that there will be risk. The source of risk is the tension between positive and negative goals.

The goal creation step is often contentious, because different people may have different perceptions of what changes are needed, how much time and money should be spent, and what compromises should be made. Project champions and the sponsors of major technology projects who support them typically screen a proposal to initiate a major new project by looking at many alternatives and options before accepting it. Two questions must be answered for any new project: 1) why do this project at all, and 2) why not do some other project instead?

Ultimately, goals are the criteria used to determine if a project has been successfully completed. If all of the goals are unequivocally met, we say that the project is hugely successful. If a few are not quite met, but the deviations are small, we generally concede moderate to good success. Anything less is generally viewed as a failure or at least a near-failure. Most would concede that the following are examples of project failures:

• The partially completed project was cancelled because of actual or likely cost or schedule overruns, or apparent inability to meet positive project goals.
• The cost or schedule constraints were seriously violated, with serious consequences, even though the project was completed—only extreme need for the product kept the project from being terminated.
• There had to be a major and unwanted restructuring of the goals after the project started in order to avoid an overrun condition in cost, schedule, or both.
• The project created seriously bad unintended consequences for the sponsors or for others.
• A vital mission related to the project was not completed.
• Revenues were so small that a financial loss resulted (for projects that have revenue goals).

Programmatic planning is important because it is the medium through which the goals of the project and the proposed means of meeting them are communicated within the project team and to interested stakeholders outside the team. The project plan is a dynamic, not a static entity. The rough plan that was drawn up when the project was first conceived will seldom be a suitable guide to action when the project is running at full speed later on, when 50 or 500 or 5,000 people are involved. The plan is merely an expression of what is currently considered to be the best course of action to achieve the goals. It is not a god. It can and should be changed when it needs to be changed.

In today’s world, it is not uncommon for the plan in a major project to change in some degree almost every day due to new or unforeseen circumstances. Projects tend to be dynamic. This is both good news and bad news. The bad news is that changing a plan takes effort and costs money. And, the new plan must be checked to see if it still permits the goals to be accomplished with acceptable probability. The good news could be that the project team is kept current in what is supposed to happen, so they can adjust their actions accordingly—that is, provided the changes are promptly and clearly communicated to them.

Programmatic design best practices

A well-conceived project plan includes most if not all of the following elements, in one form or another:

• Positive and negative goals.
• Statement of work (SOW).
• Baseline product design.
• Work breakdown structure (WBS).
• WBS dictionary.
• Project schedule.
• Project cost estimates.
• Project budgets.
• Staffing plan.
• Risk management plan.
• Statement of earned value.
• Other plans for the acquisition, retention and use of assets.
• Disaster recovery and business continuity plans.
• Miscellaneous ad hoc plans.
• Record of tradeoff analyses contemplated and conducted.
• Revenue forecast.
• Project metrics.
• Project phases definition.

The project plan can be implemented in many different physical forms. Parts of it typically are conventional text documents on paper. Other parts may be graphical material on paper. A few parts may be graphical material mounted on a wall, such as a master schedule. Increasingly, project plans are maintained in electronic format only, to enable rapid access by computers.

Because plans on major projects may many component parts stored in different locations, it is wise to maintain a project plan index that can be readily consulted by team members.

This index could be used at any time to locate the current authoritative documents and artifacts that define the project plan.

Each of the above listed plan elements is worthy of further discussion to clarify its function and establish its need. We do so here.

• Positive and negative goals. These are the positive and negative goals as agreed with the project customer. See Chapter 2 for further discussion. They are the criteria used to measure project success. Often project goals are scattered widely throughout documentation and sometimes authentic verbal communications received from the customer. The proposal / project team (PPT) benefits enormously if these are collected and catalogued in a well organized database. The cost of the collection and cataloguing activity usually is more than repaid by the elimination of confusion that can be caused by complex goal statements and location and correction of vague or conflicting goals.
• Statement of work (SOW). The SOW describes what the team is supposed to accomplish and by when. The SOW is sometimes integrated into the goals, but may also supplement them separately. The SOW is initially generated by the customer, in its broad strokes. Details are supplied by the PPT. A common mistake made by customers is to let the SOW drift into decision areas best dealt with by the contractor.
• Baseline product design. This is a description of the current concept for the product design solution that is believed will satisfy the goals. A baseline design is typically defined in the form of drawings and specifications. Derivative product requirements and all existing design information plus information about manufacturing or other implementation or support processes are also included in the baseline. These are details that flow from the selection of a particular baseline, as opposed to requirements directly associated with the customer’s goals. It is important not to confuse what the customer wants with what you say the solution should be. The two must be maintained separately to assure integrity of the design process. A baseline is not necessarily a completed design. Early in the project, it could be little more than a conceptual sketch with some explanatory text.
• Failure to maintain an early and unambiguous baseline can lead to project drift and working at cross purposes. Team members must be able to readily distinguish between the currently agreed baseline and other options that are under study as possible baselines.
• PPT members must know at all times and with absolute clarity whether what they are working on is 1) further definition of details of the current baseline, or 2) speculative studies that could lead to adoption of a different baseline in the future. Confusion of those two types of work has led to wasting thousands of labor hours on projects and is a leading cause of cost overruns.
• A change in baseline must be executed crisply, much as a change in direction is smartly executed by marching troops. To minimize waste motion and misunderstandings, the plan must contain a “command language” for implementing baseline changes that is well understood by the PPT. A command language is a consistent means of communication that is well understood by all core team members.
• Work breakdown structure (WBS). The WBS is a hierarchical list of (mostly) product-oriented items to be designed and / or implemented by the team to create the overall product defined by the baseline design. Although purists may insist otherwise, most projects find it convenient to have some elements of the WBS that are not directly product-oriented. For example, in addition to elements for a “Wing” or the “Control System” of an aircraft development project, there also could be a “Project Management” element, and perhaps a “Legal Matters” element. Exhibit 9-1 presents a simplified WBS for an aircraft project.

Exhibit 9-1--Example (Simplified) WBS for an Aircraft Development Project

• Often the same WBS element is used for both development and production, but with an added code of some sort to separate the work. For example, autopilot development might be coded 5.2D and autopilot production might be coded 5.2P. If the project must account for work beyond development and production, such as deployment, operations, and maintenance, the usual practice is to append additional elements to the WBS, many of which may not be product oriented, such as fuel and crew costs, and airport access costs.8
• The customer may (or may not) specify the top two or three levels of the WBS. The contractor usually is expected to define any lower levels needed for effective project management. In practice, work breakdown structures that go beyond four or five levels deep are difficult to manage.
• WBS dictionary. The WBS dictionary is a description of the work to be accomplished for each WBS element. Such descriptions are sometimes referred to as “work packages” and may include budget and schedule allocations and a wealth of other information. Creative variety abounds in the way projects handle the WBS dictionary function. The important thing is that there must be a way for core team members to understand the nature of what is (and what is not) included in each task beyond a simple title such as “Autopilot.”
• Project schedule. Every project of any importance must have a schedule so that team members know, as a minimum, when tasks are supposed to begin and end. If all tasks are sequential, that information can be conveyed by a WBS listing with begin and end dates appended (see Exhibit 9-2). Using the horizontal bar chart graphical technique expands the simple listing into what is known as a Gantt chart (see Exhibit 9-3). A Gantt chart contains essentially the same information as a simple listing of dates, but makes it easier to visualize. In a Gantt chart it is also possible to portray concurrent tasks.

Exhibit 9-2—Simple Sequential Schedule

Exhibit 9-3—Simple Sequential Schedule Expressed as a Gantt Chart

• In modern practice, the Gantt technique if often used to depict simplified versions of project schedules for uses such as customer and management presentations, but large, important projects almost always will create as well a full-fledged schedule network. A schedule network is a schematic that typically depicts tasks as rectangular boxes with interconnecting lines (other styles are sometimes used, but this is the preferred style). The interconnecting lines show the dependencies among tasks, that is, what must be completed before a given task can be started. Exhibit 9-4 shows a simple example of a schedule network. A major advantage of the schedule network method of schedule presentation is that you can use it to find the project critical path. The critical path is the longest path through the network, from project beginning to project end. It establishes the total duration of the project.

Exhibit 9-4 Schedule—Tank Purging System Schedule

• In Exhibit 9-4 there are four paths (left to right) through the network. The longest path is ten weeks, and for it the boxes are shaded. The three tasks on the critical path need more management attention than other paths because any delay on this path stretches out the whole project. All of the other paths have “slack,” that is, delays up to and including the amount of slack will not affect the overall project duration. Your customer will be pleased to know that you understand which tasks are on the critical path, and that you intend to give them extra management attention so that they won’t be late in completing.
• The task Manage Project in Exhibit 9-4 is not actually a path through the network. It is an example of a spanning or bridging task, also called a “hammock.” All spanning tasks assume the length of the tasks they span. The Manage Project task spans the entire project, so its duration is equal to the length of the critical path.
• In the exhibit, task duration and cost are shown for each task. This illustrates that many different types of information can be shown in task boxes in a schedule network. Other information that might be shown is a start and an end date of each task, name of task manager, and so forth.
• Start and end dates of tasks that have slack are ambiguous unless some kind of rule is specified. The most common rules are As Soon As Possible (ASAP) and As Late As Possible (ALAP). ASAP is the most common rule, perhaps because it gets things done early and minimizes the chance that some delaying event that occurs can cause a late completion. ALAP is sometimes used to delay cash flows associated with tasks, or to level labor resource requirements. Start time rules intermediate to ASAP and ALAP are also used for manpower leveling.
• The tasks shown in a schedule should be the same ones shown in the WBS, and should have exactly the same names. This rule is sometimes ignored to the confusion of all concerned.
• Remember: a WBS is a hierarchy, and a schedule, especially a network, may or may not be expressed as a hierarchy. Frequently, a schedule network will show only the lowest levels of the WBS hierarchy.
• Project cost estimates. Project cost estimates are preferably made for each lowest level task in the WBS. Sometimes they are made at higher levels, because of use of some preferred estimating process that does not lend itself to estimating at the lowest level. If this is done, we recommend that allocations be made downward to the lower level tasks in some rational fashion. This allows all lowest level tasks to have both an assigned duration and an assigned cost. This can useful in several respects, for example in trade studies, risk analyses, and task management.
• Cost estimates are usually made separately for labor costs (based on labor hours), material costs, and other costs, for each task listed in the WBS, and each fiscal period of interest (often monthly, but sometimes weekly or even daily). The cost estimates must be based on the baseline product design and other parts of the plan concerned with implementing the baseline product design.
• It frequently happens that various parts of the cost estimate are made using different cost estimating methods. This is perfectly acceptable. The best available method should be used for each estimate.
• Project budgets. Budgets are financial allocations to groups or functions within the team that show how much they are authorized to spend and when. Typically, the budgets are based on the cost estimates, except for funds held in reserve by the project manager as a means of dealing with risks and problems. (Sometimes project budgets have no connection to estimates. This can happen when the project sponsor says “This is all the money I have—live with it,” and the project does not shrink to conform. This unfortunately common situation is a recipe for project disaster.)
• Staffing plan. The staffing plan describes by name or at least by skill category each person expected to work on the project. The plan also identifies which functional group in the project team each person is to work in, and who leads that group. The staffing plan also shows how many hours each person or skill category is supposed to work in each fiscal period, and on which tasks.
• Risk management plan. The risk management plan usually comprises descriptions of identified risks and their possible project impact, plans for avoiding or modifying risks, the accomplishments to date in modifying risks, and the special expenditures budgeted or incurred to modify risks. Persons responsible for risk mitigation actions are also usually named.
• Statement of earned value. A statement of earned value compares what has been done and what has been spent at the present time with what the plan calls for. It is a measure of success to date in overcoming risks and problems. It also can be extrapolated to roughly predict future success (or failure).
• Other plans for the acquisition, retention and use of assets. If appropriate, there may also be other plans for the acquisition, retention, and use of various assets, such as capital assets, raw materials, manufactured items, expendable items, computers, data services, consultants, utilities, local transportation, etc. From a risk management standpoint, such plans should always exist and be scrupulously executed unless the availability of the assets is otherwise assured.
• Disaster recovery and business continuity plans. It may be appropriate to have disaster recovery plans and also business continuity plans that are not necessarily limited to natural disasters. A disgruntled employee may do more damage than a hurricane. An embezzler can wreak financial havoc. In today’s computer dependent word a server or data line failure can put a project out of business, at least for a time.
• Miscellaneous ad hoc plans. Various other plans may also be needed, such as for human safety, quality control, hiring, etc. The general rule should be, if something is important to avoiding project failure, or hurting people, or loss of vital assets, have a plan for it, and make sure the plan is followed.
• Record of tradeoff analyses conducted and accomplished. The baseline product design, as it evolves, is always the result of tradeoffs between design options.
• These tradeoffs typically include customer satisfaction, cost, schedule, and risk, among other factors. It is important that the project team not lose sight of how it came to select the current design baseline, while moving away from previous design baselines. Loss of this understanding can result in confusion and “reinventing the wheel.”
• Revenue forecast. Many major projects are managed totally from a cost perspective, even though they may generate revenue after or even before project completion. But if revenue generation is expected as part of the scope of the project, then the plan for revenue generation should be included as part of the project plan. Once the time has come when revenue is expected to flow, the actual flow of revenue should be recorded and compared to the plan. Activities to ensure or enhance revenue flow should be recorded.
• Project metrics. Project metrics are records of trends in major results related to satisfaction of goals and derivative requirements. For example, if maximum product weight is a key requirement, then a record that tracks computed or actual weight as the project proceeds is a vital metric. Metrics are important to an understanding of how well the project is meeting positive and negative goals and derivative requirements.
• Project phases definition. One last aspect of project plans needs to be discussed before moving on—project phases. Larger projects typically are divided into several major phases. There are many preferences for how to do this, and often the project team must follow the scheme of phases decreed by the customer. A generic scheme for phases that has wide acceptance follows:
• Concept. This is the initial phase wherein the need for the project is first understood, and advocacy for it begins to build. The key positive and negative goals are roughed out. Steps may be taken to alert or even solicit help from organizations that may later be involved, such as potential prime and subcontractors, or other departments within the same organization and to solicit from them advice on how to structure the project. The costs of the concept phase are often not considered to be project costs, but bid, proposal, or business development overhead expenses.
• Business case development. In this phase the value of the project is initially assessed. This phase often runs more or less concurrently with the concept phase. The assessment may be done based on a number of different criteria, such as return on investment, net present value, internal rate of return, competitive positioning, customer satisfaction, long term stability, effectiveness, survival, mission objectives accomplished, etc. Government projects often use value measures such as benefit / cost ratio or cost effectiveness. It may be more appropriate in a military project to use the phrase “threat case development” rather than “business case development.” Usually business (or threat) case development includes some consideration of inherent risk, as well as it can be understood at the time. Contractors or other performance agents are contacted and qualified. They may submit rough order of magnitude cost estimates. If a formal proposal is required either internally or externally, it is prepared as part of this phase. The costs of the business case development may not be considered to be project costs, but rather bid, proposal, or business development “overhead” expenses.
• Preliminary design. In this phase, available product design options are explored and traded off, and at least the first baseline design is created. High-level derivative requirements and specifications are developed. Needed project sites are explored and surveyed. Some may be acquired. Study of logistics, safety, reliability and support begins. Critical designs requiring long-lead procurement are detailed. Development and qualification testing is performed. Analyses, simulations, studies, etc. are done, and models, prototypes, and pilot plants are created and tested. The phase typically ends with a comprehensive product design review.
• Detail design. In this phase the entire design is detailed in specifications, drawings, and reports. Tooling and other implementation aids are designed and built. Support equipment and facilities are designed and built. Product validation testing is performed. Implementation and deployment planning are completed. Critical material is acquired. Sites not already owned or otherwise available are acquired. Sites are prepared for implementation and deployment. The phase typically ends with a comprehensive product design review.
• Implementation. In this phase the product is created. The means of creation vary with the nature of the project. In hardware projects, implementation generally means manufacture. In software projects, it means design, coding, test, and related activities. In construction projects, it means construction work at the site, and related support activities. In a health care project, the product could be a set of procedures to be followed, or it could involve the acquisition and use of new diagnostic tools. In a financial project, the product might be a new instrument for investment. Creation of the product ends with acceptance and deployment.
• Operations and support. In this phase the product is operated and supported in its deployed state. Maintenance, adjustments, retrofits and repairs are performed. In many projects, this phase is not the responsibility of the team that created the product, yet it may have large inherent risks, such as warranty costs, for the sponsor or other stakeholders.
• Retirement. In this phase the product is retired and disposed of. This may be irrelevant to some projects, but to others, such as the aircraft industry, chemical plants, factories, or especially the nuclear power industry, it is a major factor. Retirement is not always considered to be a part of the project. In smaller projects, it may be regarded