8 Project Engineering Management Practices
8.1 Introduction
A successful engineering project, from the installation of new equipment to the construction of new facilities, requires established processes to plan and manage the project. These multifaceted processes include, but are not limited to, planning and managing scope, defining appropriate deliverables, monitoring and controlling schedule, cost, quality, resources, and risk. Communication between the various workflows of a project, as well as with stakeholders, is critical to the success of a project.
The "good engineering practices" required to ensure success (meeting cost/schedule estimates at the appropriate level of quality) are the same, although the scale is certainly different. Relevant practices are described in this chapter.
See Appendix 5 for additional materials on project engineering management practices.
8.2 Project Requirement/Scope Definition
8.2.1 Project Charter
Purpose/Intent
The project charter formally documents the agreed agreements on business objectives, definitions, motivations, assumptions and potential risks, constraints, and key milestones. It may also include things like project budget estimates and project governance structure. The project charter is used to initially communicate and document the project requirements (commercial and technical). The identified requirements can be used as a basis for the development of a project design brief and/or project scope document.
input
Typical inputs typically required to create a project charter include project objectives and rationale, a list of key stakeholders (usually at the corporate level), potential project teams, budget estimates, high-level schedules, impact assessments, feasibility studies (which can be done early or late depending on the project), and more.
output
The output is typically a project charter document approved by the project manager and confirmed stakeholders. It is not typically considered a lifecycle file, but is archived along with the project documentation.
liability
A project charter is typically created by the project manager and submitted to a confirmed set of stakeholders for review and approval.
Time
A project charter is usually created and approved before the project starts.
8.2.2 Project Design Introduction/Project Requirements
Purpose/Intent
A project design brief document, also known as a project requirements document, provides a more detailed description of the project's objectives and background/context. It can include project scope, deliverables, budget, resources, how success is measured, governance and reporting requirements, communication plans, issues and risk management processes, review and approval levels of project documentation, and lessons learned.
The project briefing document helps establish clarity and consistency, while identifying inefficiencies between internal and external partners in the project.
input
Typical inputs typically required to create a project brief document include information about the background and key issues driving the project, clearly defined scope, high-level project requirements, time required for project implementation, key milestones and deliverables, estimated budget and resource planning, etc.
For a typical project, the key input is the identified product and process type, as product and process knowledge supports the initiation of a comprehensive QRM-based C&Q process. Note that it is usually not necessary to explicitly identify the CQA of the product and the CPP of the process at this stage, and in some cases, generalized inferences can be made. For example, for a well-established process type like sterilization filling, CPP can be assumed based on the general understanding of the industry. Similarly, CQA inferences can be made based on the identified product types. This is especially important for similar contract manufacturing organizations and facility projects, where a clear CQA and CPP are often not known.
output
The output is typically a project brief document that has been reviewed and approved by identified key stakeholders.
liability
Project managers are usually responsible for creating project profiles.
Time
Project briefs are typically created at the same time prior to the project kickoff meeting and should be completed and approved prior to the start of the project.
8.3 Project Infrastructure (Site/Project Procedures)
Site/project engineering activities should be performed according to clearly defined procedures and processes. These procedures/processes can be developed, referenced, and/or used from a variety of scenarios, such as:
• References and use of existing sites directly from the site where the project will be carried out
• Consistent with company procedures, developed specifically for projects (e.g., greenfield projects) and will be adopted by new sites
The engineering organization should have procedures in place that cover the scope of activities expected within the project, including appropriate governance procedures, which can be generic or used for individual projects. These programs can be developed as part of the infrastructure of an engineering organization or specifically for a project as needed. The following is a list of proposed procedures/subject areas (depending on the size of the project/site, the subject areas can be individual procedures, or programs that are broken down into multiple process-specific processes as needed):
• Applicability of C&Q methods and EQPs
• Project organization and reporting structure
• File strategy and workload planning
• Planning, schedule, and cost reporting
• Procurement process
• Document management, including retention and storage standards
• System Boundary Definition: In a project, all stakeholders (e.g., manufacturing, project engineering, automation, maintenance, etc.) agree on the most logical boundaries of the project system. See Chapter 9, Section 2.
• Project and Operational ECM: See Chapter 7, Section 2.2.
• Design Review: See Chapter 9, Section 9.5.
• HSE Safety Audit: This is usually a hazard and operability study, but it can also be a review similar to a "what-if analysis" or "process hazard analysis" depending on company practice.
• Problem/Defect List/Non-Conformance Management (Design, Construction, and C&Q): A process for documenting all issues that occur during the detailed design, construction, and C&Q phases. See Chapter 7, Section 3.1.
• Mechanical Finish: See Chapter 10, Section 10.3.2.
• Drawing Verification: A process that defines the timing of specification checks, marking instructions, and verification of the scope of requirements during the construction and C&Q phases.
• Handover Package (TOP)/System Documentation: Documents delivered by the system, suppliers and/or buildings can be submitted by the system; Documentation required for the C&Q phase, as well as documentation to support subsequent operations/maintenance and automation. See Chapter 10, Section 10.5.
• Engineering Quality Control (Definition of Engineering Standards)
• Project closure procedures: lessons learned, continuous improvement, completion indicators, etc.
8.4 Project Planning and Organization
To ensure the successful achievement of project objectives, the project should have a clearly defined organizational structure, clear roles and responsibilities, and associated procedures. Project planning and organization should be documented in an approved plan or include several sub-plans within a master plan, depending on the size and complexity of the project. This document is sometimes referred to as the Project Implementation Plan or Project Master Plan. See Appendix 6 for an example of a project execution plan.
Project planning should consider the following areas, including the content of the project plan: scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholder management.
8.4.1 Scope
The development of a scope management plan and the elaboration of the scope of the project should begin with an analysis of:
• Information contained in the project charter
• Any approved sub-plans (e.g., procurement, resources, etc.)
• Historical information (plans, processes, policies, procedures, and knowledge bases) contained in the organization's process infrastructure
• Any internal corporate factors (e.g., organizational culture, geographic distribution, infrastructure, IT software, resource availability, and staff capabilities)
• Any external business factors (e.g., market conditions, socio-cultural influences, legal constraints, commercial databases, government and industry standards, financial considerations, and physical environment)
Note: A feasibility study may also be conducted to ensure that all issues of the project are fully understood and considered in the cost estimation and schedule.
At this stage of the project, the definition of scope should clearly identify the boundaries of the project, including what is in scope and what is out-of-scope, and should be as detailed as possible. It should also define physical and information (IT) interfaces with other systems.
8.4.2 Progress
A project schedule provides a detailed plan of how and when the project will deliver the products, services, and outcomes defined in the scope of the project. It is also used as a communication tool, to manage stakeholder expectations, and as a basis for performance reporting.
The project management team chooses the methodology of the schedule, such as the critical path or the agile method. Then, enter project-specific data, such as activities, planned dates, durations, resources, dependencies, and constraints, into the schedule tool to create a schedule model for your project. The result is a project schedule.
Where possible, the detailed project schedule should remain flexible throughout the duration of the project so that adjustments can be made based on knowledge gained, increased understanding of risks, and value-added activities, while still meeting set project milestones and timelines.
8.4.3 Costs
The development of a cost management plan and a detailed description of the project scope should include the following analysis:
• Information contained in the project charter
• Analysis of progress and identified risks
• Analysis of corporate environmental factors (organizational culture and structure, market conditions, currency exchange rates, published business information and geographic productivity)
• Organizational process assets (financial controls, historical information and lessons learned repositories, financial databases, existing formal and informal cost estimation and budget-related policies, procedures and guidelines)
For more information on Cost Management, see Chapter 4.
8.4.4 Quality
The project quality plan should make clear acceptable quality standards and how they will be achieved and evaluated, such as the review phase, approvals, and quality management of suppliers.
The project quality plan should cover the following:
• Change management process and implementation
• Problem/defect list management
• Uses supplier documentation and data to support system delivery and validation
• Application of risk management strategies (how to manage risk and when to assess)
• Review, review and approval of documents prior to predetermined stages such as Concept, Design Release (IFD) and Design Qualification (IFC).
• Document numbering and version control
• Equipment and instrument identification
• Design and progress review
• Document distribution and control
8.4.5 Resources
A project team should be made up of individuals with roles and responsibilities who work together to achieve a common project goal. Each project should have a well-defined project team with clear decision-making responsibilities and financial authority. Resource planning should be documented (e.g., project organization chart and RACI matrix) and included in the project implementation plan or approved as a stand-alone document. These individuals should have sufficient training and experience to perform their assigned role or should be provided with appropriate training/supervision.
In the resource planning process, the following factors should be taken into account, such as:
• SME and technical experts with the necessary knowledge of products, processes and equipment
• Team environment
• The geographic location of team members
• Communication between stakeholders
• Organizational change management
• International, national and corporate politics
• Cultural issues and organizational distinctiveness
• Other factors that may affect project performance
8.4.6 Communication
Effective communication builds bridges between various stakeholders from different backgrounds, cultural and organizational backgrounds, different levels of expertise, different perspectives and interests.
The communication plan should be appropriately reviewed and pre-approved for the following categories of communications:
• Internal: Focus on stakeholders within the project and within the organization.
• External: Focus on external stakeholders such as customers, suppliers, other projects, organizations, governments, the public, and environmental advocates.
• Formal: Reports, formal meetings (regular and ad hoc), meeting agendas and minutes, stakeholder briefings and presentations.
• Informal: General communication activities using email, social media, websites, and informal ad hoc discussions.
• Hierarchical focus (up/down/horizontal): The stakeholder or team's relationship with the project team will affect the format and content of the message.
• Formal: annual report; Reports to regulators or government agencies.
• Informal: Communication that focuses on building and maintaining the image and visibility of the project, as well as building strong relationships between the project team and its stakeholders through flexible and often informal means.
• Written and verbal: verbal (word choice and tone of voice) and non-verbal (body language and actions), social media and websites, media releases.
The project execution plan should describe in detail the method and frequency of communication, taking into account the size and complexity of the project.
8.4.7 Risks
Organizations should manage project risk in a controlled and intentional manner to create value while balancing risk and reward.
Project risk management should identify and manage risks that are not addressed by other project management processes. If left unmanaged, these risks can cause projects to deviate from plan and fail to achieve clearly defined project goals.
Risks should be documented in the project execution plan or in a stand-alone risk management plan listed as a reference document. See Chapter 3.
8.4.8 Procurement
Procurement planning is the process of documenting project purchasing decisions, prescribing methods, and identifying potential sellers.
The main benefit of this process is that it determines whether and if so, what goods and services are obtained from outside the project, and how and when. Goods and services can be procured from other parts of the organization or from external sources. The project execution plan should define a process for reviewing and managing external sources. See Chapter X, Section X.
8.4.9 Stakeholder Management
The process of stakeholder identification and engagement should be initiated as early as possible. The stakeholders of the project charter are usually at the corporate level. After the project charter is approved, the project manager is assigned, and the team is formed, additional stakeholders will be identified.
Stakeholders should have ownership and responsibility for the project and its outcomes.
Stakeholder management should be integrated into resource planning and communication strategies (as described in Section 8.4) to understand their needs and expectations, resolve issues, manage conflicts of interest, and facilitate appropriate stakeholder engagement in project decisions and activities.
8.5 Project Value Analysis
Rational decision-making approaches regarding project implementation should be defined in terms of their ability to generate value. Value management, which is specific to business solutions, and value engineering, which is specific to technology solutions, should be considered.
8.5.1 Value Management
Value management is a multidisciplinary process that aims to enhance the value of a project from conceptual design to final delivery and the use of project results.
This approach is consistent with the principles of Lean Six Sigma (see Chapter 6, Section 6.2.2) and requires the full involvement of the customer, the project team, and key stakeholders.
Please refer to section 1.7.3 of the ISPE Good Practice Guide for Project Management in the Pharmaceutical Industry [11].
8.5.2 Value Engineering
Systems should be put in place to review proposed technical solutions to ensure adequate quality at the lowest cost, taking into account the total life cycle cost of the proposed solution.
8.5.3 Process Risk Profile and Value Engineering
In regulated manufacturing, risk management must be considered when value engineering is conducted. In cases where value engineering impacts the process risk profile, any changes to the process risk control strategy must be evaluated to ensure that an acceptable level of residual risk to product quality is maintained.
8.6 Project Monitoring and Control
Systems/processes should be put in place to identify the most appropriate way to monitor project progress (ongoing costs, work progress, completed activities) and forecast final costs and completion dates.
The following processes are essential for monitoring and controlling the project and should be performed throughout the duration of the project: Change Management, Monitoring and Control of Project Work, Scope Control, Schedule Control, Cost Control, Quality Control, Resource Control, Communication Monitoring, Risk Monitoring, Procurement Control, and Stakeholder Engagement Monitoring.
8.6.1 Project Change Management
A system should be put in place to manage changes in the project. A change management system should have a timely approach to reviewing change options and determining the most appropriate course of action.
The change management system should revise and modify the scope, schedule, and budget to reflect the selected outcomes. Changes and their potential impact should be communicated to key stakeholders (e.g., users, quality departments, project cost control, and senior management).
The change management system and its associated review and approval methodology should be adapted to the project phase and regulatory impact to achieve effective and rapid change control. See Chapter 7, Section 7.2.
The following aspects of project change management should be considered: For more information on the following aspects of project change management, please refer to the PMI PMBOK® Guide [12]:
• Monitoring and control of project work (see Chapter 5, Section 5.4)
• Scope of control
• Control your progress
• Control costs
• Quality control
• Control resources
• Monitor communication
• Monitor risk
• Control procurement
• Monitor stakeholder engagement
![Cheng Shi: Explore the context of market value management from the perspective of excess returns[fig]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)