Inferior Corporate Support

All organizations are expected to provide assistance and support to the projects that are often the lifeblood of these organizations. Support should be forthcoming from the PM's boss as well as the various designated support groups such as accounting and finance, contracts, graphics, production, manufacturing, and an assortment of matrixed functional elements (such as mechanical design, electrical design, software engineering, etc.). For example, accounting/finance may be expected to provide project cost reports to the PM and the project team on a periodic basis, such as monthly. If these reports are late or incorrect most of the time, the PM is operating at a distinct disadvantage. The PM should not allow this situation to continue. Although finding solutions to inadequate internal support can be a nontrivial adventure, it is usually worth the time and effort necessary to solve such a problem. However, even a good PM may have to enlist the good offices of line management to do so.

The preceding sections present just seven ways a project can go off track. There are clearly many others. If you are a Project Manager or Chief Systems Engineer, it makes sense to understand these and other problem areas so that you can find solutions before they lead to cost and schedule overruns and inadequate system performance. These key problems can be restated in terms of specific guidance to the Project Manager, as described in Exhibit 1.1:

Exhibit 1.1: Selected Ways for the PM to Avoid Problems

1. Review and analyze requirements continuously and in detail and raise problems with requirements with your management and, as necessary, with your customer.

2. Prepare the best project plan that you can and update that plan at least once a quarter; make sure that your plan is concise and readable by your project personnel.

3. Do not accept poor technical performers on your project; insist on the best technical talent who meet the highest standards of performance and creativity.

4. Build a high-energy responsive team that is able to communicate freely and solve project problems; discharge personnel that prove to be incorrigible nonteam players.

5. Maintain high standards of open and honest communication and coordination with your boss, other company people, project staff, and the customer.

6. Monitor project status and progress through informal MBWA, being sensitive to the work habits and needs of your people; establish more formal periodic status reviews.

7. Set up efficient and productive support mechanisms within your company or organization so as to maximize the effectiveness of these interactions; insist upon high standards of performance from support organizations.

Most government agencies develop systems and therefore have been struggling with these types of problems for a long time. They often try, therefore, to provide guidance internally and also to contractors as to issues and prob lems that they have faced in the past. For example, the National Aeronautics and Space Administration (NASA) has been building high-technology systems since its inception and attempted to head off problems by publishing a document called Issues in NASA Program and Project Management [1.12]. The contents of this document are as follows:

1. An Overview of the Project Cycle

2. Systems Engineering and Integration (SE&I) Management for Manned Space Flight Programs

3. Shared Experiences from NASA Programs and Project: 1975

4. Cost Control for Mariner Venus/Mercury '73

5. The Shuttle: A Balancing of Design and Politics

6. Resources for NASA Managers

Clearly, NASA is trying to learn from its history, experiences, and mistakes and have its contractors benefit from the past. A relatively new ''theory'' of management emphasizes ''the learning organization'' and proposes methods of assuring that such learning occurs [1.13]. Learning from one's own as well as another's errors is a basic rationale for this as well as other books.

1.4 THE SYSTEMS APPROACH

The ''systems approach,'' at times difficult to define and execute, is basically a recognition that all the elements of a system must interoperate harmoniously, which, in turn, requires a systematic and repeatable process for designing, developing, and operating the system. The architecture for a system must be sound, and it must at least satisfy all the requirements for the system as set forth by the user or customer. By following a systematic and repeatable ''systems'' process, the developer maximizes the chances that this will be the case.

The key features and results of a systems approach may be stated as follows:

1. Follow a systematic and repeatable process.

2. Emphasize interoperability and harmonious system operations.

3. Provide a cost-effective solution to the customer's problem.

4. Assure the consideration of alternatives.

5. Use iterations as a means of refinement and convergence.

6. Satisfy all user and customer requirements.

7. Create a robust system

Figure 1.1 provides an overview of a systems approach, the elements of which are briefly cited in what follows:

Figure 1.1. Overview of the systems approach.

Box 1: Requirements. Requirements for the system are defined by the customer and user and become the touchstone for all design and development efforts. These are considered inviolate unless a negotiation leads to changes that should be reflected in all contractual documents. Requirements are normally provided in a formal ''requirements'' document. At times, a derivative document called a specification is forthcoming from the customer. The specification, however, is often written by the developer.

Box 2: Project Plan. The PM is able to develop a project plan from the statement of requirements. This is a roadmap (discussed in Chapter 3) for the important aspects of the project. If the key members of the project team have been selected, they will work with the PM in order to develop the plan. If not, they must ultimately buy into the plan as defined by the PM, or modify it appropriately.

Box 3: Functional Design of Alternatives. The architectural design of the system operates at the functional level, that is, it concentrates on the functions that the system is to perform in distinction to how these functions are to be implemented in hardware, software, and human components. Several such designs are configured, each representing a feasible alternative. Often, these alternatives span concepts that range from low cost to high performance.

Box 4: Analysis of Alternatives. Each of the alternatives is analyzed in terms of cost, performance, and satisfaction of requirements. By interacting back and forth between the postulation of alternatives and their analyses, it is ultimately possible to determine the quantitative and qualitative attributes of the various viable alternatives. At the system level, two to four alternatives might be considered desirable.

