project management

Module 2 : Project Integration and Scope Management (Created by Dr A Cabello 2020)

Institution: Platform Site: ENGG951 (S221) Engineering Project Management

Book: Module 2 : Project Integration and Scope Management (Created by Dr A Cabello 2020)

Printed by: Dixitkumar Pravinbhai Patel Date: Thursday, 9 September 2021, 5:21 PM

Table of contents

1. Project Categorisation and Prioritisation (Activity 1) 1.1. Strategic Alignment 1.2. Financial Models for Prioritisation (Activity 2) 1.3. Multi Criteria Models for Prioritisation

2. Introduction to Project Integration and Scope Management

3. Project Integration Management 3.1. Project Initiation & Developing a Project Charter (Activity 3) 3.2. Developing the Project Management Plan 3.3. Directing and Managing the Project Execution Phase 3.4. Monitoring and Controlling Project Work 3.5. Integrated Change Control 3.6. Close Project Phase

4. Project Scope Management 4.1. Defining Project Scope 4.2. Collecting requirements 4.3. Create the Work Breakdown Structure (WBS) 4.4. Comprehensive Project Scope Statement (Activity 6) 4.5. Verifying Project Scope (Activity 7) 4.6. Controlling Project Scope

5. References

6. Glossary 6.1. Project Sponsor 6.2. Project management office (PMO) 6.3. Project configuration Management 6.4. Note Managing the Execution Phase 6.5. Note Monitoring and Controlling Project Work 6.6. Contract 6.7. Enterprise environmental factors 6.8. A general list of items on a project charter 6.9. Baselines 6.10. Organisational process assets 6.11. Project management information systems (PMIS) 6.12. Lessons learned 6.13. Product Scope 6.14. Project Scope 6.15. Importance of product definition 6.16. Scope Creep 6.17. Gold Plating 6.18. Project Constraints 6.19. Reports of blunders with scope definition 6.20. Quality function deployment (QFD) 6.21. An organisational unit

1. Project Categorisation and Prioritisation (Activity 1)

Prior to the initiation of a project an organisation will need to decide which projects it will choose to undertake. So a consideration of project categorisation and selection will be included in this module. 

In general terms it can be said that projects can be categorised as:

Compliance Projects - which are those necessary to meet legal compliance requirements and therefore necessary to enable operation or emergency projects required to enable continuation of operation. 

Operational Projects - are those designed to reduce costs, improve efficiency or improve performance. So whilst they are needed to support current operations.

Strategic Projects - are those designed to support the organisations long term vision or evolve their current mission.

Compliance projects by their nature must be done as a first priority above all other projects - the are "Must Do" projects, whilst operational and strategic projects have a degree of discretion regarding their implementation.

For any substantial project, many organisation's will require that a business case be established for a project, to determine whether or not a project should proceed past the initial conceptual stage. Some considerations and tools that might be used to justify the pursuit of a project are contained in the subsections which follow.

Watch the following video extract from a past lecture in which the strategic nature of projects and their categorisation is discussed.

Module 2 Lecture Video - Project Categorisation & Prioritisation

 Activity 1

  saved

Q1. The portfolio of projects is typically represented by compliance, strategic, and operations projects. What impact can this classification have on project selection?

 Submit

Q2. You manage a hotel resort located on the Queensland Gold Coast hinterland. You are shifting the focus of your resort from a traditional fun-in-the- sun destination to eco-tourism. (Eco-tourism focuses on environmental awareness and education.) How would you classify the following projects in terms of compliance, strategic, and operational?

 Check

 Projects Classification

Options Convert the pool heating to solar power

Build a four-mile nature hiking trail

Renovate the horse barn

Launch a new promotional campaign with Jetstar Airlines

Convert 12 acres into a wildlife preserve

Update all the bathrooms

Change brochures to reflect eco-tourism image

Revise disaster response plan based on new requirements

Compliance

Operational

Strategic

Explanatory Note

1.1. Strategic Alignment

As may have been evident to you from watching the video extract in the prior section - aligning projects with the strategic goals of an organisation is a crucial first step in deciding whether or not to proceed with a project. As an organisation grows and becomes more complex, this is often not a simple matter and success lies in creating a process that is open and transparent for all stakeholders to review. The figure below shows a schematic of the strategic management process and the link that should exit to all projects undertaken by an organisation.

FIGURE 1.1 The Strategic Management Process

SOURCE: Larson and Grey, 2021, p 31

The steps to ensuring that a project complies with these requirements are simple.

1. Begin with reviewing the organisational mission an identifying very clearly the purpose of your organisation ie What are we now? or what is it we need to do well now?

2. Then identify the strategic objectives that your organisation has identified in order to achieve their strategy.  3. Any project selected should at the very least support the strategic objectives of the organisation.

Having passed this first hurdle a project must then satisfy any financial criteria that the organisation has set as an imperative. As resources are almost always limited, the project will need to compete with other project for resources  and its potential costs and returns may then need to be compared to other potential projects in order to identify which of those projects most benefits the organisation.

 Question How are projects linked to strategic plans and why is it important to link a project to the organisation's strategic plan?

  saved

 Submit

1.2. Financial Models for Prioritisation (Activity 2)

The criteria for project selection between organisations will vary but it is very likely that the criteria will contain both financial and non-financial criteria. Alignment with an organisations strategy, as discussed in the prior section - is an example of non-financial criteria for project selection. However, after this has been established many organisations prefer the objective application of financial criteria where there is a high level of confidence associated with estimate of future cash flows. The most common financial models used are:

Payback Period - which refers to the amount of time it takes to recover the cost of an investment and is calculated using the cost of the investment divided by the annual cash flow.

Return on Investment (ROI) - tries to directly measure the amount of return on a particular investment, relative to the investment's cost and is calculated using the formula below.

Net Present Value (NPV) - which is the difference between the present value of cash inflows and the present value of cash outflows over a period of time and is calculated using the formula below.

where:

These are often combined with non-financial criteria to create Multi-Criteria Models for project selection.

Watch the following video extract from a past lecture that discusses the financial models for project selection mentioned above and their limitations.

Module 2 Lecture Video - Financial Models for Prioritisation

ROI = Current Value of Investment − Cost of Investment Cost of Investment

NPV = ∑ n

t=1 Rt

(1+i) t

= Net cash inflow - outflows during a single period tRt

 i = Discount rate or return that could be earned in alternative investments and

 t = Number of time periods

 Activity 2

  saved

