Processes and Tools for Planning a Program - 1,

The first activity for systems engineers on a new product development program is to assist in planning the program. Although planning a program is the responsibility of the program leadership a product development program cannot be properly planned without systems engineering work. Program planning involves defining the tasks to be performed, scheduling the tasks and developing the planning documentation needed to guide the work and the workers. One of the primary reasons product development programs fail to achieve the expectations of management and customers is poor planning. This chapter presents processes and tools that reduce the chances that a product development fails to meet expectations due to poor planning.

This chapter discusses the various plans and documentation making up a product development plan, scheduling the development and touches on the important program management issues of design reviews and supplier relationships that involve systems engineering. This chapter does not distinguish whether systems engineering or program management is responsible for any specific plan item. That decision is up to the development team management. Allocating budget for each task and assigned people to each task are additional planning functions that are not treated here as these activities usually don’t rely on systems engineering other than for estimating the cost of the systems engineering work.

Product development programs are called projects here even though the term projects refer to both product and service developments. The planning for a new product or service development is similar so there is no reason to restrict this chapter to products; besides project is a shorter term than product development program.

Planning Documentation

Documentation is an integral part of project planning. Although not many projects fail due to poor documentation good planning documentation makes a project easier to manage and easier for the workers assigned to the project. Four types of documentation that are typically used on complex projects are discussed. These are the Integrated Management Plan (IMP), the Schedules, the Systems Engineering Management Plan (SEMP) and the System Design Document (SDD). The first three comprise the top level planning documentation. Of course there is considerable documentation needed to back up these top level plans. The SDD is not strictly a planning document but it should be started during the planning phase.

There are two ways to produce poor documents and one way to produce good documents. Poor documents are either so brief or poorly written that there is little useful information for managers overseeing the project and new workers assigned to the project or the documents are so long and detailed that no manager and few workers will ever read them. Surprisingly, most bad documents are those that are far too long to be useful. This is because the project leaders have slavishly followed advice to include everything but the kitchen sink description in these documents.

In the an earlier post it was stated that where ever possible labeled graphical models should be used rather than textual documents. Plans are one of the areas that require a significant amount of text. However, the goal should be to make as much of the plans as possible graphic models such as diagrams and tables. (Tables are included as graphic models here because they are less ambiguous than pure text.)

The Integrated Management Plan - A concise IMP is preferred because the IMP should be viewed as a “contract” between the project team and their senior management. Therefore the document need only address issues at a summary level. This allows the team and management to focus on the important issues without getting mired in detail. Mature organizations have standard procedures and processes for items like configuration management and product assurance. Management needs to know if any tailoring is needed for standard processes but they don’t need to wade through the details of standard processes. Certainly documents like a Product Assurance Plan are necessary but hopefully the organization is mature enough that the plan for any specific project is a tailored version of a standard plan.  Summarizing how the plan is tailored to the specific project is sufficient for the IMP. Any manager or worker that needs to know the details can read the detailed plan.

A good IMP is about ten pages long or less. If it is any longer it won’t be read by managers who are expected to have oversight of the project or by few workers that are assigned to the project. It is quite difficult to cover all the items that are recommended for an IMP in ten pages but it is far better to put effort into a good ten page document than to put even more effort into 80 pages that are never read. A template is provided here for a ten page IMP. Many books and web sites advise far more material be included in an IMP but it’s not effective to produce such tomes and it costs precious time and money to produce them. If a project leader insists that all the detail is needed then include a seven to ten page Introduction and Summary for managers because that is all they are likely to read.

The table shown here is an outline for a seven to ten page IMP. Your project may not have the same required items but this outline illustrates that a useful IMP can be ten pages or less. The suggested number of pages in this table adds to ten pages if the maximum suggested amount is used for every item. The recommended topics provide managers a concise overview of a project and are sufficient to orient new workers assigned to the project. If the resulting IMP is well written then, together with the project schedules, it provides senior managers all the information they need to conduct oversight that ensures that the project is progressing adequately or that the project leaders need help. New workers do need additional information but that is better provided in the SEMP and SDD.

Topic	Number of pages
Program Overview (Milestones, Deliverables with quality level required, Fit with Strategic Goals and a one page Top Level Schedule)	1.5 to 3 pages
Technical Description of System (Intended function, hardware/software overview and any make/buy issues)	1 to 2 pages (Include a top level System Breakdown Structure (SBS) and link to more detailed breakdowns in the SEMP.)
Key Performance Characteristics	0.25 to 0.5 pages (Include links to a Specification document for those needing more detail.)
Work Breakdown Structure (WBS)	1 page of top level only (Put the detail, if needed, in an appendix or link to a separate document, e.g. the SEMP.)
Cost target, Preliminary budget & Sources of funding	0.25 page
Staffing Plan (Preliminary manning forecasts, any critical resources, & any teaming arrangements)	0.25 to 0.5 pages
Key Assumptions	0.25 to 0.5 pages
Summary of major risks and plans to mitigate	0.25 to 0.5 pages and reference a risk register in an appendix
Inter-project cross feeds and dependencies	0.25 page
Capital and facility requirements	0.25 to 0.5 page
Status of Preliminary Support Plans (Configuration Mgmt. Plan, Product Assurance Plan, Environmental Health and Safety Issues/Plans, Logistics and Field Support, etc.)	0.5 to 1 page (Which are standard and which are to be tailored. Say why tailoring is appropriate.)

If an enterprise accepts the definition of the IMP as a contract between the project team management and the enterprise management then there is no reason that the IMP always be a text document. It may be acceptable that the IMP is a set of briefing charts that the team presents to the management and receives acceptance or guidance from the management at the end of the briefing. Since most briefings today use electronic data projected on a screen it is easy to include links to the more detailed plans just in an electronic text document. Including appropriate links to more detailed planning documents makes the briefing charts as complete as any text document.

There are several advantages to this approach. First, it is easier to prepare a set of briefing charts covering the topics of an IMP than it is to write a high quality document. Second, if the team can get the management to set through a briefing then there is no question about whether the management has read the IMP and there should be no question about whether the IMP is approved or not. Also, a briefing allows any ambiguities to be resolved in real time. Finally, the 80 page tome is discouraged because senior management isn’t likely to sit through a briefing that long.

A last but important reminder is to prepare the IMP using an IMP from a previous project as a template and strive to make the new IMP an even better template for future IMPs. This advice isn’t limited to the IMP. Where ever possible look for opportunities to build on previous work and structure work so that the result makes future work easier and faster. This approach to fundamental to executing systems engineering rapidly and accurately.