ABSTRACT
A complex product program requires careful planning and management of its functions The management needs to ensure that resources (people, capital, and equipment) are provided And processes and tools are available to multidisciplinary teams to carry out coordinated technical and management functions to develop and produce the products needed by the customers In addition, collaborative engineering environment, constant reviews of product design and continuously applied management controls, and communication of time schedules, budgets, and costs are provided for successful completion of the product program A large program typically consists of several projects The projects are typically managed by project managers and they report to a program manager who coordinates the progress and accountability of all the projects
This chapter covers the program and project management functions and tools and the systems engineering management plan (SEMP) required to manage the Systems Engineering (SE) process
The life cycle of a complex product can be managed as a program The program will involve the prime responsibilities of designing the right product, producing it, servicing it during its operating life, and finally closing the production operations and disposing or recycling the products The entire program is generally divided into a number of manageable projects such as (1) developing the product, (2) building needed tools and production equipment, (3) building plants and installing equipment to get ready for the production, (4) recruiting and training people to operate the plant, and (5) generating marketing plan and training dealers to sell and service the product Brown (2008) provides additional information on this topic
A program usually contains many projects The outputs of projects are used to create the program outcomes Thus, a program can be either a large project or a group of projects Each project can have a project manager The project manager’s job is to ensure that his/her project succeeds The program manager, on the contrary, may not spend much effort on the management of individual projects, but is concerned with the aggregate result or the end state For example, in an automotive company, a program may include one project to introduce new products to take advantage of rising markets in emerging countries and another project to protect
against the downside of falling markets in developed countries These projects are opposites with respect to their success conditions, but they fit together in the same program
Program management thus provides a layer above the management of projects and focuses on selecting the best group of projects, defining them in terms of their objectives, and providing an environment where projects can be run successfully Program management also emphasizes the coordinating and prioritizing of resources across projects, managing links between the projects, and the overall costs and risks of the program Program manager should avoid micromanagement of the projects; he should leave the project management to the project managers and concentrate on the success of the overall program
The program management functions typically include the following activities:
1 Projects management: (a) Coordinating projects through a master plan management, (b) status reporting, (c) issues management, and (d) resource management
2 Performance management: (a) Cost measurement, (b) benefits measurement, and (c) analysis of business data
3 Change management: (a) Change facilitation, (b) change communication, and (c) workforce training and transition
4 Knowledge management: (a) Documentation and sharing of lessons learned from past projects and programs, (b) management of standards and best practices, (c) outputs of product and process benchmarking, and (d) customer complaints and feedback data gathering
The project development activity requires a lot of inputs The gathered information is used to develop a project plan The key project development activities include the following:
1 Collecting inputs from all stakeholders 2 Creating a common understanding of all the projects 3 Preparing documentation of technical plan, management plan, and SEMP
(covered in section entitled, “Systems Engineering Management Plan” of this chapter) for each project in the program
4 Supporting the implementation and management of the SE process involving development of requirements, functional analysis and allocation, interface analysis, balanced product design, detailed design, designing and building tools and manufacturing facilities, conduction verification and validation tests, sales, marketing and service, and finally retirement of the product and disposal of facilities
Project management is the discipline of planning, organizing, securing, and managing resources to bring about the successful completion of specific project goals and objectives
The traditional phased approach involves a sequence of following five phases to be completed:
1 Project initiation 2 Project planning and design 3 Project execution and construction 4 Project monitoring and controlling systems 5 Project termination
Figure 71 presents a flow chart of the aforementioned activities in relation to a project The project involved a series of tasks to be performed It is important that the project work must be clearly understood with details about all the tasks to be performed, their sequence, resources (people, equipment, and funds) needed, and time required Thus, Figure 71 shows arrows linking the three primary phases (ie, phases 2-4) to the tasks to be performed
Not all the projects will go through every phase as projects can be terminated before they reach completion Some projects do not follow a structured planning and/or monitoring stages Some projects will go through phases 2-4 multiple times Many industries use variations on these project phases
The basic steps involved in planning a project include the following:
1 Develop a work breakdown structure (WBS) (see section entitled, “Work Breakdown Structure” in this chapter) of all activities by listing each task in each of the activities Each task is defined as a group of all steps or actions to be completed to accomplish the task
2 Identify task inputs, outputs, and deliverables 3 Establish task precedence relationships 4 Determine start and finish time for each task 5 Estimate task duration and resource needs to perform each task The
resource needs include headcount needs by disciplines (eg, number of designers, number of engineers, and number of test operators), budget to perform the tasks, and special resources (eg, software applications, training, and product test facilities)
6 Display schedule (eg, a Gantt chart; see section on “Gantt Chart”) Determine critical path (longest time path of planned activities to the end of the project; see section on “Critical Path Method”)
7 Estimate project budget and cash flows (expenses and revenues as functions of time) (see Chapter 8 for more information)
A Gantt chart is a type of bar chart (with horizontal bar segments on a timescale) that illustrates activities in a project or program schedule Figure 72 illustrates a Gantt chart of a product program It provides a visual diagram of all activities in the program on a timescale A Gantt chart illustrates the start and finish dates of all elements or activities in a project or a program Some Gantt charts also show the dependency (ie, precedence network) relationships between activities Gantt charts can be used to show current schedule status using percent-complete by use of shadings or colors of the horizontal bars
The critical path method (CPM) is used for scheduling a set of project activities The essential technique for using CPM is to construct a model of the project that includes the following:
1 A list of all activities required to complete the project (typically categorized within a WBS)
2 The time (duration) of each activity
3 The dependencies (or sequence of completions) between the activities 4 Project beginning and end dates
Using these values, CPM calculates the longest path of planned activities to the end of the project and the earliest and latest that each activity can start and finish without making the project longer This process determines which activities are “critical” (ie, on the longest time path) and which have “total float” (ie, can be delayed without making the project longer) In project management, a critical path is the sequence of project network activities that add up to the longest overall duration
This determines the shortest time possible to complete the project Any delay of an activity on the critical path directly impacts the planned project completion date (ie, there is no float on the critical path) A project can have several, parallel, near-critical paths An additional parallel path through the network with the total durations shorter than the critical path is called a subcritical or noncritical path
The program (or project) evaluation and review technique, commonly abbreviated PERT, is a model for project management designed to analyze and represent the tasks involved in completing a given project It is commonly used in conjunction with the CPM PERT is a method to analyze the involved tasks in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project PERT was developed primarily to simplify the planning and scheduling of large and complex projects It is able to incorporate uncertainty by making it possible to schedule a project while not knowing precisely the details and durations of all the activities
The uncertainty in completion time of each activity is considered by using estimates of optimistic time, most likely time and pessimistic time for each activity The expected time and variance of time for each activity can be computed as follows:
ET (OT MT PS )
=
+ +4
6 =
− (PS OT )
where ETi = expected time of the ith activity in the critical path OTi = optimistic time estimate to complete ith activity in the critical path MTi = most likely time estimate of completing ith activity in the critical path PSi = pessimistic time estimate to complete ith activity in the critical path σi2 = variance of time to complete ith activity in the critical path
The probability of completion of a project [P (T ≤ k)] before a certain date (k), that is, kth day from the project start date, can be estimated by assuming that the total time T of the critical path has a normal distribution with its mean equal to the sum of expected times of all activities (µT) and the variance of the total time (σT2) equal to the sum of variances of task completion times of all activities in the critical path as follows:
P T k T T
( e d≤ =
−−∞∫) 12σ pi
where ( )
2 Y
T T
=
−µ σ
∑µ =
∑σ = σ
If the project has more than one critical path, then the probabilities of completion of each of the paths before a certain date can be computed The probability of completion of the project can be computed by multiplying the probabilities of completing all the critical paths before a certain date (if the paths are independent from each other See the AND gate probability computations as shown in Figure 162)
PERT is more of an event-oriented technique rather than start-and completionoriented and is used more in projects where time, rather than cost, is the major factor It is applied to very large-scale, one-time, complex, nonroutine infrastructure and research and development projects
A WBS in the project management and SE is a tool used to define and group a project’s discrete work elements in a way that helps organize and define the total work scope of the project A WBS element may be a product, data, a service, or any combination A WBS also provides the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control Additionally, the WBS is a dynamic tool and can be revised and updated as needed by the project manager
The outputs of the WBS are generally shown in a series of block diagrams using flow charts and tree structures (eg, with hierarchical levels similar to the decomposition tree shown in Figure 21) Each block represents a task and provides many task details and parameters (eg, time required, dates, costs, and assigned to) A WBS typically displays the following: (1) various elements of the project, (2) distribution of work elements of the project in different tasks, (3) distribution of the cost or budget between the elements of the project, and (4) subdivision of larger work elements into smaller elements Some versions of the WBS may not consider timings or order of execution of the tasks (However, many project management software applications used in WBS analysis can create Gantt charts and conduct CPM and PERT analyses)
Several project management software systems are currently available (eg, Oracle, Microsoft Project, and Project Standard 2013, developed and sold by the Microsoft Corporation; Microsoft, 2013) The software programs are designed to assist a project manager in developing a plan, assigning resources to tasks, tracking progress, managing the budget, and analyzing workloads Microsoft Project allows creation of color-enhanced time charts with milestones, tasks, phases, people, and so on, and can share databases with other applications (eg, Microsoft Excel) Many of the software packages allow online sharing of data between project managers and program
managers Thus, all team members have instant access to the project data and many features such as input changes, assign tasks, create personalized dashboards of projects, view calendars, prepare reports, track project issues, create customized charts and graphs, and assign tasks
Many other tools are available for specialized analyses such as investment analysis, cost-benefits analyses, expert surveys, simulation models and predictions, risk profile analyses, surcharge calculations, milestone trend analysis, cost trend analysis, target versus actual comparisons of dates, time used, and costs incurred and head count These analyses can facilitate communication of project status and improve efficiency and capabilities of project and program managers, especially when these tools are available online and accessible with extensive databases on existing, past, and other similar projects for comparison purposes The tools also allow managers to create different types of project timing, budget, and progress reports for communications and control of project schedules, cash flows, and problems involving different types of risks
The SEMP is a higher-level plan (not very detailed) for managing the SE effort to produce a final operational product (or a system) from its initial requirements Just as a project plan defines how the overall project will be executed, the SEMP defines how the engineering portion of the project will be executed and controlled The SEMP describes how the efforts of system designers, test engineers, and other engineering and technical disciplines will be integrated, monitored, and controlled during the complete life cycle of the product (DOD, 2012; USDOT, 2007) Figure 73 presents a flow chart illustrating the relationship of the SEMP to project work and project management
For a small project, the SEMP might be included as part of the project plan document, but for any project or program of greater size or complexity, a separate document is recommended The SEMP provides the communication bridge between the project management team and the technical teams It also helps coordinate work between and within different technical teams It establishes the framework to realize the appropriate work (or tasks to be performed) that meet the entry and success criteria of the applicable project phases The SEMP provides management with necessary information for making systems engineering decisions It focuses on requirements, design, development (detailed engineering), test, and evaluation; it also addresses traceability of stakeholder requirements and supportability across the project life cycle
The purpose of this section is to describe the activities and plans that will act as controls on the project’s SE activities For instance, this section identifies the outputs of each SE activity, such as documentation, meetings, and reviews This list of required
outputs will control the activities of the team and thus will ensure the satisfactory completion of the activities Some of these plans may be completely defined in the SEMP (in the framework or the complete version) For other plans, the SEMP may only define the requirements for a particular plan The plan itself is to be prepared as one of the subsequent SE activities, such as may be the case with a verification plan or a deployment plan Almost any of the plans described in the following discussion may fall into either category It all depends on the complexity of the particular plan and the amount of up-front SE that can be done at the time the SEMP is prepared
The first set of required activities relates primarily to the successful management of the project These activities are likely to have already been included in the project/program plan, but may need to be expanded in the SEMP (USDOT, 2007) Generally, they are incorporated into the SEMP, but, on occasion, may be developed as separate documents The items that can be included in the SEMP are listed as follows The items and their descriptions provided in USDOT (2007) were modified to meet the needs of complex product development
1 WBS consists of a list of all tasks to be performed on a project, usually broken down to the level of individually budgeted items
2 Task inputs: It is a list of all inputs required for each task in the WBS, such as source requirements documents, interface descriptions, and standards
3 Task deliverables: It is a list of the required deliverables (outputs) of each task in the WBS, including documents, and product configuration including software and hardware
4 Task decision gates: These are a list of critical activities that must be satisfactorily completed before a task is considered completed
5 Reviews and meetings: It is a list of all meetings and reviews of each task in the WBS
6 Task resources: It is identification of resources needed for each task in the WBS, including, for example, personnel, facilities, and support equipment
7 Task procurement plan: It is a list of the procurement activities associated with each task of the WBS, including hardware and software procurement and any contracted or supplier provided services such as SE services or development services
8 Critical technical objectives: It is a summary of the plans for achieving any critical technical objectives that may require special SE activities It may be that a new software algorithm needs to be developed and its performance verified before it can be used Or a prototyping effort is needed to develop a user-friendly operator interface Or a number of real-time operating systems need to be evaluated (verified) before a procurement selection or the level of assembly is made
9 Systems engineering schedule: A schedule of the SE activities that shows the sequencing and duration of these activities The schedule should show tasks (at least to the level of the WBS), deliverables, important meetings and reviews, and other details needed to control and direct the project An important management tool is the schedule It is used to measure the progress of the various teams working on the project and to highlight work areas that need management intervention
10 Configuration management plan: It describes the development team’s approach and methods to manage the configuration of the systems within the products and processes It will also describe the change control procedures and management of the system’s baselines as they evolve
11 Data management plan: It describes how and which data will be controlled, the methods of documentation, and where the responsibilities for these processes reside
12 Verification plan: It is always required This plan is written along with the requirements specifications However, the parts on tests to be conducted can be written earlier
13 Verification procedures: These are developed by the core engineering experts and they define the step-by-step procedures to conduct verification tests and must be traceable to the verification plan
14 Validation plan: It is required It assures that the product being designed is the right product and would meet all the customer needs
The second set of plans is designed to address specific areas of the SE activities (USDOT, 2007) They may be included entirely in the SEMP or the SEMP may give
guidance for their preparation as separate documents The plans included in the first set listed in the preceding list are generally universally applicable to any project On the contrary, some of the plans included in this second set are only rarely required The unique characteristics of a project will dictate their needs The items that can be included in this second set are described as follows The items and their descriptions provided in USDOT (2007) were modified to meet the needs of complex product development
1 Software development plan: It describes the organization structure, facilities, tools, and processes to be used to produce the project’s software It also describes the plan to produce custom software and procure commercial software products
2 Hardware development plan: It describes the organization structure, facilities, tools, and processes to be used to produce the project’s hardware It describes the plan to produce custom hardware (if any) and to procure commercial hardware products
3 Technology plan: It (if needed) describes the technical and management process to apply new or untried technology Generally, it addresses performance criteria, assessment of multiple technology solutions, and fall-back options to existing technology
4 Interface control plan: It identifies all important interfaces within and between systems (within the product and external to the product) and identifies the responsibilities of the organizations on both sides of the interfaces
5 Technical review plan: It identifies the purpose, timing, place, presenters and attendees, topics, entrance criteria, and the exit criteria (resolution of all action items) for each technical review to be held for the project/ program
6 System integration plan: It defines the sequence of activities that will integrate various product chunks involving components (software and hardware), subsystems, and systems of the product This plan is especially important if many subsystems and systems are designed and/or produced by different development teams from different organizations (eg, suppliers)
7 Installation plan or deployment plan: It describes the sequence in which the parts of the product are installed (deployed) This plan is especially important if there are multiple different installations at multiple sites A critical part of the deployment strategy is to create and maintain a viable operational capability at each site as the deployment progresses
8 Operations and maintenance plan: It defines the actions to be taken to ensure that the product remains operational for its expected lifetime It defines the maintenance organization and the role of each participant This plan must cover both hardware and software maintenance
9 Training plan: It describes the training to be provided for both maintenance and operation
10 Risk management plan: It addresses the processes for identifying, assessing, mitigating, and monitoring the risks expected or encountered during a project’s life cycle It identifies the roles and responsibilities of all participating organizations for risk management
11 Other plans: Other plans that might be included are, for example, a safety plan, a security plan, and a resource management plan
This second list is extensive and by no means exhaustive These plans should be prepared when they are clearly needed In general, the need for these plans becomes more important as the number of stakeholders involved in the project increases
The SEMP must be written in close synchronization with the project plan Unnecessary duplication between the project plan and the SEMP should be avoided However, it is often necessary to put further expansion of the SE effort into the SEMP even if they are already described at a higher level in the project plan
The USDOT (2007) guide also provides a checklist to assure that the SEMP includes the following:
1 Technical challenges of the project 2 Description of the processes needed for requirements analysis 3 Description of the design processes and the design analysis steps required
for an optimum design 4 Identification and documentation of any necessary supporting technical
plans, such as a verification, an integration, and a validation plan 5 Description of stakeholder involvement when it is necessary 6 Identification of all the required technical staff and development teams,
and the technical roles to be performed by the system’s owner, project staff, stakeholders, and the development teams
7 Description of the interfaces (or interactions) between the various development teams
The role of the systems engineers assigned to the program is essentially to do what is needed to implement the systems engineering process A carefully developed SEMP will provide a clear roadmap for the systems engineers They should work closely with all other team members, technical and program planning, to ensure that all basic SE steps are followed (see Figures 22 and 25) The role of systems engineers is described in more detail in Chapter 2
A carefully developed and executed SEMP will enable proper implementation of SE during the program; that is, all the SE steps from obtaining customer needs to
the product validation in the product development and subsequent steps during the product operations and disposal stages are completed by the program teams in a timely manner
The value of the SEMP can be summarized as follows:
1 It will facilitate reducing the risk of schedule and cost overruns and increasing the likelihood that the SE implementation will meet the user’s needs
2 It will engage the right specialists at the right (needed) time (because they will know what needs to be done) and make sure that they perform the right tasks (eg, analyses or tests), thus resulting in improved stakeholder participation
3 The product team will be more adaptable, and the developed products and systems will be resilient and meet customer needs
4 All entities within the product will be verified for functionality and thus the product should have fewer defects
5 The experience gained and lessons learned during the implementation of the SEMP can be used to create improved SEMP documentation for the next program
Programs that require separate program management functions, processes, and people for their management are inherently more complex than simple programs that are generally managed by technical persons responsible for the product development (See the story on the cyclone grinder development [case study #4] in Chapter 18) Simple programs do not require additional processes or people to manage the program (the management tasks are generally small and responsibilities in small teams are shared)
Thus, for the management of complex products, the program management should undertake the following:
1 Divide the complex product into manageable number of “chunks” (Note that a chunk can include one or more systems of the product)
2 Create an organization structure with multiple teams (for different systems or chunks of the product) to manage the complex product program
3 Select team members based on their expertise and capabilities to understand the “big picture,” that is, the technical issues related to functioning of the entire product and the interfaces between and within their assigned chunk(s)
4 Train team members to select and apply tools (covered in this book and other tools in specialized disciplines)
5 Require each team to create requirements for assigned chunk based on the customer needs and customer attributes created by the product planning activity
6 Require each team to provide information on status of its deliverables according to their WBS to the program control team
7 Require each team to select and apply necessary tools (covered in Chapters 12 through 16) during the product development phases and report results to their parent team during design reviews and program management meetings
To facilitate timely completion of planned activities, the program management should include the following:
1 Gateways/milestones (timely targeted decision points) in the program schedule (see Figures 14 and 15)
2 Reviews by different specialized areas (by attributes, specialized design and user groups [eg, technical experts, users, service personnel, and maintenance personnel], peer reviews, subsystems reviews, system reviews, etc)
3 Definition of work to be completed at each milestone 4 Formal approval plan to proceed to the next phases 5 Plan to handle disapprovals that will involve rework, delays, and workload
balancing problems (overtime costs and/or program slippage) 6 Good communication on timing status (ahead of schedule, on schedule vs
behind schedule) and related problems
The program management should prepare cost and timing charts to communicate and control costs and timings Various types and formats of charts can be used to control and communicate information on budget levels and comparisons between budgeted costs versus costs incurred and projected costs as functions of time (especially, cost overruns) Figure 74 presents an example of a time chart comparing cumulative budgeted cash flow versus actual expenditure
Hectic pace and staying on top of all relevant internal and external issues or problems that can affect the project or program pose constant challenges to the program management Examples of internal factors are failures in meeting verification test requirements, breakdown of critical test equipment, changes in personnel, bad weather, power outages, and so forth Examples of external factors are delays caused by supplier problems, changes in the state of economy, changes in the budgets, new technical developments that can change program objectives, political problems in countries affected by the program, and so on Thus, the program management personnel must be able to handle multiple problems simultaneously, constantly maintain communication with the lower and higher levels of team organization, anticipate problems, and be prepared for various possibilities Generally, program managers with technical background and familiarity with the technical aspects and issues will
be able to handle and foresee possible developing problems quicker than nontechnically oriented program managers
The component-level problems during the design stage and failures in some verification tests can affect progress of work on the higher product levels (ie, risks in not meeting deliveries of subsystems, systems and product for verifications and validations, effect on costs due to redesign, rework, retests, etc) Therefore, it is essential that technical problems and resulting timing and cost problems need to be tracked and communicated immediately through the higher levels so that necessary corrective or precautionary actions can be taken to minimize the program risks Progress charts on technical issues, timing, and costs need to be kept up-to-date and reviewed through an appropriate reporting structure
Project and program management involve a lot of challenges, even in situations where the path to the desired deliverable seems obvious The difficulties arise due to people, technology, and competition change rapidly Some examples of sudden changes are
(1) the project may be progressing fine until a key team member suddenly resigns, (2) a revolutionary new product is about to be introduced in the market, or (3) a major competitor launches a product almost identical to the manufacturer’s new product The aforementioned situations would force changes in the program The program complexity will only increase over time as the rates of technological innovations have been increasing rapidly Furthermore, changes in organizational culture, working environment, economic situation, and scarcity of resources also add substantial challenges in controlling and successful completion of the programs