Question 1. Two new software projects are proposed to a young, start-up company. The Alpha project will cost $150,000 to develop and is expected to have an annual net cash flow of $40,000. The Beta project will cost $200,000 to develop and is expected to have an annual net cash flow of $50,000. The company is very concerned about their cash flow. Using the payback period, which project is better from a cash flow standpoint? Why?

 Submit

  saved

  Question 2. A local manufacturer of industrial electronics needs to increase production capacity. They had been selling 480 units per year, at a price of $3,200 each, for a total revenue of $1.536 million. They are considering implementing a project to reduced process cycle time (ie the time to make 1 unit) by 10 percent, the company can increase output by the same amount. The Project they are considering will cost them $145,000  and the organisation only accepts projects that deliver a return of >10% because they have other potential investments that return at least this value. Using an ROI calculation determine if they should proceed with the project implementation? - explain your reasoning.

 Submit

  Saved

  Question 3. A five-year project has a projected net cash flow of $15,000, $25,000, $30,000, $20,000, and $15,000 in the next five years. It will cost $50,000 to implement the project. If the required rate of return is 20 percent, conduct a discounted cash flow calculation to determine the NPV.   Once attempted, click the 'Show Solution' button below to see the worked example.

 Submit

Show Solution

1.3. Multi Criteria Models for Prioritisation

As you may have already determined from watching the prior modules, financial criteria alone do no always reflect the strategic imperatives of an organisation. Organisations may need to be prepared to discard potentially profitable projects that are outside the realm of their core mission or which may impact negatively on their future vision eg the development of core competences. This means that organisations have to include other criteria in their selection process that mirror critical success factors for the organisation but may not relate to profit margins and at times might be considered to be somewhat intangible.

In addition to identifying the criteria that is to be considered it is potentially useful to differentiate amongst criteria with respect to their relative importance - which is where multi weighted scoring models become quite useful.

Watch the following video extract from past lectures which discusses both non financial criteria and multi criteria weighted scoring models

Module 2 Lecture Video - Multi Criteria Models for Categorisation

 Questions

  Saved

Question 1. Why should an organization not rely only on ROI to select projects?

 Submit

  Saved

  Question 2. Consider what the pros and cons of the checklist versus the weighted factor methods of selecting projects might be and list them.

 Submit

2. Introduction to Project Integration and Scope Management

Once a project has made it on to the organisations to do list using the analysis tools used in prior section, then comes the point in time when you must plan and execute the project. When you undertake a project which is expected to deliver a solution to a particular problem, you will need to get your head around what the project is about (what is the project scope?) and what exactly needs to be done to deliver the expected solutions. These two aspects, defining and scoping a project and the project management processes required to deliver the solution, are what we will be covering in this module.

Defining a project would include identifying and organising information on how to initiate the project and then setting the required project management infrastructure for the smooth execution of the project. The processes involved in defining a project are outlined under ‘Project Integration Management’ in the PMBOK® Guide. However, project integration management also includes other aspects such as developing a project charter, developing an initial project plan and putting in place measures for project control. In essence, project integration management deals with maintaining the cohesiveness of the overall approach to managing a project. As such, integration management interacts with and unifies all nine areas of project management knowledge referred to in Module 1. By comparison, managing project scope begins with establishing what needs to be done, and only what needs to be done, to successfully deliver the project outcomes agreed, and expected, by the key stakeholders of a project.

3. Project Integration Management

According to PMBOK, Project Integration Management includes identifying, defining and coordinating the various processes and project management activities within the Project Management Process Groups. It is one of the project management knowledge areas, that is specific to project managers and where the accountability cannot be transferred to other experts e.g., cost analysis to accountants, scheduling to specialist schedule coordinators or schedulers and risk to risk management experts. The project manager is ultimately responsible for the project as a whole and therefore they must combine the results of all the other Knowledge Areas and have a holistic view of the project.

The table below is an extract from the PMBOK® Guide in which the processes related to project integration management are identified.

Figure 3.1: Integration and scope management processes vs. project management knowledge areas

(Source: PMBOK® Guide, 6h Ed; p. 25)

These processes are briefly described below.

4.1 Develop Project Charter – Compile a document that authorises the project or a project phase

4.2 Develop Project Management Plan – Develop the initial high-level framework for integrating and incorporating all subsidiary project plans

4.3 Direct and Manage Project Work – Provide the overall direction and guidance for performing the project work to ensure that the planned project outcomes are delivered

4.4 Manage Project Knowledge - Which relates to the process of using existing knowledge and creating new knowledge to achieve the project’s objectives and contribute to organisational learning

4.5 Monitor and Control Project Work – Endeavour to maintain the project performance targets, by way of monitoring progress while dealing with variations.

4.6 Perform Integrated Change Control – Track and review all changes requested and incorporated into the project and evaluate their effect on the desired project outcomes

4.7 Close Project or Phase – Ensure the orderly completion of all project activities

In Module 1, we introduced the project management process groups (Figure 1.1) as parts of the project lifecycle. As you can see from the above, a more complete list is provided by the PMBOK® Guide and also includes monitoring & controlling which is generally not captured in the project lifecycle. We also had a brief look at the nine project management knowledge areas. The above table illustrates how a knowledge area (project integration management) relates to the PMBOK process groups.

3.1. Project Initiation & Developing a Project Charter (Activity 3)

Figure 3.2:  Overview of the process of developing the project charter

In most cases, a project needs some form of authorisation to go ahead, and the document that formally authorises a project is the project charter.  If the project is large and is multi-phased, each phase may have its own charter. Usually, it is the project sponsor who develops the project charter, or else the project manager may be assigned the responsibility of developing it. Apart from the project manager, key stakeholders, consultants, subject experts and the project management office (PMO) may also get involved and use their expert judgement in compiling the project charter. These key stakeholders may also include members of a steering committee who will ultimately provide guidance and direction to the project sponsor and project manager. Those people involved are considered experts that may have previously involved in similar type of work in similar or varying project environments and their tacit knowledge can be quite useful. Project managers can also draw information from a variety of internal and external sources, for example, the statement of work (SOW), business proposal or business case and contract documents, as well as consider other environmental factors that may influence the project. Moreover, the project charter may refer to the organisation’s current processes, policies and procedures, as a project is an integral part of the organisational undertakings and is expected to utilise and follow the organisational process assets policies and protocols.

Watch the following Video extract from a past lecture that discusses project initiation and the project charter and which will also give you an insight into developing a project plan which is the topic of the next section of this module.

Module 2 Lecture Video - Project Initiation

Exception - sessionwaiterr

NOTE: Please note that this video refers to a Close Out Report which is featured in Assessment 2. For 2021 this is in fact Assessment 5 which contains a Close Out Report. The reference in the video is an old reference to a prior assessment numbering system.

Activity 3

  Saved

Make a list of information that you think should be available in a project charter.

 Submit

3.2. Developing the Project Management Plan

Figure 3.3: Overview of the process of developing the Project Management Plan