Box 5: Evaluation Criteria. The analysis of alternatives could not be carried out without the clear identification of criteria against which the alternatives are evaluated. These criteria are derived from the requirements and may include such features as interoperability, growth potential, and societal risk as well as the detailed performance items listed in the requirements document. A formal evaluation framework is normally necessary in order to carry out the evaluation.

Box 6: Preferred System Architecture. This step is a selection of the system-level architecture that is most cost-effective. It represents a choice among the competing alternatives. Many projects go astray because they leap to a preferred architecture without the explicit consideration of alternatives. As an example, this may constitute the selection of timedivision multiplexing as preferred over a frequency-division multiplexing approach for a communications system. System architecture is a very important part of the systems approach and the system engineering and design process and is discussed again in Chapter 9.

Box 7: Satisfies Requirements? We make this step explicit in order to emphasize the significance of assuring that the preferred system architec ture meets all the designated requirements. If even one mandatory requirement is not completely met, then it is necessary to loop back and consider additional alternatives. If all the key requirements are satisfied, then and only then can the project team move on to the matter of subsystem design.

Box 8: Subsystem Design. By knowing the preferred architecture at the system level, it is then possible to move into detailed subsystem design. These subsystems involve the interplay among hardware, software, and human elements. Subsystems are naturally divided into subordinate elements, which can be called builds, configuration items (CIs), components, or other names that can be mutually understood.

Box 9: Analysis of Alternatives. Following a process similar to that utilized to develop a preferred architecture, alternatives are set forth and analyzed at the subsystem level of design. This is critical because there are numerous ways to implement a given function. Issues of timing and sizing are usually important here.

Box 10: Trade-Off Studies. A variety of trade-offs are generally considered in trying to optimize at the subsystem level. These may be power-weight-space-performance trades, attempting to find the proper balance of attributes. An iteration loop is shown explicitly to account for the possible need to postulate additional alternative subsystem designs.

Box 11: Preferred Subsystem Designs. Preferred subsystem designs flow from the previous steps, representing near-optimal choices with all relevant factors explicitly considered in the trade-off studies. At this stage of the process, one is still at the design level and the system has not, as yet, been built. There are some exceptions to this, as with the notion of rapid prototyping of subsystems in order to prove certain critical high-risk parts of a system.

Box 12: Satisfies Requirements? We again wish to make explicit the checking of the preferred subsystem designs to assure that all requirements have been met. If not, an iteration loop is shown that means we are ''back to the drawing board.'' If so, we move on to the physical building of the system.

Box 13: Subsystems/Builds. The physical construction of the subsystems is now in order, occurring for the hardware, software, and human components, and in consonance with the subsystem designs. Builds is used here as a generic name for configuration items, components, subsubsystems, and so on. The physical construction proceeds through the various levels of indenture defined in the design process.

Box 14: Subsystem/Build Integration. After a given build (or CI) has been constructed, it must be integrated with all interoperating builds (or CIs). This is performed at all subordinate levels of the system.

Box 15: Subsystem/Build Test. Physical testing takes place as builds (CIs) are integrated to assure that they work together, are compatible, and perform as required. If integrated builds fail these tests, the process is iterated until the test leads to success. Clearly, all test plans and procedures must be based on the original or derivative requirements. Many people have suggested, especially with respect to software, that a ''build a little, test a little'' orientation is most likely to lead to success.

Box 16: System Test and Evaluation. A final system-level test and evaluation (T&E) step confirms that the system meets both development and operational requirements. This can be a long and protracted step, especially for systems that are to operate in a hostile field environment such as aboard a ship or aircraft. It represents an end-to-end check of the full system and a final verification that all requirements have been met.

Box 17: Cost-Effective Physical System. The result of all the previous steps, and many implicit substeps, is a cost-effective physical system.

Although these steps represent most of the elements of the systems approach, there are several that are implicit and therefore are examined in later chapters. However, this overview explains the key aspects of such an approach. It is intended to lead to a system that meets all requirements and is cost-effective and robust. These terms are examined in the chapters dealing with systems engineering management.

The Project Manager and Chief Systems Engineer are clearly key players in assuring that the systems approach is carried out with discipline and good sense. We now more formally explore their roles and responsibilities in a corporate setting.

1.5 THE PROJECT ORGANIZATION

An illustrative organization chart for a project is shown in Figure 1.2. This chart shows only the project and not the organization in which the project may be embedded, which is addressed later in this chapter.

The Project Manager (PM) is shown at the top of the chart with two other key players, the Chief Systems Engineer (CSE) and the Project Controller (PC). In this book, we strongly suggest that the chief engineer of a project be called the Chief Systems Engineer, stressing that the main task of the chief engineer is the systems integrity of the overall system. Some organizational structures might list the lead engineer as the chief engineer and have the systems engineer and systems engineering function in parallel with the other engineering functions such as hardware and software engineering. Some projects might be more limited in scope and therefore not require some of the functions shown. Others might indeed be larger and include additional func-

Figure 1.2. Illustrative project organization. RMA

= reliability-maintainability-availability; ILS

= integrated logistics support; MMI = man-machine interface.

Figure 1.2. Illustrative project organization. RMA

= reliability-maintainability-availability; ILS

= integrated logistics support; MMI = man-machine interface.

tions such as manufacturing, production engineering, installation, operations and maintenance, and others. We will now consider the specific responsibilities of the Project Manager, Chief Systems Engineer, and the Project Controller.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment