3.4.1       Project Management

Introduction - Project Management and SE

Project Management is defined by the Project Management Institute (PMI) as “the use of specific knowledge, skills, tools, and techniques to deliver something of value to people”.  This is accomplished through the application of project management processes throughout the project’s life.  These processes are defined within five process groups covering the beginning to conclusion of a project.  This section will describe the basic processes of project management across the five process groups defined by PMI.

Initiation

The Project Management Body of Knowledge (PMBOK) defines the project initiation group as “the process of formally recognizing that a new project exists or that an existing project should continue into its next phase.”  The Initiation group of project management processes authorizes the project to start, and provides the charge to the project team. This includes determining the vision for the project, document what the project hopes to accomplish, and secure approvals from the organization to develop the project.  The primary output of this process group is a Project Charter which provides a high-level motivation and definition of the project.  The Charter may also serve as an authorization of the project. ITS projects are typically initiated (programmed) through transportation planning activities such as the Transportation Improvement Program (TIP), or the statewide equivalent (STIP).  A Project Charter can build upon the limited project information usually found in the TIP/STIP to provide an initial scoping of the project or for multi-phase projects, this process can be used to validate or refine the decisions made during the previous phases.  The Project Charter as defined in the PMI Body of Knowledge (BOK) addresses the following topics related to the project:

·        Define the purpose, goals and objectives of the project

·        Define Project Scope and Deliverables

·        Define High level Needs for the product or service

·        Define Project High Level Budget, Schedule

·        Identify Sponsor, Key Stakeholders, Responsibilities

·        Project Approvals

Planning

Once the project initiation is complete and the project has the green light to go ahead, the project planning processes can begin.  Project planning starts with the project’s goals and objectives as defined by the Project Charter, the regional ITS architecture, and the needs and constraints elicited from the project’s stakeholders. It identifies all relevant agency policies and procedures used in managing and executing such a project. It uses these to identify the project tasks [both administrative and technical], their interdependencies, estimates of needed resources, and budget for each task, the project schedule and the project’s risks. The result of this planning is the Project Management Plan. This plan identifies the detailed work plans for both the administrative and technical tasks. The plan estimates the resources [people, equipment, and facilities.] needed for each task along with an estimated budget for each task. It identifies key events and the technical and program milestones, and establishes a schedule for the project. Each task’s detailed work plan is developed to identify its needed inputs and outputs and a description of the process used to carry out the activity. Based on project complexity, additional technical plans [e.g., a Systems Engineering Management Plan] and additional administrative plans [e.g., Configuration Management, Risk Management and Procurement] may be included as part of the PMP, or defined as separate outputs.  A template for the PMP is described in Section 6.1.

The Planning processes also include specific activities relevant to the systems engineering aspects of a project which are documented in a Systems Engineering Management Plan (SEMP). SEMP is the top-level plan for managing the systems engineering effort to produce a final operational system from initial requirements. It can be used in conjunction with a Project Management Plan which defines how the overall project will be executed, to define how the engineering portion of the project will be executed and controlled. It 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. For a small project, the SEMP might be included as part of the Project Management Plan document, but for any project of greater size or complexity a separate document is recommended.

The information contained within a SEMP can be organized in different ways, but in general it should include an introductory section (including system description, top-level schedule, and relevant documents), technical planning and control, systems engineering processes tailored specifically for the project, and plans for coordinating the efforts of multiple engineering disciplines to accomplish the project tasks. Make sure that the SEMP and the PMP are consistent – it’s fine to reference the PMP in the SEMP and vice versa. The following sections provide additional details on what would be included in the different main sections of a SEMP.  In addition, a template for the SEMP is contained in Section 6.2

Technical Planning and Control – This section describes how the project will be controlled from a systems engineering point of view. It includes the engineering organization and responsibilities, identification of technical and performance monitoring reviews to be held during the project life cycle, the system test strategy, technical performance measurements to be monitored, the configuration and data management strategy, the risk management strategy, and identification of any critical items that may require special risk management. In addition, there are a host of other plans that should be created near the beginning of the project life cycle. Depending on the size and complexity of the project, plans may be small and included as part of the SEMP or they may be referenced by the SEMP as standalone documents. Minimally, the SEMP should identify all of the relevant project documents.

Plans to be described or referenced in the SEMP include:

•         Interface Control Plan, describing the nature of external interfaces and responsibilities of organizations on each side of the interface.

•         System Integration Plan, describing the strategy for how the software and hardware that comprise each subsystem will be integrated with other subsystems to form the overall system and including the dependencies and operational capabilities at each stage in the integration.

•         System and Subsystem Verification Plan, describing how requirements will be verified for the system and each subsystem. This plan may also include the test lab environment(s), tools required, and dependencies.

•         System Validation Plan, describing the approach that will be used to validate the project delivery.

•         Software and Hardware Development Plans, describing the facilities, tools, and processes to be used to produce the project’s software and hardware including development of custom software/hardware and procurement of commercial software/hardware products.

•         Installation Plan, describing logistics for system deployment and installation procedures.

•         Operations and Maintenance Plan, describing the organization, staffing, and processes for operating the deployed system, including maintenance, technical refresh plans, enhancement process, and procedures.

•         Other plans, such as a Training Plan, a Safety Plan, or a Security Plan, may also be needed to address special issues of the project.

Systems Engineering Processes – This section of the SEMP describes the activities to be used for execution of the various systems engineering processes covered in Chapter 3, as tailored for your project. This is a good place to include a discussion of the project’s approach to meeting the requirements of FHWA 23 CFR 940.11/FTA Policy Section VI. This section should include a definition of all high-risk areas, including critical technologies that might pose some challenge for your system. The SEMP will include a list of the tools that will be employed during the development (e.g., a requirements traceability tool).

Coordination of Engineering Disciplines – This section describes how the various inputs into the systems engineering effort will be integrated and how appropriate disciplines will be coordinated with that effort. In a complex project, there will be multiple engineering disciplines contributing to the success of the project. For example, for projects that have a user interface, operability/ human engineering will provide input during the development cycle to ensure that the design is user-friendly and intuitive. If system reliability is a major issue, specialists should assess the design to make sure that it will meet performance requirements. In the SEMP, the dependencies between these various engineering disciplines and the project life cycle will be documented. This will help the systems engineer to make sure that input is solicited from each engineering discipline at the appropriate time and that the right people are at the various technical reviews.

Preparation of the SEMP is a multi-step process that involves the system owner, systems engineer, and the Development Teams. First, the system’s owner (or systems engineer) develops a framework for the SEMP before any process work starts. This includes the organizational structure, a master schedule for the system implementation, and identification of the technical tasks. For each task the SEMP framework identifies the required outputs, and to the extent possible at this stage, the inputs and processes to be performed. The SEMP framework may define a number of other items including a candidate set of supporting plans, metrics to measure technical performance, and the criteria for technical reviews. The SEMP framework will also tailor the technical processes commensurate with the scope and risk level of the project.

Then, the systems engineer and selected Project Development Teams, will take the SEMP framework and supply the needed detail for the processes to be used. This will include preparing any supporting plans, for instance, a Software Development Plan or an Interface Control Plan.

Execution

The Execution Process group defines the processes that should be performed to complete the work defined in the project management plan to satisfy the project specifications. This Process Group involves coordinating people and resources, as well as managing and performing the activities of the project in accordance with the PMP.  Some of the key activities of the process group are:

•         Direct and Manage the work performed per the PMP

•         Acquire and Manage Project Team

•         Conduct Procurements, if needed, by creating Procurement Documentation and getting vendors on-board to perform tasks per the PMP

•         Manage communications, distribute information and manage stakeholder expectations     

Monitoring and Control

Monitoring the progress of an engineering project requires a combination of management and engineering knowledge. The project plan requires an assessment of progress to adjust schedule, along with budget and staffing levels to meet project goals and customer requirements. The ability to assess the merit of reported progress entails knowledge of the underlying engineering efforts, with the possibility of related engineering discipline changing as the project progresses. A method to anticipate project progress is to examine not only concurrent measures of progress, but to consider leading indicators that identify potential issues prior to the project experiencing schedule slips. Table 13 shows representative potential monitoring approaches for phases of an ITS project. Other monitoring approaches may be appropriate depending on the specifics of the project.

Table 13 contains the following information in its columns:

•         Phase: the phase of the SE process that is being monitored

•         Acquired Service: key engineering activity during the phase

•         Measure of Progress (MOP): quantifiable measures that can be assessed to give an indication of the progress in the phase

•         Assessment: suggested method of monitoring the MOP

•         Leading Indicator: additional quantifiable measures that can be an indicator of potential issues with maintaining the schedule, budget, and scope of the systems engineering effort.

 

 

Table 13: Progress Monitoring Alternatives

Phase	Acquired Service	Measure of Progress	Assessment	Leading Indicators
Project Conceptualization	·        Stakeholder Engagement ·        Project Scoping	·        Cost variance ·        Schedule variance ·        Level of consensus ·        Participation level	·        Cost vs plan ·        Progress vs plan ·        Qualitative assessments	·        # of meetings ·        # of participants ·        % budget change
SE Tailoring	·        SE assessment ·        SEMP development	·        Cost variance ·        Schedule variance ·        Analysis value ·        Correspondence to tailoring	·        Cost vs plan ·        Progress vs plan ·        Qualitative assessments	·        # of prior similar projects ·        % Schedule prior to draft
Concept of Operations	ConOps Development	·        Cost variance ·        Schedule variance ·        Document completeness	·        Cost vs plan ·        Progress vs plan ·        Qualitative assessments ·        Review comments	·        # of prior similar projects % Schedule prior to draft
Requirements Development	Requirements Development	·        Cost variance ·        Schedule variance ·        Document completeness ·        Correlation to Needs ·        Requirements quality	·        Cost vs plan ·        Progress vs plan ·        Topics vs plan ·        Qualitative assessments ·        Review comments	·        # of prior similar projects ·        % Schedule prior to draft
System Design	Design Development	·        Cost variance ·        Schedule variance ·        Correlation to Requirements ·        Design quality	·        Cost vs plan ·        Progress vs plan ·        Qualitative assessments ·        Review comments	·        % of proven technology ·        % of custom products ·        # of requirements revisions
Component Design	Design Development	·        Cost variance ·        Schedule variance ·        Correlation to Requirements ·        Design quality	·        Cost vs plan ·        Progress vs plan ·        Qualitative assessments ·        Review comments	·        % of proven technology ·        % of custom products ·        # of requirements revisions
Implementation	Implementation/installation	·        Cost variance ·        Schedule variance ·        Test plan completeness ·        Component testing	·        Cost vs plan ·        Progress vs plan ·        Qualitative assessments ·        Review comments	·        # of design revisions/RFIs ·        % of custom products ·        Schedule variance
System Testing	System testing	·        Cost variance ·        Schedule variance ·        Test plan completeness ·        System testing	·        Cost vs plan ·        Progress vs plan ·        Qualitative assessments ·        Test results	·        # of test plan comments ·        % of failed tests
System Evaluation	Evaluation testing	·        Cost variance ·        Schedule variance ·        Evaluation plan completeness ·        System evaluation	·        Cost vs plan ·        Progress vs plan ·        Qualitative assessment ·        Test results	·        # of evaluator prior projects ·        Volume of ‘before’ data
System Retirement	Retirement planning	·        Cost variance ·        Schedule variance ·        Plan adequacy	·        Cost vs plan ·        Progress vs plan ·        Qualitative assessment	# of dedicated staff

 

 

Closing

The Closing process group includes processes performed to finalize all activities across all Project Management Process Groups to formally close the project or phase.  Key among those processes is performing system acceptance and getting sign-offs.  After review and acceptance of the project deliverables, the Project Manager obtains acceptance of the project.  Another key activity of this process group is post-project or phase review.  Examples of key deliverables for the post project review are the following: 

•         “Lessons learned” document that can be used to improve the agency’s project management procedures 

•         List of potential future enhancements to the project’s deliverables (e.g., a newly implemented center-based systems may trigger users to ask for more improvements)

Two additional activities that are needed for closing all projects are:

•         Close out Procurements, ensuring financial and legal closure

Archive project documentation, which includes collecting all final project documentation.