The best term to describe the project management plan is to say that it is the mother of all plans in a project. Although the PMBOK® Guide has introduced the project management plan separately under project integration management; each knowledge area contributes to the project management plan. Therefore, the project management plan will be made up of multiple sub plans (see Figure 3.5) which are specific to each knowledge area. The development of the project management plan will rely on the inputs illustrated in Figure 3.3 above which include; the project charter, organisational process assets and information pertaining to the organisation where the project is being conducted, i.e. enterprise environmental factors.

The project management plan, at the initial stages of a project, will contain information pertaining to technical and management information that would help reach project goals; the resources needed to complete the project; and the level of project configuration management (PCM) required to be implemented and documents that would be subject to change management. Depending on the size and complexity of the project, experts with proficient knowledge may be engaged in making decisions with regard to these aspects.

At this stage, as we are just embarking on our journey of project management, the project management plan is discussed as a pre-requisite for scope management.  Therefore, recognising that it’s the initial planning that goes into a project, we could expect only the core components (Figure 3.4) of the project management plan to be considered. These would include: project milestones; performance measurement baselines that include a high level time; scope and quality baselines; identified risks; and resource availability. The performance measurement baselines would generally include time, scope, cost and quality parameters.

Why use configuration management (CM)?

To keep track of changes.  CM is highly recommended for evaluating, tracking, approving and communicating change. Therefore, CM is very effective in channeling information for project investigations.  Example: if a project has steered off the planned track,  CM is useful in determining a point of rollback, where there is evidence that the project was on track.

The configuration management plan that is included in the project management plan and specifies the procedures involved in evaluating, tracking and reporting change.

Figure 3.4: Core components of the project management plan (Source: Sherrer, 2009; p. 72)

However, once the project progresses and additional planning is completed, the following plans will need to be incorporated into the project management plan.

Figure 3.5:  Sub plans in the project document (Source: Sherrer, 2009, p. 73)

3.3. Directing and Managing the Project Execution Phase

The process of directing and managing the project execution is concerned with ensuring that the project outcomes are delivered to meet the expectations of the key stakeholders.

Figure 3.6: The overview of the process of directing and managing project execution

For example, if we consider the construction of a bridge, then the activities that need to be completed to deliver the final product, i.e. the bridge, is the core of the execution process.  However, it does not merely deal with the final project deliverable, but all other intermediate deliverables that need to be successfully completed in order to meet the final project objective. As such, if, for some reason, the project cannot go on as planned, then the project manager should take necessary actions to mitigate the adverse impact of any disturbances on the project, so that the project objectives are met.

These actions may include: consulting with stakeholders to identify a suitable solution to a potentially problematic situation; evaluating project performance and make necessary changes to ensure the project gets back on track; and directing or alerting the project team to address potential issues or rectify any problems. Overall, it is the project manager’s responsibility to identify alternative paths towards project completion, when the current path is obstructed, due to one or more reasons.

 Question

Exception - sessionwaiterr

As part of directing and managing the project execution phase, the project management plan, accepted change requests, organisational process assets and enterprise environmental factors can be used by consultants, experts, technical gurus and the management to make judgements. This process can be facilitated by software tools which support decision making. These tools may be automated and are commonly identified as project management information systems (PMIS). An organisation may have an industry-standard PMIS or a custom made system built to suit specific requirements. These tools may help the experts to evaluate the progress of the project and make adjustments if needed to keep the project on track.

Any adjustments made during this process should be followed by corresponding updates to the project management plan, project documents, work performance measurements and deliverables.

3.4. Monitoring and Controlling Project Work

In this process, the project outputs and the project management tasks are critically evaluated to identify variances, if any, and their causes. Each organisation and each project can be distinctly different, and therefore, an acceptable range for variance may be defined by the senior management in the organisation on a project-by-project basis. Any variations outside this range would have to be investigated, the root cause established and a plan to manage or eliminate the unnacceptable variance put in place.

Consider this example; a project manager calculates a lapsed time of 540 days for the successful completion of a project. However, the project is completed in 320 days. This is a variance of over 40% to the original baseline schedule. Therefore, although the variance is positive, the PMO may need to investigate why there was such a vast difference. This investigation could reveal useful insights into the relevant aspects of project management, for example, were there any issues with the estimation techniques used and did this lead to an overestimation of the required time. This knowledge would be documented as lessons learned for future reference.

Also, consider this example, the project manager learns that a project has fallen behind schedule by 15%. Based on past experience and by reading the lessons learned documentation, they feel that they can recover from a 15% variance to the schedule, by adhering to the accepted protocols of project schedule control used previously in documented projects. However, they will need to keep a close eye on this problem ie monitor the problem, because if they fail to catch up or if the schedule variance exceeds 15%, they will have to take extraordinary steps to resolve the issue which may include appealing to the project sponsor for additional resources or reduce the duration of the project. The aspects that one might consider in controlling variations to the project plan will be covered in later modules and the case given below is a typical example that highlights the importance of post project analysis or a project ‘post mortem’ to create a lessons learned document. The lessons learnt from this failed project would be of much use for future projects in this particular organisation.

Figure 3.7: Overview of the process of monitoring and controlling project work

Let’s look at another example, say, that a project to build a large dam on a river has been launched, the project manager, or in this particular case (since the project is rather large) the project management team, keeps a constant vigil on the project progress. The inputs for this process may arrive in the following forms; the project management plan, performance reports, organisational process assets and enterprise environmental factors. This information will be subject to analysis by experts and judgements on the progress of the project will be made accordingly. If there should be corrective action on the construction of the dam then requests for change will be initiated, actions taken, documented and the project management plan and project documentation will be updated.

 Activity 4

Exception - sessionwaiterr

3.5. Integrated Change Control

Change is not necessarily a bad thing and at times inevitable. There may be many reasons to incorporate change, such as, changes to business rules, identification of new risks, and correction of errors or to incorporate omissions.  The important thing about change is that it should be identified, documented, analysed, response(s) defined, communicated and implemented. Like the PMIS or as a part of PMIS, in some cases, automated change control systems that assist this process (CCS) could be found.

Figure 3.8: Overview of the process of integrated change control

In the process of integrated change control, information from the project management plan, change requests and work performance information will be considered. The individual, or preferably a panel, evaluating the changes should make sure that if these changes were to be incorporated, they should adhere to the organisational standards and procedures, as well as the enterprise environmental factors.  

Once a change request is initiated the experts would then evaluate the change request and decide the best possible approach to dealing with it. This could be either to incorporate the change, disregard it, or hold it till more information is received. Once the decision is made the following documents will be updated. First the project management plan, this plan will constitute two sub plans that assist in change management; these two plans are the configuration management plan and the change management plan. The change request itself and other project documentation will also need to be updated reflecting the actions taken.

3.6. Close Project Phase

The end of a project or a project phase signifies an important milestone not just for the project but also for the incumbent organisation. At this milestone, the project or project phase success or failure may be measured.  Regardless of whether a project can be considered a success or a failure, there is a considerable amount of information that may be generated and is useful for the future.  In a case where the milestone represents the end of a project phase, the information gathered will be useful in making decisions such as whether to continue or discontinue the project. 

Whether the project or project phase has successfully achieved its objective or not, it is important that the project manager brings the phase or the project to an orderly completion. This may involve checking a result, service or product for stakeholder conformity, deciding the project’s future and possibly transferring the project’s product to the customer. Also conducted in this process are documenting the lessons learned and ensuring that updates are made to the project documents.

However, before we conclude this section, it is worthwhile reiterating that what has been discussed thus far in this module - Project Integration Management - does not constitute a knowledge area that can be exclusively applied to one particular aspect of a project. The content reflects all four functions of management – planning, organising, leading and controlling – and the concepts and techniques apply to the whole project over the span of its entire duration.

Consequently, if you find it difficult to follow the prior content of this module, it might be helpfull if you understood some of the other areas involved in developing the project plan in more detail ie Time, Cost and Resource Management. Therefore it may be useful for you to move on to the next section and revisit project integration management once you have completed Module 5.  

4. Project Scope Management

The purpose of project scope management is to ensure that a project delivers the intended product or outcomes as per the agreed upon expectations while adhering to the agreed time, cost and quality parameters. This is achieved through: identifying and detailing all key stakeholder requirements; establishing a scope baseline; and then by controlling the scope against undesired discrepancies.

The PMBOK® Guide shown in the figure below, outlines the processes relevant to the project scope management.

FIGURE 4.1 Relationship between Project Scope Management Knowledge Area and PMBOK processes.

SOURCE: PMBOK® Guide, 6th Ed., 2017, pp.25

A brief definition of each follows.

5.1 Plan Scope Management - The process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled

5.2 Collecting Requirements – Gather stakeholder expectations on the project and product deliverables

5.3 Define Scope – Describe in detail the project and product expectations

5.4 Create WBS – Draw a hierarchical pictorial illustration of work that needs to be completed to deliver on project and product expectations

5.5 Validate Scope – Obtain formal acceptance on the work to be completed, by all key stakeholders

5.6 Control scope – Endeavour to maintain the agreed project and product scope by way of consistent monitoring of work performance against the scope baseline.

It is evident from the matrix that the Project Scope Management knowledge area occurs during the PMBOK processes of Planning and Monitoring and Controlling. We will go through these areas in some detail; there are some useful concepts you might want to familiarise with prior to embarking on scope management. First, it is important to understand the term ‘scope’, as it is used in both project and product contexts and, therefore, can sometimes be confusing. Product scope refers to the aspects of deliverables or outcomes of the project whereas the project scope applies to the actual work that needs to be completed in order to successfully deliver the project outcomes. The expected project deliverable could indeed be a tangible product or it could be an intangible service or a particular solution to solve a problem. Whatever the product is, the successful delivery is much dependent on understanding and accurately capturing stakeholder requirements.

Inadequate or incomplete definition of project scope may lead to scope creep, gold plating and compromising on project constraints and even project blunders. The project managers for Australia's Olympic Park project (2012), had taken on board the notion of ‘freezing’ the project scope four months before the Olympic games began in 2012; this, they say, was a deliberate measure adopted to manage the scope. However, the project itself ran for around six years; therefore, this example would give an idea of how much and how long the scope definition would have been haggled with. There are a few other approaches, apart from scope freezing, that are useful for managing scope; they would be further discussed in the scope control process. Let’s start with the process of defining scope.

4.1. Defining Project Scope

The process of scope definition utilises the collected requirements to compile the project scope statement. The project scope statement describes in detail, all deliverables expected of the project and the work that needs to be completed in order to accomplish these deliverables.

In the scope definition process, two documents which were discussed before, the project charter and requirement documents are referred to, along with organisational process assets. Organisational process assets are standards, procedures and guidelines that are implemented in the organisation. As mentioned previously, in most cases, projects need to follow organisational processes closely as they are considered an organisational unit of the main organisation.

Figure 4.2: Overview of the process of scope definition

During the translation of requirements into a scope statement, a project manager may employ the services of an expert. An expert, in this sense, would be an experienced staff member who has had considerable amount of exposure to similar projects. If a project is critical and in-house expertise is not available, it might still be worthwhile hiring an external expert to work on the project. Other techniques that may be utilised in scope definition include product analysis, alternative analysis and workshops.

Product analysis refers to the process of analysing the requirements stated in relation to the deliverables before the actual production, the benefits of this process range from finding better ways of approaching the product development to actually recognising what products should be developed. An example: In most information systems projects, the customers are unaware as to what the end product is and what it can do. In such situations, business analysts and product analysts are called upon and a software solution is configured by the project team.  

Alternative analysis and workshopping, for defining scope, are employed with intentions of identifying different or alternative ways of conducting the work on the project. Key personal in a project may sit down and brain storm, focus group or merely discuss better ways to conduct the work at hand.

The process of scope definition is deemed successful when a comprehensive scope statement is prepared - an example of which is shown in the figure below. A synthesis of what is contained in this document is often referred to as a high level Project Scope Statement or a Statement of Project Objectives as is seen in the Snapshot From Practice illustrated below. To be considered complete, this statement should contain sufficient information such that an individual with experience in the field can accurately interpret the key constraints and output of a project. At its most basic level, it should at least express an ACTION, a TIME BOUNDARY and a COST (which in some projects may not be relevant eg writing a term paper). A final and very important consideration is that the final comprehensive scope must ultimately be verified and agreed upon by all relevant stakeholders and therefore by implication each element which contributes to this definition must be verified and agreed. The process of verification will be further discussed in later sections.

 Figure 4.3: Illustration of a Scope Statement (Source: Based on Larson & Gray, 2021; p. 109)

In the example provided above, the ACTION is - "To construct a high-quality, custom home". Do not underestimate the importance of the location ie Lot 42A in Greendale. This information is crucial to provide a clear picture of the project requirements to someone with knowledge about construction in this location eg whether it was flat vs very hilly or steeply sloping land. The TIME BOUNDARY is within five months and the COST which is relevant in this case is$350,000.

Watch the following video extract from a past lecture that discusses the concepts of a High Level Project Scope Statements and Detailed Project Scope Statements and provides a number of examples.

Module 2 Lecture Video- Project Scope Management

Exception - sessionwaiterr

The above activity focuses on only one of the elements contained within a Comprehensive Project Scope Statement ie the Project Objective Statement, which may also be referred to as a high-level statement of scope.  In order to produce a complete detailed or Comprehensive Project Scope Statement, a project manager must begin with collecting the stakeholder requirements which is discussed in the next section. 

 Activity 5

Exception - sessionwaiterr

4.2. Collecting requirements

A prerequisite for defining scope is to determine the requirements of key stakeholders. During the requirements identification stage, key stakeholder are consulted, requirements are elicited, communicated and documented. In order to define the scope, requirements may have to be gathered from a range of stakeholders and across many organisational positions across single or multiple organisations. The project manager or the business analyst involved in the process may refer to the project charter to get an overview of the project and refer the stakeholder register to recognise key stakeholders that need to be consulted. Collecting customer requirements is considered a specialist skill, and most projects employ business analysts to elicit, collect and translate business requirements into technical terms that would be understood by the rest of the project team. Quality Function Deployment is another approach commonly used in new product development projects to elicit and translate customer requirements into product specifications. 

Figure 4.4: Overview of the process of collecting requirements

Popular tools and techniques employed during requirements gathering include; interviews, questionnaires, observation, group requirements gathering methods and building prototypes. Requirements may also be elicited by reading organisational documents. Take the example of a project which has undertaken to design and build a ramp on a bridge. In order to successfully undertake this project, it would be necessary to look at the documents from earlier projects, such as the blueprints of the bridge, local traffic volumes, community needs and so on.

The identified requirements need to be collated and documented for future reference. The requirements management plan, requirements documentation and requirements traceability matrix are some of the documents that may be compiled during this process.

4.3. Create the Work Breakdown Structure (WBS)

Once the scope statement has been developed, the work to achieve the project outcomes, needs to be organised into manageable chunks. This is where the concept of a Work Breakdown Structure (WBS)  become important. In this process, the scope that was defined in the earlier process is decomposed into components that are identifiable based on some physical or technical dimension. As shown in the diagram below, the information needed to conduct the decomposition is available in the following the scope statement, requirements documents and organisational processes, guidelines and standards.

Figure 4.5: Overview of the process creating the WBS

The WBS is a hierarchical illustration of the decomposed work, depicting the highest and the lowest level of work defined.  It can take many forms but some rules of thumb apply. Decomposition may take the scope through a few levels of sub divisions until the smallest level at which the work item can sit on its own is reached - this is often the work package level which is where a project manager can assign the work to an individual or group. The method of decomposition depends largely on the discretion of the project manager and there is no one universal method applicable to all circumstances. Some project managers resort to the project phases and decompose the project work accordingly, while others may choose to use project deliverables or sub- projects within the project as the basis of decomposition. However, a consistent rule, that needs to be noted in decomposing work and creating a WBS is that a work package could have only one parent in its hierarchy.

The following figure illustrates the technique of decomposition to the work package level using deliverables as a means of segregation.

Figure 4.6: An example of decomposition using deliverables as the means of segregation

(Source: Larson & Gray, 2011; p. 108)

An alternative approach to decomposition of a WBS - using project phases and deliverables is given in the PMBOK ® Guide and reproduced in the figure below.

Figure 4.7: Illustration of a WBS (Source: PMBOK® Guide, 2008; p. 119)

Regardless of the method used, a critical component of the WBS is its coding. As you can see from the illustration above each element contained within the WBS has its own unique code which is critical for later reference and interfacing into other project and organisational systems.

The information captured in the WBS is not limited to a description of the activities. Project managers’ may opt to incorporate ‘control accounts’ into the WBS as they depict the  “management levels in the WBS where scope, cost and resource information can be summarised and used later for earned value performance measurements”  (Sherrer 2009,p. 114). Earned value performance measurements and the use of control accounts will be discussed in module 3. The WBS dictionary on the other hand has all the information with regard to the WBS: the account code or identifier, resources required, quality requirements, acceptance criteria, milestone information, technical information and contractual information are some of the information that may be available. Scope baseline that is also an output of this process is a collection of documents that include the WBS, WBS dictionary and the scope statement.

Once the scope is decomposed, the following outputs are expected: the WBS, WBS dictionary, scope baseline and necessary updates to the relevant project documents.  

Watch the following video extract from a past lecture in which WBS are discussed.

Module 2 Lecture Video - Project Scope Management - the WBS

Exception - sessionwaiterr

4.4. Comprehensive Project Scope Statement (Activity 6)

By this point in time you will have all the information that you need to create a complete "Comprehensive Project Scope Statement". Now all that is left is to verify that all the key stakeholders agree that this statement accurately reflects the project's requirements and expectations. The process of verification will be discussed in the next section of this module. However, before proceeding to the verification step try and complete the following activity which will help reinforce for you the key elements to include in a comprehensive Project Scope Statement and how to appropriately express each of the elements. 

 Activity 6

Your roommate is about to submit a scope statement for an orientation week concert sponsored by the entertainment council at the University of Wollongong (UOW). UOW is a university with over 30,000 students some of who live on campus, but the majority live off campus. This will be the first time in six years since UOW has sponsored an orientation week concert. The entertainment council has budgeted $40,000 for the project. The event is to occur on the Friday of Autumn orientation week and it must be held somewhere close to the Unibar so that revelers can enjoy the services offered at the Unibar. Since your roommate knows you are taking a class on project management and she had already asked you to help her write a project objective statement (ACTIVITY 5), she asks that you now review her scope statement and make suggestions for improvement. 

The comprehensive project scope statement which she has completed is reproduced below in a word document. Given your newfound project management knowledge - review her work and provide her with some feedback ie read the document and suggest appropriate amendments that would improve it (via commments on the word document)).

 UOW O-Week Concert Project Scope

After you have provided improvement on the document, click the Solution button below to download the same Project scope document with possible amendments (via comments) that your teacher has suggested . 

Show Solution

4.5. Verifying Project Scope (Activity 7)

By this point in time you will have all the information that you need to create a complete "Comprehensive Project Scope Statement

Figure 4.8: Overview of the process of scope verification

The scope verification is aimed at ensuring all key stakeholders agree and are comfortable with the identified scope. A project manager may refer to the previously developed project management plan, requirements documentation and requirements traceability matrix to find and present the details of the defined scope to stakeholders. An inspection can then be planned and conducted to verify the identified scope.

During the inspection, the scope that has been defined should be examined to determine that the product and project scope have both been adequately captured; i.e. the project scope is defined well enough to facilitate the product and project deliverables.

There are various ways to conduct an inspection and verify the scope. Product and process analysis and walkthroughs are the most common approaches. Apart from these, an organisation may resort to methods that are specific to the incumbent organisation; these could vary from interviews, group decisions to testing and analysing a prototype. Some organisations may organise a formal presentation or a workshop where all stakeholders are invited to provide their feedback. The stakeholders may be able to freely comment on their requirements and evidence the extent to which their requirements have been captured. Stakeholders could also point out any shortcomings in the identified scope, during such presentations. 

If for some reason it is discovered that there is a discrepancy between the expected scope and the defined scope, it is recommended that a formal change request be issued. Once the changes are accepted and the monetary, functional and aesthetic implications have been discussed, the changes may be incorporated. The process of inspection, may be iterative until an agreement is reached by all stakeholders, and once completed, change requests and other project documents will be filed.

Figure 4.9: An example of a change request (Source: Larson & Gray, 2011; p. 232)

Once this process has been completed it is expected that updates are made to the project documents that include: the stakeholder register; requirements documentation; and the requirements traceability matrix. 

 Activity 7

Conduct this exercise using the Scope Document you previously developed for the UOW music festival during Autumn orientation week (ACTIVITY 6). Consider working with a peer to complete this exercise. Let your peer evaluate your original Scope Document while you evaluate theirs. When it’s your turn to evaluate, play the role of the sponsor of the event and discuss and verify that the scope of the UOW music festival has been adequately captured. If your peer has missed out on any essentials, point that out and negotiate a way of incorporating that into their scope. Then put on your project managers hat and consider the change request you would need to complete in order to incorporate any missing elements that you agree are important enough to accept and warrant a change to the project documentation.

This activity has been written with the intention of collaborating with a peer.

4.6. Controlling Project Scope

Once the scope is verified and agreed upon, the focus of the project manager will shift towards controlling the scope. A change, especially a growth in scope, as it may incur additional work, may have ripple effects on cost, time and quality, and therefore, should be carefully handled.

Figure 4.10: Overview of the process of scope control

The information with regard to the agreed-upon scope will be available in the following documents:  project management plan, requirements document, requirements traceability matrix, and organisational procedures, standards and guidelines. Supplementary to these documents, a project manager may refer to the performance information, provided that the project work has already commenced. Performance information will provide details on what work has completed on the deliverables and the current status of these tasks.

Variance analysis is the technique used to identify discrepancies in project scope. Variance analysis will take into account the scope baseline from the project management plan and the performance information of the work conducted, and compare the two. If any variance is found, the cause and the degree of variance needs to be determined and the project manager will need to make an informed decision as to what corrective actions will be implemented, if any.

If any changes are found and are identified as necessary to ensure the project success, then change management processes will be brought to effect and the change to the scope will be incorporated and documented. The scope control process may see the need to update the following documents: project management plan, organisational process assets, change requests, project documents and work performance measurements.

5. References

Larson, E.W. and Gray, C.F. (2011), Project Management: The Project Management Process, 5 edition, McGraw Hill

Maylor, H. (2010), Project Management, 4 edition, Prentice Hall

Mulcahy, R. (2011), PMP Exam Prep, 7 edition, RMC Publications, Inc,

Olympic Park Project, Larson & Gray (2011,p. 110)

Project Management Institute (2008), A Guide to the Project Management Body of Knowledge

Sherrer J.A.(2009), Project Management Road Trip for the Project Management Professional

Thorn, Brian & Carrano, Andres & Wood, C. & Plaz, C. & Giunta, M. & Villanueva, A. & Gasparin, H.. (2006). Design, development, and deployment of low impact solar ovens for impoverished populations. 2006 IIE Annual Conference and Exhibition. 

th

th

th

6. Glossary

Module 2: Supplementary Information

6.1. Project Sponsor

A Project steering committees are organised to encourage executives to provide guidance to project teams and participate in the resolution of issues amongst other responsibilities. The project sponsor is the owner of the project or the entity that funds the project, and could be an institution or an individual. The project sponsor has a higher level authority on the project and is responsible or has a large say in appointing a project manager, approving or disproving further project finances and resources to make sure that the project performs as desired.  

FIGURE 6.1: A depiction of the role of the project steering Committee and project sponsor

(SOURCE: PROJECTSMART.co.uk)

Just as projects differ in size and complexity so too does their reporting structure differ. Whilst the above diagram illustrates a situation in which the PM reports to the Project Sponsor, who is in turn directed by the Steering Committee, there are times when a PM may report directly to a steering committee, or there may be situations where the project sponsor replaces the steering committee. In fact, the steering committee may not be made up of C suite executives at all, but instead it may be made up of functional area managers. Ultimately the structure under which the project will operate will be dictated by the organisation. But what is consistent in their depiction, is that just as an umbrella protects individuals from the weather, a steering committee and a project sponsor are expected to shield a project from external and unforeseen forces that may threaten to hinder the project progress and provide guidance and direction to the project manager. 

6.2. Project management office (PMO)

PMO can play varying roles in relation to their involvement in projects, depending on the purpose they are meant to serve, as mandated by the incumbent organisation. On the one end of the spectrum, PMO can assume the role of the governing body of projects in an organisation. In such cases they oversee the project management aspect of projects, and be responsible for developing and implementing the protocols to be followed in managing projects, i.e. particular processes, frameworks, guidelines, standards, templates, training, databases, reporting and communication mechanisms and so on. On the other end of the spectrum PMO’s may only play a rather remote and passive role, for example, collecting information on the progress of projects, facilitating communication between various internal and external parties, and providing administrative support as needed.    

Not all organisations have PMOs, but some do. PMOs are very popular with organisations that execute their business strategy by means of projects. In such organisations, multiple projects take place at any given time, therefore, meticulous management of all these projects are of high importance to the success of an organisation. Larson and Gray (2011, p. 78), introduces the project office in the following manner.

Case snippet 6.1: The project office (Source:Larson & Gray, 2011; p. 78)

A PMO may also be responsible for making certain decisions with regard to ongoing projects in an organisation. The PMO, with input from project staff, and based on information gathered from other sources, can make decisions in relation to prioritising resource allocation for projects considering their importance to organisation’s business strategy. 

Figure 6.2: An illustration of the information and action flow, to and from the PMO (Source: Maylor 2010; p. 63)

Given below is a diagram from Maylor (2010, p.61) that illustrates the alternative ways of handling multiple projects; the figure depicts that some projects are conducted concurrently while others are conducted sequentially. If an organisation adopts such approaches, then it’s advisable to have a PMO overseeing the management of these projects.

Figure 6.3: An illustration of the conduct of multiple projects or a programme (Source: Maylor, 2010; p. 61)

6.3. Project configuration Management

Project configuration management (PCM) is the collective body of processes, activities, tools and methods project practitioners can use to manage items during the project life cycle. PCM addresses the composition of a project, the documentation defining it, and other data supporting it.

6.4. Note Managing the Execution Phase

As you cover the contents of future modules you will learn about options that you may need to consider in order to address unforeseen events. So in this case you simply need to apply common sense and consider what you would do in this situation.

- Might you delay the project until the resources are available? Yes, you might do this but then how would you deal with the tight deadline?

- Might you obtain the resources from another source eg hire them from outside the organisation? Yes, this might be an option but then you would need to consider the implications of this for the organisation, including impacts on cost and project complexity and determine whether it is worthwhile proceeding.  If you do proceed, you would need to identify, engage and manage the external sources for the required resources.

- Might you approach the client and negotiate a delay? - Yes, this might be an option but what impact would this have on your organisation's reputation and ability to source future work? and is this really an option you want to take before exhausting all other possibilities?

- Does it prompt you to think that you may need a process in place to deal with this type of problem, should it occur when a project is underway? 

The key point to consider here is that there may be many potential solutions to this problem and at this stage of your learning you are not yet aware of some of the possible solutions. But what you should be starting to recognise, is that all of these choices have roll-on implications for the project and any change that is made to one aspect, has to be assessed in terms of its impact on other project considerations. It should also highight the importance of preplanning and putting in place infrastructure and processes upfront to deal with issues that arise during execution. These are the key considerations of integration management.

6.5. Note Monitoring and Controlling Project Work

As the leader of a project that is designing a new glass bottle for a popular soft drink, you have so far been satisfied with the progress of the design team. However, early trials of a prototype indicate that some customers not satisfied with certain features (aesthetic aspects) of the bottle. How will you approach this situation? 

Would you consider re-designing the bottle, conduct further trials or abandon the project?

Or would you ignore the early customer feedback because it is based on a small sample, and go ahead with the introduction of the new bottle as planned.

Some factors you might consider in making a decision? 

- What was the original specification provided to you by the client you are developing the bottle for?

- Have the designs produced for the protorype met the original project requirements set out in the documented specification and scope? - Quantify this

- Have you determined the proportion of the customer base that are not satisfied with the aesthetics?

- Armed with the data above have you discussed the project status and customer feedback with the client and collaborated on an agreed path forward?

6.6. Contract

A commercial contract is a legally binding agreement entered into between two or more parties that sets out the obligations and entitlements, usually, in relation to the provision of goods or services in exchange of money. They can be quite important, especially if the customer is an external entity. However, contracts with internal customers are not rare either. A contract should be read carefully and agreed upon by all parties involved in the project. The time, budget and scope expectations are some of the things which will be referred to, in the contract document. The contract will also lay down terms for any alternative conduct or outcomes. If any legal disputes arise out of a contractual agreement, the terms specified in this contract will draw the line of decision. Maylor (2010,p. 323) illustrates the process that leads to establishing a contractual agreement as follows (Figure 2.04A).

Figure 6.4:  Process of establishing a contract (Source: Maylor, 2010; .p 323)

This process will be discussed further in later modules dealing with project procurement management.

6.7. Enterprise environmental factors

These factors include the organisational culture, as well as policies and procedures adopted in an organisation. They may also include government rules and regulations, market conditions, automated tools adopted and codes of conduct governing stakeholder relationships and stakeholder risk tolerances. The relevance of these factors may depend on the phase of the project, i.e. not all factors are highly influential all of the time.

6.8. A general list of items on a project charter

List of Information that may appear on a Project Charter

Project title Project objective Success criteria Funding sources Major deliverables Acceptance criteria Milestone schedule Key assumptions Major risks Project constraints Project manager Reporting hierarchy Signatures for authorisation

Figure 6.5: List of items that may be available on a project charter

Should you be worried if you have less or more items in your list?

No, project documents and plans are customisable, and the incumbent organisation may use it as they want, and as suitable for the current project.

6.9. Baselines

A baseline is a target or reference framework which has been agreed upon by relevant parties and approved by an authorising body. Resources for the project are released based on the baselines. Project baselines for a project may include time, scope, cost and quality parameters. Changes to the baselines should follow approved change control protocols. Given below is an illustration that depicts the original and adjusted baselines.

Figure 6.6: Changes reflected on the baseline (Source: Larson & Gray, 2011; p. 478)

6.10. Organisational process assets

These include adapted models, procedures, guidelines, automated or manual methods adhered to by the organisation. They will also include security systems, defect management tools, process measurement systems and databases. Project files from previous projects are also considered to be in this category.

6.11. Project management information systems (PMIS)

PMIS are usually computer-based tools implemented to support the execution of the organisational strategy. They allow storing, analysing, retrieving and reporting of project information. The diagram below is a depiction of a PMIS by Larson & Gray (2011), they attempt to illustrate how an automated tool has captured organisational and project information and how the overall operation adheres to the organisational structure.

Figure 6.7: An illustration of PMIS (source: Larson & Gray, 2011; p. 460)

6.12. Lessons learned

Problems identified and determined as the cause for impacting the progress of the project and how they were dealt with are documented as lessons learned. The expectation is that if these problems were to arise on another project/phase, then the knowledge gathered from the past could be utilised to counter the problem.Lesson learned does not necessarily have to be with regard to only the negative aspects of a project, lessons learned with regard to achieving success can also be documented and be put to use in the future.  An illustration by Maylor (2010, p. 367) explains this scenario further.

Figure 6.8: Depiction of how lessons learnt on project A would be affecting project B

(Source: Maylor, 2010; p. 367)

As shown in the diagram above, the project B would benefit from the lessons that were learn from project A. An example from practice follows.

Case snippet 6.2: A brief description of how lessons learned are helpful (Source: Maylor, 2010; p. 361)

6.13. Product Scope

PMBOK® Guide defines product scope as “The features and functions that characterise a product, service or result” (2008, p. 103). Consider this example; imagine that you are describing the characteristics of an apple, let’s say, to ‘the creator’, neither you nor the ‘creator’ has eaten or even seen an apple ever before. You would probably start with something like this: apples should grow on trees; it’s round and reddish; with an appetising smell.

Think of how many variations of outcomes could be created by this description? Cherries, tomatoes, pomegranates and quite a few others would fit the above description as much as an apple would.

Figure 6.9: Possibilities for an apple, given the above description

Icons borrowed from freeware on the internet

In an attempt to get a clearer picture of the product, the ‘creator’ may ask you more questions such as:  describe the smell of the fruit, what shades of red are allowed? what tenderness is required? can you cut the fruit with a knife? how long could the fruit remain before the perishing process starts and should there be seeds inside the fruit and if so how many seeds? This is what the project manager and the project team would do in identifying the product scope; i.e. establish as precisely as possible the requirements of the customer and other relevant stakeholders in order to build a product that closely resembles stakeholder requirements.

6.14. Project Scope

The project scope is defined in the PMBOK® Guide (2008, p. 103) as, “the work that needs to be accomplished to deliver a product, service or result with the specified features or functions”.  With regard to our previous example of making of an apple, the project team which undertook to design and develop the apple will have to complete certain tasks: conceptual design and prototype development, procurement of suitable materials, perhaps, including subcontracting of some work, and the final assembly of the apple. These are known as project management deliverables and can also include: preparing design documents, budget/cost documents, quality documents, resource plans, communication plans and others which are needed for successfully completing the project.

The project scope, therefore, includes the attributes of the final product, as well as the objectives and deliverables associated with the making of the product. This concept is succinctly summed up in the following diagram.

Figure 6.22: Project and product scope (Source: Sherrer, 2009; p. 99)

6.15. Importance of product definition

It is undesirable, yet not uncommon for projects to deliver the wrong product. Apt application of scope management should help minimise such problems. The figure 2.3A below, from Maylor (2010, p. 113) illustrates light heartedly, the differences of understanding by different stakeholders. Incorrect communication, recording and understanding of requirements will lead to outcomes which are not desired by the stakeholders and the project may end up a failure.

Figure 6.11: How the project scope could easily be misinterpreted (source: Maylor, 2010; p. 113)

6.16. Scope Creep

Scope change that has not been approved using a formal change request is considered as scope creep. Scope creep may happen any time after the scope baseline has been approved. In certain cases scope creep may occur due to inadequate consideration given to a product feature or function during scope definition. Therefore, when implementing this feature/function a considerable amount of additional work may be involved, which was not included in the scope.  Scope creep could also be due to a particular attribute that a stakeholder tries to sneak in, while the project progresses. Careful vigil has to be kept on the scope at all times and any changes should be discussed, negotiated, documented and signed, adhering to the change control mechanism installed.  Note that changes to scope may have a ripple effect on other areas such as time, quality, risk and cost management.

Figure 6.12: Beware of scope creep

6.17. Gold Plating

This term refers to the tasks that incorporate functions and features which are beyond the expectations of the stakeholders or in other words, beyond the actual functional or aesthetic expectations.  For example; if the customer request is to build a functional computer with a metal exterior, it would be ‘gold plating’ to build a computer with gold exterior or studded with diamonds. However, in the business world there are reasons to ‘gold plate’. In certain cases, to win a large proposal bid and acquire work, the bidders may promise to gold plate. Whatever the reason, gold plating will expend resources and time. Organisations that willingly choose to gold plate may have their own reasons, if this is not the case then it’s time to revisit project scope control processors and get back within the boundary of the scope.

Apart from the situations discussed above, an over-ambitious customer may pressure the project manager to include certain niceties’ into the product design. In such cases, project managers need to weigh the pros and cons of accommodating the extra features requested and use their best judgement.

The requirement

Gold plating

Figure 6.13: Gold plating

Icons borrowed from freeware on the internet

6.18. Project Constraints

The most common constraints are cost, scope and time. Although meeting all constraints is important, there may be instances where certain constraints will have to be compromised in order to meet the others. It is common, when setting constraints, for the project manager to discuss and set priorities with the stakeholders. For example if time and scope are of priority to the key stakeholders then cost may need to be compromised. Likewise, if the available funds are limited, then the scope of work may need to be curtailed.

Refer this example: a new highway construction project is under way and is to be opened to the public on the 15  of October 2013, the invitees have been informed and the ceremony is due to take place on this exact day. With such a project, time constraint is immovable and is of high priority. The scope of the project will be hard to compromise, given that the product i.e. the road is to be used by the public and needs to adhere to many standards and safety measures. In this case the best option is to compromise the cost and have more resources involved in completing the project in time, within scope.

Figure 6.14: The triple constraint

Why is the triple constraint displayed as a triangle in the above figure?

PMBOK® Guide describes the triple constraints as the iron-triangle, meaning that on a triangle, if one axis is modified the others would be affected. Therefore, it is necessary to understand that a change in the scope or a main constraint would have a ripple effect on the project.

th

6.19. Reports of blunders with scope definition

Case snippet 6.3: The Sinclair C5 (Source: Maylor, 2010; p. 100) 

Case snippet 6.4: Chicago’s Millennium Park (Source: Maylor, 2010; p. 115)

6.20. Quality function deployment (QFD)

This approach is used in a wide range of market sectors and is often used in manufacturing and construction projects to gain a better understanding of the product being built. The approach involves customer communication, market research and product comparison to identify the requirements of the customer. These requirements are then evaluated and prioritised before the production process begins.

This methodology can assist the project manager to understand customers' expectations as well as requirements, predict how customers will perceive a product’s value, obtain buy-in from stakeholders by clearly expressing the customer's needs and how each function can contribute to delivering these needs, develop goals customer-centric performance goals and document requirements. The process provides structure and enables the prioritization of resources so that they are focused on areas most critical to the customer and bottom line. 

Some organisations use QFD in conjunction with a technique called the ‘house of quality’ illustrated in the figure below.  Diagramming of this technique involves listing customer requirements against the technical characteristics needed to realise these requirements, in the form of a ‘house’, hence the term, ‘house of quality’.  This technique is used to translate requirements into technical (manufacturing or construction) goals. It could also be used to evaluate and prioritise the importance of the customer requirements against the technical feasibility of achieving it. 

FIGURE 6.15: Example of a House of Quality Diagram capturing QFD data for an engineering project

SOURCE: Thorn et al, 2006, Figure 3, pp5 

The QFD process is far more detailed than can be covered in this module, but consider the following example: a luxury housing Construction Company is embarking on building a high-rise condominium in the heart of the city. The company is marketing the project as selling not just living space, but a life experience to the customers. The top managers in this project decide to go with QFD, to gather and elicit customer requirements. They start with market research, surveys and focus groups to collect customer requirement. This is followed by employing the ‘house of quality’ technique to translate customer requirements into technical goals. The design, marketing and construction departments in the company will involve in carrying out the technique and evaluate and prioritise requirements.  A display unit may then be built based on the outcome and customers are invited to view and further voice their requirements. These requirements may then be used to further improve the living experience the company is promising.

6.21. An organisational unit

At the inception of a project, the project organisation will be defined; i.e. the project structure, reporting hierarchies, flow of information and flow of communication etc. Project organisation will be influenced by the strategy and structure and culture of the organisation that is conducting the project. Therefore, a project is considered a sub-organisation (an organisational unit) of the main organisation. The following diagram by Larson & Gray (2011,p. 14) illustrates how the organisational strategic alignment works as the starting point and how organisational culture works as an all-encompassing factor for project management.

Figure 6.16: A Project as a sub-organisation (Source: Larson & Gray, 2011; p.14)