An Investigation into the

Effectiveness of Using
SAP-PS as a
Multidimensional Project
Control System
by

Brett Machen
Graduate Diploma of Project Management
Graduate Certificate of Project Management
Bachelors of Engineering Technology, Major; Mechanical Engineering
Associate Diploma of Engineering, Major; Mechanical Engineering
Certificate of Trade, Fitting, Turning and Machining

A thesis submitted for the degree of

Master of Project Management

School of Natural and Built Environments

Division of
Information Technology, Engineering and the Environment (ITEE)

November 2014
 Contents

INTRODUCTION .................................................................................................................. 1
LITERATURE REVIEW ........................................................................................................... 3
THE CURRENT LANDSCAPE OF EVM ................................................................................................... 4
GOING BEYOND EARNED VALUE ....................................................................................................... 6
CURRENT LANDSCAPE OF ERP PROJECT MANAGEMENT SYSTEMS .......................................................... 9
THE NEED FOR FURTHER RESEARCH INTO ERP INTEGRATED MULTIDIMENSIONAL PROJECT CONTROL .......... 14
METHODOLOGY AND METHODS........................................................................................ 15
RESEARCH METHODOLOGY ............................................................................................................ 15
RESEARCH METHODS .................................................................................................................... 17
Literature Review ................................................................................................................. 17
Stakeholder Identification and Needs Analysis Case Study ................................................. 18
Evaluation of SAP-PS ............................................................................................................ 23
ANALYSIS AND RESULTS .................................................................................................... 26
PROJECT STAKEHOLDER IDENTIFICATION .......................................................................................... 27
PROJECT STAKEHOLDER SUCCESS CRITERIA ....................................................................................... 28
PROJECT STAKEHOLDER SUCCESS CRITERIA PRIORITISATION ................................................................ 29
EVALUATION OF SAP-PS ............................................................................................................... 30
DISCUSSION ...................................................................................................................... 35
DEFINING STAKEHOLDER SUCCESS CRITERIA ...................................................................................... 35
EVALUATION OF SAP-PS AS A MPCS .............................................................................................. 37
Different Approaches to MPCS ............................................................................................ 37
Effectiveness of SAP-PS as a MPCS ...................................................................................... 39
Delivering Business Benefit .................................................................................................. 43
CONCLUSIONS .................................................................................................................. 45
RECOMMENDATIONS FOR FURTHER RESEARCH ................................................................. 47
REFERENCES ....................................................................................................................... 1
APPENDIX A RESEARCH INFORMATION SHEET ................................................................. 1
APPENDIX B ETHICS CONSENT FORM ............................................................................... 2
APPENDIX C PERMISSION REQUEST TO UNDERTAKE RESEARCH ....................................... 3
APPENDIX D STAKEHOLDER MEETING INVITATION EMAIL ................................................ 4
APPENDIX E STAKEHOLDER QUESTIONNAIRE FORM ........................................................ 5
APPENDIX F STAKEHOLDER REQUIREMENTS LISTING ....................................................... 1
APPENDIX G SAP-PS TEST SCRIPT ..................................................................................... 1

i
 List of Figures
Figure 1 - Vectorial representation of project control dimensions ............................................... 6
Figure 2 - Vectorial representation of project with gap vector G used to identify planned and
actual divergence .......................................................................................................................... 7
Figure 3 – Illustration of SAP-PS Integration across business ..................................................... 10
Figure 4 - Triangulation of research ............................................................................................ 17
Figure 5 - PESTLE model for stakeholder identification .............................................................. 19
Figure 6 - Stakeholder register table ........................................................................................... 20
Figure 7 - Stakeholder power-interest grid for quantifying the success factors. ........................ 22
Figure 8 - Stakeholder power ranking index aligned with functional structure.......................... 23
Figure 9 - SAP-PS Black-Box test structure .................................................................................. 24
Figure 10 – Filtered PASTLE diagram ........................................................................................... 27
Figure 11 – Case study project stakeholder functional structures.............................................. 28
Figure 12 - Stakeholder success criteria with low ranking excluded from the assessment ........ 30
Figure 13 – The functional departmentalisation organisational structure can be used to help
refine stakeholder requirements ................................................................................................ 36
Figure 14 – Multidimensional representations of project control .............................................. 37
Figure 15 – Multidimensional project control dimensions incorporating earned value ............ 39
Figure 16 – Project WBS example following project lifecycle and process flow ......................... 40
Figure 17 - WBS and GPCS relationship to project phases .......................................................... 40
Figure 18 - GPCS concept structure aligned with project stakeholder success .......................... 41
Figure 19 - GPCS calculations table ............................................................................................. 42
Figure 20 – Cost and benefit of change over project life ............................................................ 43
Figure 21 - Extending MPCS to control business benefit ............................................................ 44

ii
 List of Tables

Table 1 - Timeline of SAP ERP from its genesis up to present .................................................... 11

Table 2 - ERP System advantages and disadvantages ................................................................. 13
Table 3 - The two primary sources of qualitative information ................................................... 15
Table 4 - Test Inputs Defined ...................................................................................................... 23
Table 5 - SAP-PS Test Procedure ................................................................................................. 25
Table 6 - SAP-PS evaluation results against functional departments ......................................... 31
Table 7 - Verification test results for k = 0 (not achieved) ......................................................... 31
Table 8 - Verification test results for k = 1 (achieved) ............................................................... 32
Table 9 - Exploring Rozenes, Vitner and Spraggett (2004)’s MPCS concept ............................... 40

iii
 Glossary

ECC Enterprise Central Component

ERP Enterprise Resource Planning

EV Earned Value

GPCS Global Project Control Specifications

MPCS Multidimensional Project Control System

MS Projects Microsoft Projects©

PESTLE Political, Economical, Sociocultural, Technical, Legal

PM Plant Maintenance

PMBOK Project Management Body of Knowledge

PMI Project Management Institute

PS Project System

System -analyse und Programmentwicklung [System Analysis and

SAP
Program Development]

Sf Success Factor

WBS Work Breakdown Structure

k Verification Indicator

iv
 Summary

Purpose: The aim of this study is to investigate into the effectiveness of using the corporate
ERP system SAP-PS as a multi dimensional project control system that can be used to monitor
and control the work performed on projects, meet the needs and expectations of the project
managers and support the requirements of other key stakeholders within the organisation.
Design/methodology/approach: A qualitative case study and quantitative computer system
verification test approach was used. A triangulation method was adopted (case study
interviews, literature review and system verification test) to collect data on project
stakeholder success criteria and test the effectiveness of using the corporate ERP system SAP-
PS to monitor and control the stakeholder success criteria within a fully integrated
multidimensional project control framework. A literature review was performed to establish
the definition of multidimensional project control. A range of project stakeholders from across
a case study enterprise were interviewed to identify the most important project stakeholder
success criteria typical for the type of engineering projects being executed within a continuous
manufacturing chemical plant environment. A SAP ECC 6.0 development database
environment running a standard implementation SAP-PS was used for the verification test.
The identified project stakeholder success criteria were used for a verification test run to
determine if the system could be used as a fully integrated multidimensional project control
system that could effectively monitor and control the achievement of the project stakeholder
success criteria.
Findings: The results from this study suggest that the corporate ERP system is effective at
monitoring and controlling the project stakeholder success criteria within a fully integrated
environment. The system does however need to be setup and configured for the purpose of
MPCS. The various success criteria also need to be resolved down to tangible inputs suitable
for assessment within a computerised project control system. This study has identified that in
organisations operating a functional departmentalisation structures the intangible success
criteria originating from the more influential senior stakeholders can often be resolved into
tangible control dimensions by following the organisation functional structure and identifying
subordinate success criteria. This study has also identified that the senior position
stakeholders rank business benefit and product performance highly as key project success
criteria. SAP-PS has been demonstrated as effective at controlling many of the tangible
stakeholder success criteria during project delivery; however, the system does not appear to
support stakeholder requirements that extend beyond project handover.
Value of the research: This study indentifies that the corporate ERP systems is likely one of the
only systems truly capable of solving the age old problem of how to expand the traditional
singular dimensional approaches commonly used is project control so multiple control
dimensions are integrated with each other and other business systems to form a
Multidimensional Project Control System. Further studies are needed to investigate into the
methodology of extending MPCS beyond the project handover point to help monitor and
control project success criteria based on ensuring the project delivers the promised business
benefit until the end of product life.

v
 Declaration

I declare that:
This thesis presents work carried out by myself and does not incorporate without
acknowledgment any material previously submitted for a degree or diploma in any university;
to the best of my knowledge it does not contain any materials previously published or written
by another person except where due reference is made in the text; and all substantive
contributions by others to the work presented, including jointly authored publications, are
clearly acknowledged.

Brett Machen 19th October 2014

vi
 Acknowledgments

I wish to express my sincere gratitude to Reza Hosseini for being my research supervisor and
providing me with his guidance and support while writing this thesis.
I wish to thank the management and staff at Orica Limited for providing me their assistance
and support while performing this research.
A special thank you goes to my wife and three children for their support, understanding and
tolerance during this study.

vii
INTRODUCTION
Monitoring and controlling the work performed on a project is one of the most important
activities in project management and it can be one of the most difficult aspects of a project
manager’s job (Taylor 2008). The main goal of project control is to minimise the gap between
project planning and project delivery and ensure the project is executed and finished on
schedule, the original budget is respected, and the entire project is completed to stakeholder
satisfaction (Munier 2013, p.209). Project control has always played a very important role in
achieving projects’ success and the poor performance of the monitoring and control process
group has often contributed to one of the common reasons for projects' failure (Burke 2007,
p.278).
Project management as a discipline has experienced significant growth and development over
recent decades; however, the area of project control remains lacking in development
(Rozenes, Vitner & Spraggett 2004). Researchers Rozenes, Vitner and Spraggett (2006) suggest
that for project control to progress, the current traditional approaches and methodologies
need to be redesigned. The problem with how project control is currently performed is that
there remains a reliance on the legacy methodologies developed during the sixties with little
or no project control system integration. This issue was identified as problem number #1 by
Fleming and Koppelman (1999) in their review of the effective use of earned value. Ten years
later Budd and Budd (2010) also commented on how project control elements are often not
integrated with practitioners relying on disparate systems to manage project areas
independently. De Marco and Narbaev (2013), Kim et al. (2008) and Deng and Hung (1998) all
agree that practical applications of project control systems integration is generally lacking and
projects continue to be controlled using disparate single dimensional systems.
Rozenes, Vitner and Spraggett (2004) suggest that the answer to improving project control
methodologies lies in expanding the traditional singular dimensional approaches to project
control so multiple control dimensions are integrated with each other and other business
systems to form a Multidimensional Project Control System (MPCS). One of the main issues
facing businesses trying to move in this direction is that legacy project control systems are
difficult to align with other enterprise systems (Franz 2009). Songer, Hays and North (2004)
further suggest that organisations trying to integrate and analyse their project information are
also faced with the problem that projects can produce voluminous amounts of data that is
difficult to process and interpret. The answer to these issues and the key to project control
system integration may lay with the latest generation of Enterprise Resource Planning (ERP)
databases; which are nowadays in common use throughout major global organisations.
ERPs have evolved through enterprise systems history providing corporations with solutions
for integrating disparate legacy business systems across intra-organisational boundaries
(Bendoly, Kumar & Esteves 2011). If ERPs can successfully solve voluminous data integration
issues between functional business areas then they should also be capable of solving project
control system integration issues. The use of fully ERP integrated project control systems
appears to be a relatively new development in project management. Andera, Weirich and
Worster (2012, p.130) suggests that this is because education and advanced understanding in
business knowledge areas such as project management has experienced significant
advancement over recent years. Specialised certification programs such as offered by the PMI

1
(Project Management Institute) means that more and more project practitioners are
developing advanced understanding and specialised skills in project management.
Advancements in project practitioner knowledge is driving the development of advanced ERP
integrated technical solutions as project management practitioners look beyond using their
ERP systems as a cost centre management tools and progress towards using the system as an
effective tool to drive project and business results (Andera, Weirich & Worster 2012, p.130).
Essex (2005) identifies this changing trend in project and portfolio management stating that
one of the key reasons why businesses are moving towards fully integrated project systems is
to provide decision makers with better visibility on their projects and investments. This
immerging trend is creating an opportunity for software developers to capture a piece of this
new market and there is a rush to fill the market space by many different vendors. However
this rush for technical solutions will not automatically produce integrated project control
environments, there needs to be change and acceptance within the organisation’s project
management culture across all levels of the organisation before full benefit can be realised
(Essex 2005). The success of fully integrated multidimensional project control systems (MPCS)
requires more than just IT processes and ERP configuration. It requires a new mind set; a
change in project control process; project practitioner educational programs and workforce
training in the underlining principals and deeper knowledge of not only the ERP integrated
application but also how the business operates; how projects are controlled and managed and
how to fully utilise the systems to maximise benefit (Andera, Weirich & Worster 2012;
Rozenes, Vitner & Spraggett 2006).
This thesis looks at the theory and practicality of MPCS and how MPCS can be integrated into
an operating business environment. The ERP system chosen for this study is SAP-PS (Project
Systems). The reason SAP-PS is being used is because it has the built-in project and portfolio
management tools required for MPCS and it closely integrates with all other aspects of
business management including Accounting, Materials Management, Sales, Production,
Human Resources, Plant Maintenance, and so on (Franz 2009). The principles derived in this
study should also be applicable to other ERP systems with the same level of functionality and
data integration as SAP-PS. The question that this thesis will endeavour to answer is whether
an ERP integrated project management system can truly offer a one-system solution that
performs the role of a MPCS and displace the legacy single dimensional project control
systems currently in common use while still meeting the needs and expectations of the project
manager and other key stakeholders within the organisation.

2
LITERATURE REVIEW
Historically project managers have relied on many different and disparate project control tools
to control the separate project knowledge areas within single dimensional control systems.
Fleming and Koppelman (1999) identified this as an issue when they studied the effectiveness
of integrated project control outside of the US Department of Defence. The use of standalone
disparate systems such as controlling time with a schedule, cost control treated separately as
project cost management; quality control; scope control; engineering and design control, and
so forth remains a common practice even in today’s competitive business environments. De
Marco and Narbaev (2013), Kim et al. (2008) and Deng and Hung (1998) have all observed this
fact in their separate reviews from different industries and countries around the world.
Atkinson (1999) comments that these “old and tired ways” of measuring project management
success need to go and project management needs to adopt new methodologies and tools
designed to achieve holistic project success.
Disparate singular dimensional project control systems have received much criticism within
many different project management literature sources reviewed. Cooke-Davies (2002)
suggests that traditional singular dimensional control systems are more concerned with
monitoring project management success as opposed to measuring project success against the
overall objectives. This distinctions is supported by Dweiri and Kablan (2006), Atkinson (1999)
and many others who agree that overall project success is dependent on not only whether the
project was “done right” but more importantly on product success. Dweiri and Kablan (2006)
elaborates on their statements by suggesting that project management success contributes to
product success however it doesn’t guarantee it. Project success must be viewed as a whole,
as the entire process required to produce the project product and singular dimensional
systems often fail to provide this level of visibility. Lauras, Marques and Gourc (2010)
comment that singular project controls systems do not provide a view of the project as a
whole and may even result in superfluous and incompatible performance measures being
produced that are used as lagging metrics and lack the strategic focus required to meet all
project success criteria.
The lack of project control system integration appears to be very common throughout the
project management sphere. The reasons for the lack of integration has been contributed to
many different reasons with some of the most common being that it is difficult and expensive
to implement integrated project control systems (Lukas 2008). Rozenes, Vitner and Spraggett
(2006) suggest that the prevalence of using disparate systems has resulted from the wide
spread adoption of standards developed by the two main bodies of knowledge, Project
Management Institute (PMI) and Association of Project Management (APM). This is most
evident in the PMBOK guide; which, specifically does not refer to project control as a distinct
knowledge area, but considers project control as a process performed within the other
knowledge areas (PMI 2013). Despite the continuous evolution in project management the
traditional approaches to project control remain lacking in methodologies, which may be
significantly contributing to some of the reasons why so many projects fail (Atkinson 1999; de
Falco & Macchiaroli 1998).
With the effectiveness of the traditional one dimensional project control methodologies in
question many project management researchers and practitioners are now recommending

3
that a multidimensional approach in project control is more effective at delivering success
across all project aims and objectives (Mantel et al. 2005; Nicholas 2004; Rozenes, Vitner &
Spraggett 2006). The concept of Multidimensional Project Control Systems (MPCS) is where
several dimensions are integrated within the same control system. A classical example of this
is Earned Value Management (EVM); which is used to monitor the two dimensions of time and
cost.
Earned Value Management (EVM) is described by Burke (2010) as a powerful project planning
and control methodology that integrates the project elements of time and cost to provide a
measure of the true progress in the project. Vanhoucke (2012a) explains that EVM takes into
account the work completed, time taken and costs incurred to help evaluate and control
project schedule and budget risks. Burke (2010) comments that earned value is a powerful
tool that enables project managers to track the true progress of a project not only in time and
cost but can also be used to monitor performance of work hours, tons of steel, cubic meters of
concrete, pages of documents or any metric requiring an efficiency measure against planned.
EVM has been comprehensively described by numerous sources including Vanhoucke (2012a),
Fleming and Koppelman (2010), and many others. The methodology has even been adopted
as a standard in several countries including the US and Australia:
 ANSI/PMI 99-001-2008 A guide to the project management body of knowledge
 AS 4817-2006 Project performance measurement using Earned Value
EVM is considered the best integrated project control methodology available today; however,
there are still many sources that suggest EVM does not integrate enough project dimensions to
fully cover all project success factors. Nicholas (2004) and Mantel et al. (2005) suggest that a
holistic project control methodology needs to consider more project elements than just time
and cost by also taking into account all other project success factors. This opinion is also
carried by Rozenes, Vitner and Spraggett (2006) who suggest that a project control system
should even go beyond the two dimensions of EVM to integrate more dimensions such as
investment management, finance, quality, operations, technical, etc.

THE CURRENT LANDSCAPE OF EVM

A study into MPCS must first review the current landscape of integrated project control
systems. This is made fairly easy in the fact that for many years now the integrated project
control landscape has been dominated by Earned Value Management (EVM). EVM as an
integrated project control system has been in use for over forty years (Fleming & Koppelman
1999). This standardised methodology was adopted by industries outside of the US
Department of Defence and gained significant favour amongst senior management and project
management professionals (Fleming & Koppelman 1999, 2003). EVM is still today considered
the most effective integrated project control tool used to manage project performance and
basically the only integrated control methodology described within the PMBOK project
management standard (PMI 2013).
Amongst many project management academics and practitioners there is a difference of
opinion over the effectiveness of Earned Value Management (EVM) as a reliable and accurate
project performance reporting and forecasting tool. There are many authors such as Fleming
and Koppelman (2003) and Vanhoucke (2012a) who suggest that EVM remains as one of the

4
most effective integrated schedule and cost control methods. Especially effective when used
as a high level WBS reporting tool for senior management and providing executives with an
auditable accounting process to report on large capital investment performance and predicting
the final cost of projects years before completion (Fleming & Koppelman 2003).
EVM also has its critics such as Cooper (2003) and Gupta (2008) who comment that EVM often
fails to perform as a more accurate forecasting tool over traditional cost and schedule control
methods. Cooper (2003) suggests that one of EVM’s main deficiencies is its requirement for
the over simplification of project structure and the methodology’s limitations when applied to
complex projects where there isn’t clear straight lines of well defined tasks. Cooper (2003)
also points out that EVM fails to take into account such complexities as rework which blurs and
confuses exactly the end of the task. Lukas (2008), Gupta (2008) and others agree that EVM
can even be disastrous for project management if the organisation trying to implement the
methodology has a low level of project management maturity and fails to prepare well defined
project plans with conforming work breakdown structures and detailed accurate estimates.
In practice EVM can easily and effectively be applied in a simplified form to high level WBS
breakdown structures and simple smaller stand alone projects (Fleming & Koppelman 2007).
The methodology works best as a top-down reporting and forecasting tool and with projects
that have clearly defined structures; easily quantified metrics; well developed estimate; and a
certain scope with little change (Gupta 2008). Problems with the EVM methodology arise
when the complexity of the projects increases; uncertainties start to creep into the project;
technical problems become evident and unquantifiable project requirements need to be
monitored, controlled and forecast (Gupta 2008; Rozenes, Vitner & Spraggett 2006;
Vanhoucke 2009). Issues surrounding the effectiveness of EVM occur around the activity level
and it is this end of the project where many academics agree that further research into
effective multidimensional project control is needed (Rozenes, Vitner & Spraggett 2006;
Vanhoucke 2012a).
There has been a lot of contemporary research into addressing the deficiencies of existing
integrated project control systems at the activity level. Naeni, Shadrokh and Salehipour (2011)
explain that in practice when activities do not have clearly definable metrics available EV
techniques tend to be deterministic and rely on peoples judgments to assess progress earned.
Naeni, Shadrokh and Salehipour (2011) explain how a fuzzy logic theory can be used to
calculate earned value for uncertain activities. Lipke et al. (2009) have developed improved
forecasting technique through advance use of statistic and Vanhoucke (2012b) introduces the
concept of using a Monte-Carlo simulation study on fictitious and empirical project data. All of
these advanced applications of EVM tend to add to the issues surrounding EVM at the activity
level; which, further makes the practical application of the methodology complicated,
expensive and unreliable in achieving accurate project performance and forecasting
information (Gupta 2008; Lukas 2008; Vanhoucke 2012a).
This review of the current landscape of integrated project control systems in use today
indicates that after many years of project management development there still remains a
reliance on single dimensional project control systems. There has been significant
development into integrating the two dimensions of time and cost with Earned Value (EV) and
it remains the most dominant integrated methodology. EV is basically the only practical

5
integrated multidimensional project control system available. Project success is however
reliant on more dimensions than just time and cost. As the profession of project management
continues to progress there is an increasing need for project control methodology to go
beyond the twin imperatives of time and cost to integrate additional control dimensions. The
following section describes the direction project management needs to development in order
to go beyond earned value management.

GOING BEYOND EARNED VALUE

Going beyond earned value requires a look at the concept of integrating dimensions of project
control that not only satisfy the traditional twin imperatives of time and cost but also integrate
all factors identified as being important (Lauras, Marques & Gourc 2010). Nicholas (2004) and
Mantel et al. (2005) extend this idea by suggesting that every project has three overriding
goals of budget, schedule and performance requirements. The budget and schedule elements
have been covered previously in the discussion on EVM; however, the performance
requirement is where the new dimensions are introduced. Nicholas (2004) explains that these
additional dimensions encompass the important elements that need to be done to reach the
end product and can include such elements as the final product or service, technological
specifications, and quality and quantity measures, whatever is important to the stakeholders
and end-user. This brings the other aspects of business management and stakeholder needs
and requirements into the project control spectrum, the importance of which that has been
recognised by the PMI with the inclusion of a thirteenth knowledge area Project Stakeholders
Management into the PMBOK Guide fifth edition (PMI 2013).
Rozenes, Vitner and Spraggett (2004) terms the additional requirements as project “success
factors”; which is common terminology in the study of project stakeholder management.
Integrating stakeholder requirements; which may be intangible, qualitative, unstructured,
variable and unclear within the traditional deterministic earned value methodology (EVM) can
be problematic (Naeni, Shadrokh & Salehipour 2011). Rozenes, Vitner and Spraggett (2006)
suggest that the key to project success is to somehow link these additional requirements to
the project control system. Nicholas (2004, p.10) and Mantel et al. (2005, p.5) offer a vectorial
representation of this relationship suggesting that every goal of the project is interrelated so
thus a change to one will impact on the others. Nicholas (2004), Mantel et al. (2005), Rozenes,
Vitner and Spraggett (2006) and many other sources all agree that project managers need to
manage all project goals and control the necessary tradeoffs between them to achieve project
success.
Figure 1 - Vectorial representation of project control dimensions

Source: (Meredith 2009, p.4; Nicholas 2004, p.10)

6
The vectorial concept of a multidimensional project control system (MPCS) is further
developed into a mathematical model by Rozenes, Vitner and Spraggett (2004). Within their
research Rozenes, Vitner and Spraggett (2004) propose a methodology that quantifies
deviations between the planning phase and the execution phase with respect to Global Project
Control Specifications (GPCS). Rozenes, Vitner and Spraggett (2004) utilise yield theory from
the manufacturing environment to represent the multidimensional deviations within the GPCS’
planned and actual values as a gap vector.
Figure 2 illustrates how the direction and magnitude of gap vector G provides an indication on
which areas of the project require more attention and what effort is required to take
corrective action. This is a capability that is currently not available within the traditional EVM
approach. It allows the project manager to determine the integrated project status; identify
where problems exist and draw attention to issues of integration whose cost is relatively low
but advantage relatively high. (Rozenes, Vitner & Spraggett 2004).
Figure 2 - Vectorial representation of project with gap vector G used to identify planned and actual divergence

Source: Rozenes, Vitner and Spraggett (2004)

Rozenes, Vitner and Spraggett (2004)’s MPCS methodology introduces a different approach for
the integrated control of multiple project goals. Project managers and project owners need to
accomplish many different project objectives in order to achieve project success. Several
sources studied in this paper agree that the majority of existing project control and
performance tools focus on the iron triangle project aspects of scope, cost and time but
neglect the softer project parameters that are also essential for project success (Cheung,
Cheung & Suen 2004; Lauras, Marques & Gourc 2010). Controlling the softer aspects of
project management and coping with multiple objectives is an essential part of the project
manager’s role; however, contemporary project management methodology provides little
suitable and practicable process to assist the project manager in achieving effective integrated
project control (Cheung, Cheung & Suen 2004; Lauras, Marques & Gourc 2010; Mantel et al.
2005).

7
There seems to be a consensus in the literature that there is currently a lack of project
management tools that support an integrated multidimensional project control approach
(Cheung, Cheung & Suen 2004; Lauras, Marques & Gourc 2010; Rozenes, Vitner & Spraggett
2006). Several authors including Lauras, Marques and Gourc (2010) and Niebecker, Eager and
Kubitza (2008) suggest that an effective method for controlling the critical factors that impact
so significantly on project success is to integrate metrics and key performance indicators (KPI)
into the project control dimensions. This approach is very similar to the vector MPCS analogy
proposed by Rozenes, Vitner and Spraggett (2004). On a similar lines of thought as MPCS,
Lauras, Marques and Gourc (2010) presents a methodology that identifies the relevance,
effectiveness and efficiency of project KPIs; monitors their successful achievement and
perform a global project performance analysis to identify deviations from planned across all
project goals.
Many of the ideas and examples proposed by the different authors mentioned above utilise
custom tools, databases and information collection sources that exist outside of the corporate
business systems. Such a method is not ideal because it compounds integration issues
requiring the upkeep of multiple sources of project information (Dowling 2008; Franz 2009).
Within the modern corporate environments utilising fully integrated business systems there is
only one true source of project performance information and that is the Enterprise Resource
Planning (ERP) system (Lau 2005b). Any data gathered external to the corporate ERP systems,
will need to be balanced and reconciled against the ERP system; which, introduces difficulties
in assembling and analysing project data pools making the process of project monitoring and
control tedious, time consuming and expensive (Cheung, Cheung & Suen 2004). Such a
process will not solve the existing inefficiencies previously identified within the EVM
methodology and but add to an existing problem.
If multidimensional project control systems (MPCS) are going to be effectively and efficiently
integrated into modern corporations utilising enterprise resource planning (ERP) systems, the
MPCS and processes will need to be fully integrated into the organisations ERPs with a direct
association between the processes of project management and business management. The
association between project management and business management can be linked through
the stakeholder success criteria identified in Rozenes, Vitner and Spraggett (2004)’s MPCS
methodology. All project relevant information, process, data and documents being made
simultaneously available with most other business management tools and information (Franz
2009). This approach is supported by Lauras, Marques and Gourc (2010) who propose that
project management process can be considered the same as business process with each task
under the WBS structure assimilated as business process activities, thus allowing standard
business process performance measurement systems to be extended into the project
environment.
The business process integration philosophy supported by Lauras, Marques and Gourc (2010)
appears logical and some of the ERP integrated project management applications such as SAP-
PS have even been developed with such an intent in mind (Franz 2009). The literature
however, appears very silent on how the practical applications of multidimensional project
control can be applied not only into the project environment but also the corporate ERP
systems. The following section looks at the current landscape of ERP integrated project
management applications and reviews the available literature on project control integration

8
within the corporate ERP systems and identifies the gaps in the knowledge on how the MPCS
methodology can be practically applied within an operating corporate project and business
environment.

CURRENT LANDSCAPE OF ERP PROJECT MANAGEMENT

SYSTEMS
In many corporations with a maturing project management culture there is a drive to start
looking for technical solutions that assimilate their disparate one-dimensional project control
systems and move towards a multidimensional project control solution (Franz 2009, p.13).
There are many different software packages available on the market that provide solutions for
the various individual control elements; however, very few can easily and reliably integrate
several project dimensions, especially those that are imbedded within the enterprise systems
(Dowling 2008). An Enterprise Resource Planning (ERP) system does however have the proven
architecture, functionality and data resources to achieve multiple levels of business system
integration that can also be utilised within the project environment (Modi & Mabert 2011).
Modi and Mabert (2011) performed a review of the enterprise system industry landscape and
described the enterprise system industry, identified the main components of the enterprise
systems and the top ERP system vendors. At the time of their review Modi and Mabert (2011)
found only five main ERP vendors offered integrated application intended to be used as project
management systems. These ERP providers include SAP, Oracle, Infor, i2 Technologies, and
IBM. The largest two ERP providers by market share are SAP and Oracle (Henderson 2009;
Modi & Mabert 2011). When considering ERP integrated project management systems SAP
and Oracle have a clear dominance over other systems; this can be contributed to their
respective positions in market share (Modi & Mabert 2011).
The development of project management system capability within the two major ERP
providers Oracle and SAP has followed different strategies. SAP-PS (Project System) has
organically evolved with the ERP since the early release in 1979 of the R/2 mainframe system
(Franz 2009). SAP-PS development has since the beginning grown with the help of industry
feedback. A good example of how industry requirements and recommendations have fed back
into the system’s development can be seen in the paper written by O'Connor and Dodd (2000).
O'Connor and Dodd (2000) investigated the impact of the SAP ERP system on capital project
delivery processes across various industries and produced recommendations for SAP
improvements to suit project management needs. SAP’s approach differs from Oracle who has
followed an acquisition strategy. In late 2008 Oracle acquired project portfolio management
specialist Primavera Software. Previous to this acquisition Oracle had no dedicated project
management solutions and the acquisition of the world’s leading Project Portfolio
Management (PPM) software developer effectively propelled Oracle into the Project Portfolio
Management market (Oracle 2008).
The majority of literature and study in the field of project management software is
predominantly concentrated on Oracle’s Primavera software and other stand-alone project
management software solutions such as MS Projects, ASTA PowerProject, Pertmaster, and
others (Geraldi & Lechter 2012; Moszkiewicz & Rostek 2011; Totin 2012). The dominate
players in project management software are Primavera and MS Projects which use the Gantt

9
chart as the central platform for planning and managing projects (Geraldi & Lechter 2012).
Besner and Hobbs (2008) identifies that project management relies on many more tools than
just the Gantt charts. This is where the SAP-PS system differs from the other main stream
project management systems. SAP-PS has Gantt charting as a function within its capability but
the system’s strongest attributes is its integration with other business and functional areas
(Dowling 2008; Franz 2009, p.13). SAP-PS’ business integration feature has been illustrated
within the SAP product information brochure and is use by Dowling (2008) to explain the
systems relationship with other business functional elements.
Figure 3 – Illustration of SAP-PS Integration across business

Source: (SAP 2013)

Franz (2009, p.13) and Dowling (2008, p.2) suggests that SAP-PS is one of the most capable
project management systems within the current range of ERPs. It is however difficult to make
a comparison between Primavera and SAP-PS because the available literature on SAP–PS is
very limited. Not only does there appear to be a lack of study into MPCS but there is also very
limited information on the performance of SAP-PS as a project management tool.
The potential of SAP-PS as a multidimensional project control system can be traced back to the
beginning of the parent suite of enterprise resource planning applications. SAP started off in
the 1960s as an integrated information system (IIS) and developed in scope and functionality
from an inventory tracking system, to materials requirements planning (MRP) and eventually
into an enterprise resource planning solution (ERP) (Lau 2005a, p.34). As one of the early
successful enterprise systems (ES); SAP achieved significant success in helping corporations
reduce problems associated with legacy business systems by migrating information into a
single integrated technology (Loonam & McDonagh 2005, p.2). Today SAP is the largest
developer of enterprise software applications in the world (Henderson 2009; Lau 2005a). This
position has come from successfully being able to help its clients deal with vast volumes of
data and coordinate their business processes and functions across organisational boundaries
on a global scale (Bendoly, Kumar & Esteves 2011, p.23).

10
Table 1 - Timeline of SAP ERP from its genesis up to present

YEARS DEVELOPMENTS

German company Software AG founded in Darmstadt in 1969, had early success in

1969
the American market with its Adabas database in the early 1970s

SAP was founded under the name "System-analyse und Programmentwicklung"

[System Analysis and Program Development] in Mannheim on April 1, 1972 by five
former employees of IBM Germany.
Installation and programming of the first IBM S/370 computers at an Imperial
Chemical Industries (ICI) plant in Östringen, Germany. The system was developed to
replace an existing punch card system used for purchasing and materials
1973
management. This first installation of SAP was termed a Material Information and
Accounting System (MIAS).
The founders developed the system for ICI but also included in the design the ability
to sell the system to other companies as a standardised solution. The MIAS system
included three components based on a single database: purchasing, inventory
management, and accounting.

By 1978 SAP’s customer base reached over 100 and further developments led to
software comprising a database and multiple standardized program packages, later
called SystemR. The software suite included an initial financial accounting (RF)
1978 package, completed in 1974, as well as components for inventory management (RM),
fixed-asset accounting (RA), and order management (RV). SAP’s modular standard
software package called SystemR monopolised the commercial software standard for
S/370 computers in Germany.

Development of SAP R/2 begins with a focus on business integration and

1979 standardisation. This is a deviation from its previous custom packages built
specifically to satisfy their customer’s individual needs.

SAP releases of R/2, which introduces an integrated standardised business product

which includes a cost accounting component and a production planning and
management component. The system is now termed as MRP II. Other expansions
1981
including human-resource management and operations maintenance (RM-Inst)
systems, which SAP again developed in close cooperation with customers. With R/2
SAP’s main focus is to develop standardized business software solutions.

SAP goes global with their customer base expanding outside of Germany into
1988 international markets with more than 1000 customers worldwide. SAP is publically
listed as SAP AG.

SAP releases R/3 to target small to mid size companies using AS/400 series computer
1992
systems running UNIX operating system and Oracle databases. This is a departure
from SAP’s traditional IBM mainframe focus. This change introduces many new
advantages including client-server principles; performance scalability; inter-

11
 operability between models and platforms such as Unix and Windows; advanced
security; greater standardization of business process; and user friendliness with a
GUI.
SAP R/3 is now termed an enterprise resource planning (ERP) systems. The system
provides a full integration across the company functional areas and introduces the
client-server technology. The timing of this new release is one the keys to SAP’s
current success because it occurs at a time when the software / hardware market
transitions from the traditional mainframe reliance to the rise of workstations and
PCs.

SAP consolidates its worldwide growth strategy with centres for sales and distribution
establish in many places worldwide. SAP starts to introduce fundamental innovations
in ERP software including complete integration of all subareas as well as new business
1996
models like e-business and other internet enabled solutions. New software
applications are added including Customer Relationship Management (CRM), Supply
Chain Management (SCM).

1999 SAP R/3 release 4.0B rollout introduces SAP-PS Project Systems module

The pending Y2K bug risk to business forced many enterprises to upgrade their legacy
2000 systems and many adopted the new generation of ERP offerings. This was a massive
boon for ERP vendors and consolidated the industry for a prosperous future.

SAP’s market share continues to grow and as the company starts to respond to the
changing new market demand through several acquisition of smaller technology
2002 companies. Developments of R/3 continue and it is now known as SAP ERP. SAP ERP
keeps up with new technology trends associated with the growth of the internet and
continues to be the global leader in enterprise software.

SAP continues its market lead and innovation with pioneering developments in
solutions for big data, the internet of things, mobile technologies and cloud based
2014 computing. The SAP ERP system is becoming much more intelligent with Data mining
and intelligence tools including expert systems, and advanced planning systems (with
optimization).

Source: (Lau 2005a; Leimbach 2008; Robert Jacobs & ‘Ted’ Weston Jr 2007)
As a brief technical definition; SAP’s primary system is known as SAP ERP 6.0 and consists of
three functional modules: SAP Financials, SAP Human Resources and SAP Logistics. Contained
within these primary modules are the sub-modules that form the business systems such as
financial accounting, investment management, recruitment, training, production planning,
project systems, material management and so on (Lau 2005a, p.37). All of these business
systems are designed by SAP developers who choose the best way in which business process
should be handled and incorporate “best practices” into the software (Brady, Monk & Wagner
2001). The main advantage of the ERP system over previous versions; and its main
competitive advantage, is the single point of data entry for users. This provides all business

12
processes and users with immediate access and usage of the data that has only been entered
once helping to reduce redundancy and making employees more efficient (Lau 2005a, p.38).
SAP ECC 6.0 and other ERP systems offer business many benefits that go beyond being tools
for completing business transactions; however, the systems do also have their disadvantages,
limitations and in some cases even performance reductions in certain business functional areas
when compared to pre ERP implementation (McAfee 2002). The advantages of ERP system
implementations normally out weight the disadvantages. Many sources concur that
enterprises basically need to effectively adopt an ERP system to successfully compete within
the modern commercial landscape or be doomed to failure by either loosing profit from less
economical legacy business applications or from being out competed by competitors who have
embraced the benefits of fully integrated ERP systems (Andera, Weirich & Worster 2012;
Annamalai & Ramayah 2011; Yang & Su 2009).
Table 2 - ERP System advantages and disadvantages

Advantages Disadvantages

Unified enterprise view of the business across
all functions and departments;
Single database where all transaction are
entered, recorded, processed, monitored and
reported;
Enables companies to achieve their objectives
of increased communications and
collaboration with all stakeholders;
Supports information sharing along business
lines and helps business achieve operating
efficiencies;
Maximise throughput of information and
minimising response times to customers and
suppliers;
Integrate information throughout the supply
chain;
Provide timely information to decision
makers;
Provide an integrated common set of
business applications across the organisation.
For many organisations implementing ERP
systems means the reengineering of their
business processes in fundamental ways to
suit the SAP ERP definitions of how business
should be conducted. This can cause a great
deal of disruption and even a decrease in
performances especially if the systems are
not fully adopted and supported;
ERP system rigidity once configured means
most business process options are fixed;
Users are restricted with limited freedom to
customise the business process to suit
individual preferences and must complete
processes according predefined rules;
ERP implementations are vastly complex and
can result in implementation failures due to
time/cost overruns and loss of management
support;
Users and managers must be focused on
making the system pay and contribute to the
business objectives or the system will not
deliver the benefits and performance
improvements expected.

Source: (Argyropoulou et al. 2011; Lau 2005a)

From the perspective of this thesis; the most significant limitation with the SAP-PS module is
that during configuration the project management processes are predefined by the SAP
developers. Therefore, if the project practitioners or other key stakeholders do not agree with

13
the philosophies then the system may not be fully supported or applicable to their needs.
Argyropoulou et al. (2011) comments that for many business that are motivated by the
potential business benefits available from an ERP system, unless managers are focused on
making the system pay and contribute to the business objectives these benefits will not be
fully realised. For this reason it is easy to understand that for a successful ERP integrated
multidimensional project controls system to deliver performance results over traditional
project control methodologies the project managers and practitioners must embrace the
system and strive to extract maximum benefit from the enterprise resource planning system.

THE NEED FOR FURTHER RESEARCH INTO ERP

INTEGRATED MULTIDIMENSIONAL PROJECT CONTROL
This literature review into project management integrated ERP systems has identified that
there is a significant amount of information and literature available on ERP systems with the
majority of information being centred on ERP technology related issues, evolving IT
architecture, and ERP system implementation (Kumar, Esteves & Bendoly 2011). There is also
a significant amount of literature and study into the main stream project management
software such as MS Projects and Primavera. For SAP’s native project management control
solution SAP-PS there is also abundant sources for reference manuals and guide books;
however, these sources concentrate on being instructional manuals for system users and
administrators with very little content on how the SAP-PS system relates back to project
management methodology and definitely no connection to multidimensional project control
theory
The study area of ERP integrated MPCS appears to be very fertile ground further research.
This view is supported by many sources for reasons including:
 Robert Jacobs and ‘Ted’ Weston Jr (2007) who believe the current ERP technology provides
an information rich environment that is ripe for improvements in planning, control and
execution logic. Their research has identified that for many businesses’ the current
application of business planning, control and execution has changed little since the late
1970s. Further stating that most organisations aren’t realising the full benefits of their ERP
system because they are basically using their new generation of ERP systems to simply
execute the same old logic much faster and in real-time;
 Several sources identify a lack of practical and effective project management tools that go
beyond the traditional earned value approach and supports an integrated
multidimensional project control approach (Cheung, Cheung & Suen 2004; Lauras,
Marques & Gourc 2010; Rozenes, Vitner & Spraggett 2006);
 Researchers Rozenes, Vitner and Spraggett (2004) have completed significant studies into
the MPCS knowledge area of project management and have identified that the area offers
great potential for further research;
 The literature review has identified that there appears to have been no research
undertaken on the performance of SAP-PS as a multidimensional project control system
(MPCS).
With a wealth of potential business benefit waiting to be realised through the effective use of
the ERP systems within the project environment combined with the knowledge there is a lack
of effectual and practical tools to help integrate a multidimensional project control

14
methodology into the project environment. This thesis will endeavour to explore the potential
of using the corporate ERP system as a fully integrated multidimensional project control
system by expanding on the study and definition of the theoretical characteristics of MPCS and
relating application of the knowledge back to the functionality and capability of SAP-PS as a
multidimensional project control system.

METHODOLOGY AND METHODS

The literature review performed as part of this research has identified that within the current
project management body of knoweldge the use and practical application of fully integrated
Multidimensional Project Control Systems (MPCS) appears to be lacking and many sources
agree that further research is needed into the integration of different project control
dimensions with the traditional EV approach. The literature review has also identified that
there is a lack of effective and practical tools available to support a fully integrated
multidimensional approach to project control. The identified gaps in the knowledge is the
focus of this thesis; which, aims to identify the characteristics of an integrated
Multidimensional Project Control System (MPCS) and investigate into the effectiveness of
using the corporate ERP system SAP-PS as a Multidimensional Project Control System (MPCS)
that meets the needs and expectations of the project manager and supports the requirements
of other key stakeholders within the organisation.

RESEARCH METHODOLOGY
To achieve the objective of this thesis the research method adopts a triangulated mixed
research methodology that follows a three step approach of:

Step 1 Develop an understanding and definition of MPCS;

Step 2 Through a case study define a collection of stakeholder success criteria which
are typical for engineering projects similar to the case study example;

Step 3 Assess the capability of SAP-PS to effectively monitor and control the
stakeholder success criteria within a multidimensional environment.

Step one and two gathered the qualitative information from two primary sources before
triangulating the information within a quantitative assessment. Table 3 below lists the primary
sources of information and their rationale for using them as information inputs:
Table 3 - The two primary sources of qualitative information

Literature review of previous work in the field of multidimensional project control systems
The literature review examines previous work in the area of MPCS, critically reviews existing
theory on the topic to develop an understanding on the current practices and technologies
being used in the field of MPCS (Evans, Gruba & Zobel 2011, p.103). The findings in this
investigation are then associated with the characteristics; functionality and capability of SAP-
PS to determine if the ERP system can be employed as an effective MPCS.

15
A case study into the stakeholder needs and requirements to identify a typical collection of
stakeholder success criteria applicable in engineering projects
The case study research method was used to undertake a stakeholder engagement process to
identify and prioritise the needs and requirements the project stakeholders require from a
MPCS. The case study captures opinion and experience from a variety of project stakeholders
including the project practitioners with a range of project management maturity levels
including beginner, accidental project managers and certified practicing professional project
managers (Darrell, Baccarini & Love 2010). The stakeholder engagement process also
captured the needs and requirements from a cross section of other stakeholders who do not
perform a project management function but are impacted by or can influence project
performance and success (PMI 2013, p.393).
The information gathered through the stakeholder engagement was related back to the theory
and study on MPCS and the functionality of SAP-PS to determine if the business Enterprise
Resource Planning (ERP) system SAP-PS can be effectively used to satisfy the project
stakeholders needs and requirements as well as integrate with other business and project
requirements to form a Multidimensional Project Control System (MPCS).

Many sources recommend the triangulated mixed approach as being one of the most
functional and best matched to the styles of research used in the engineering and built
environment sectors (Yin cited in Amaratunga, et al(2002, p.20)). The qualitative information
gathered from the case study into project stakeholder needs and requirements and the
literature review into the principals, concepts, trends, opinions and findings developed by
previous researchers within the body of knowledge were triangulated with a quantitative
assessment of SAP-PS in the form of a software system verification test (Amaratunga et al.
2002; Freeman 2002). Figure 4 illustrates how the different research elements relate to each
other within a triangulation of research.

16
Figure 4 - Triangulation of research

Source: (Amaratunga et al. 2002; Borrego, Douglas & Amelink 2009)

RESEARCH METHODS

LITERATURE REVIEW
The intent of the literature review is to establish the context of the thesis by surveying and
critically reviewing existing theory on the topic; to investigate deeper into the background of
the theory and principals of MPCS and examine previous attempts by others to solve the
problems and apply the theory (Evans, Gruba & Zobel 2011, pp.103 - 105). The literature
review continued throughout the thesis and remained focused within the theoretical
framework of the following key study areas:
 Project management principals related to traditional project control;
 Principals, concepts trends and opinions of Multidimensional Project Control (MPCS);
 Project stakeholder management and involvement specifically aligned with MPCS;
 Functionality and capability of the corporate ERP, SAP Project System (SAP-PS) to monitor
and control achievement of the project stakeholder success criteria.

17
 STAKEHOLDER IDENTIFICATION AND NEEDS ANALYSIS
CASE STUDY

CASE STUDY METHODOLOGY

A case study was conducted to establish the success criteria and multidimensional integration
points common for industrial engineering projects typical of the type being executed within
the case study example. The case study was performed within an established framework for
project stakeholder identification and needs analysis as prescribed by the PMBOK Guide Fifth
Edition (PMI 2013). The stakeholder engagement method used has been chosen because it is
an established process described by many sources as being an effective and preferred method
for capturing the required opinions, attitudes, values and characteristics of the project
stakeholder (Jepsen & Eskerod 2013; Maley 2012; PMI 2013, p.391).
The organisation studied is a global provider of commercial explosives and blasting systems to
the mining and infrastructure markets. The case study was limited to the project stakeholder
identification and needs analysis from two of the organisation’s industrial continuous
manufacturing chemical plants. The projects executed for the two continuous manufacturing
plants are delivered as a programme of projects managed by a separate corporate project
delivery division who are responsible for managing capital projects for their customers, the
manufacturing plants. The portfolio of capital investment projects consists of approximately
500 individual engineering projects with a diverse range of delivery scopes and many varied
stakeholders. The portfolio of projects and the varied stakeholders offers an excellent case
study example with a diverse list of stakeholder success criteria that can be used as
assessment parameters for a MPCS investigation.
The project stakeholder analysis was conducted as interviews with discussions centred on the
typical type of capital investment engineering projects executed within the continuous
manufacturing chemical plant environment having a value of between $500,000 and
$5,000,000. This project range was chosen because it represents 80% in number of capital
investment projects within the organisation. The respondents to the interviews are normally
related to this type of project as either part of the project management team, internal key
stakeholders or external stakeholders.
The stakeholder identification and needs analysis followed a three stage process in alignment
with Jepsen and Eskerod (2013)’s recommendations:
 Identify project stakeholders – Who can affect or be affected by the project process or
deliverables and who is the most influential over the project;
 Project stakeholder assessments – What are the requirements of each stakeholder and
how do these requirements contribute to project success;
 Project stakeholder and requirements prioritising – Prioritisation and ranking of the
stakeholder requirements to filter the many identified requirements down to the most
important requirements that can influence project success.
In compliance with the ethical terms of this research the interviewee’s names are not disclosed
only organisational functional roles are referenced within the research material. The

18
organisational and manufacturing plant names and all project financial and budget details are
also kept commercially confidential.

PROJECT STAKEHOLDER IDENTIFICATION

The purpose of this section is to identify all the individuals and groups of project stakeholders,
internal or external, who can influence the type of projects being used as an example or can be
affected by the projects and their deliverables (Burke 2007). It is important to note that this
identification process also includes the project managers and project team members. To help
in the identification of all stakeholders the analysis first categorise the stakeholder groups
using the PESTLE method (Maley 2012). The PESTLE method was used because it is recognised
by several sources as being an ideal approach for breaking stakeholder groups into smaller
divisions until you arrive at the lowest level of the responsible individual or group. This
process aids in the identification of the important individuals and groups who may otherwise
be over looked (Maley 2012; Rhodes et al. 2014)..
Figure 5 - PESTLE model for stakeholder identification

Source: (Maley 2012)

The stakeholder identification followed the recommended process of (Maley 2012; PMI 2013):
1 Develop PASTLE diagram to consider all potential sources of stakeholders;
2 Consider the relevance of the potential stakeholders to the project;
3 Consider the power and influence of the different stakeholders over the project;
4 Develop a list of primary stakeholders who have immediate interest in the project;
5 Refine the list of stakeholder to the groups and individuals who have the most interest
in and relevant power and influence to impact on the project outcomes.
Identified stakeholders and groups were listed in a Stakeholder register nominating their
respective PASTLE group ready for examination of their needs and requirements and later
requirements ranking. This method is described in the PMBOK fifth edition where it is
suggested as being one of the main project stakeholder management outputs (PMI 2013).

19
Figure 6 - Stakeholder register table

Source: (Burke 2007)

PROJECT STAKEHOLDER REQUIREMENTS

IDENTIFICATION
Following the stakeholder identification process interviews were held with the individuals or
group to discuss the typical stakeholder’s key interests. Maley (2012) suggests that one of the
advantages for using the PESTLE method is that it allows meeting and interview questions to
be structured around the targeted interest category. For example, business managers will be
interested in financial and organisational issues, whereas engineers and technical experts will
be interested in the technical aspects. The interviews were conducted as a conversation
between the interviewer and respondent with the purpose of eliciting the information
required to construct a list of project success criteria. The interviews followed a semi-
structured format focused on a common set of five key questions:
 What are your likely expectations of the projects?
 What do you see as being your key measurable requirements during project execution
(project success criteria)?
 What role would you wish to hold during the projects?
 What benefit would you normally expect to see from the projects?
 What negative impacts might there be from the projects?
Source: (Maley 2012, p.77)
Interview respondents were invited to participate using standard business meeting protocols.
Email invitations were sent with a brief agenda and a copy of the research information sheet.

20
The interviews had a maximum duration of 30 minutes. The established question plan was
followed but the conversation was flexible enough to pursue interest tangents where
applicable (O'Leary 2004, p.164). Stakeholder requirements recorded during the interview
were minuted in an interview questionnaire template. The requirements identified in the
interview were transcribed into the stakeholder requirements listing table where each
requirement is listed and prioritised relative to the requirement’s importance to project
success.
 Refer to Appendix A for the research information sheet;
 Refer to Appendix D for the stakeholder meeting invitation email;
 Refer to Appendix E for the stakeholder questionnaire form;
 Refer to Appendix F for the stakeholders requirements listing.

PROJECT STAKEHOLDER REQUIREMENTS

PRIORITISATION
The stakeholder group selection for this research was limited to twelve individuals to avoid a
large complex stakeholder analysis and keep the process manageable. Bradley (2010, p.12)
suggest that an effective final stakeholder listing should consist of between six to 15 different
groups or individuals. The sample size of interviewees used in this research not only aligns
with Bradley (2010, p.12)’s recommendations but is also representative of all of the key
stakeholder functional departments within the case study organisation and provides a sample
size of respondents suitable for characterising the nature of internal stakeholder requirements
(Zikmund 2013, p.8). The stakeholder roles and groups were limited to the following twelve
organisational roles;
1. Accountant
2. Engineering Manager
3. Finance Manager
4. Maintenance Manager
5. Maintenance Planner
6. Programme Manager
7. Project Engineer
8. Project Manager
9. Purchasing Officer
10. Reliability Engineer
11. Superintendent
12. Operations Manager
Following the recommendation of the PMBOK guide the stakeholder requirements were
ranked to determine the most important ones that have the most potential to impact on or
support the project’s goals (PMI 2013). The prioritised stakeholder requirements were termed
the project success criteria (Rozenes, Vitner & Spraggett 2006). The ranking method followed

21
the guidelines given by the PMBOK guide fifth edition and ranked the requirements according
to the stakeholder’s power and interest (PMI 2013).
To provide a more quantifiable ranking metric than the simplistic High-High or Low-Low
results, the standard power-interest grid was modified in line with Maley (2012)’s method and
the power-interest axis’ were graded into five divisions.
Figure 7 - Stakeholder power-interest grid for quantifying the success factors.

Source: (Maley 2012; PMI 2013)

The method adopted for quantifying the project success criteria followed Ackermann and Eden
(2011)’s suggested process of:
1 The project manager values the stakeholder power index. To avoid subjective
assessments a power index was aligned with the organisational functional structure;
2 The project manager subjectively values the stakeholder influence index;
3 The intersecting coordinates are used to calculate the success criteria ranking index
using the formula: (Success Factor Sf )= 25/(power x influence)). The success criteria
ranking formula produces a factor between 0 and 1 that can be used to prioritise the
list of success criteria.
For the purposes of this research the power ranking was aligned with the stakeholder’s
position within the organisational functional structure. Figure 8 illustrate how the different
organisational functional levels were aligned with the power index. Alignment of the power
ranking with the stakeholder’s level in the organisation is consistent with Parent and
Deephouse (2007)’s findings who suggest that there is a strong correlation between the salient
power of a stakeholder and their level within the organisational structure.

22
Figure 8 - Stakeholder power ranking index aligned with functional structure

Source: (Parent & Deephouse 2007; Robbins 2000)

The stakeholder interests were ranked following Maley (2012)’s suggestion where the interest
is scaled relative to how much the stakeholder’s needs and expectations are related to the
project aims and how interested they are to commit resources to influence the project. Jepsen
and Eskerod (2013, p.42) comment that a good example of a high interest is where a
stakeholder is willing to commit to participating in time consuming communications such as
workshops. During the stakeholder interviews the interest ranking was observed through the
discussions which were centred on the typical capital investment projects having a value of
between $500,000 and $5,000,000 and then subjectively valued and recorded within the
Power-Interest grid against the corresponding stakeholder requirements.

EVALUATION OF SAP-PS
This part of the research is a quantitative experiment used to empirically investigate the
effectiveness of using the corporate ERP system SAP-PS as a fully integrated multidimensional
project control tool that can be used to monitor and control the successful fulfilment of the
project stakeholder’s needs and requirements. The experiment was conducted within a non-
live test database environment running SAP ECC 6.0 with the standard SAP-PS module enabled
and configured for project networks. The test database is fully populated with replicated
operational data from a full production system database.
Inputs for the test were developed from the case study example projects. Inputs included
sample project plans, identified stakeholder requirements and simulated project execution
data.
Table 4 - Test Inputs Defined

Project Data
The scope, schedule and estimate are represented in WBS form. Burke (2007) describes the
WBS as an excellent tool for quantifying the scope of work and the primary project
management tool used to ensure the complete scope is accurately captured, estimated and
scheduled.

Stakeholder Requirements
The identified stakeholder success criteria were integrated into the project setup. This was

23
achieved by ensuring that the project setup was configured to ensure as many of the success
criteria as possible are captured in the system. This approach is recommended by several
sources reviewed including Rozenes, Vitner and Spraggett (2004) and Shenhar et al. (2001)
who advocate that the project success criteria need to be established prior to implementation
and then the project managed to deliver on the success criteria.

Execution Data
Typical project execution data was entered into the project using the same method as a live
project would collect data. Hours were booked against activities; procurements were goods
receipted and services received. All data entered was fictional and no real goods or costs
incurred.

The outputs from the test report on the standard project performance metrics of time, cost
and scope, which is used for earned value measurement, as well as verifying the successfully
fulfilment of the stakeholder success criteria used for multidimensional project control
(Freeman 2002; Meredith 2009; Rozenes, Vitner & Spraggett 2006). Figure 9 illustrates how
the inputs feed into a black box verification test and how the outputs relate to the standard
project metrics used for earned value and the additional metrics needed for multidimensional
project control.
Figure 9 - SAP-PS Black-Box test structure

Source: (Khan & Khan 2012)

The experiment was conducted as a Black Box verification test. A black box test is described by
Khan and Khan (2012) and Freeman (2002) as a test that treats the software system as a
closed system and focuses solely on the functionality of the system without any knowledge of
the internal workings of the software. A verification test, also known as a system verification
test, is commonly used during software commissioning to assess if the fully functional software
implementation meets all objectives and system requirements without having to perform tests
on a live system (Freeman 2002). Figure 9 illustrates the Black-Box test structure used for the
experiment.

24
The testing process followed Copeland (2004)’s recommended sequence of:
1 Requirements and specifications established;
2 Valid inputs chosen;
3 Expected outputs for the inputs determined;
4 Test scripts constructed with selected inputs;
5 Run tests;
6 Actual outputs compared against the expected results;
7 Success of the test determined.
The test procedure was developed using the following sources of information and data:
Table 5 - SAP-PS Test Procedure

1 Requirements and specifications established

 Established through the literature review, essentially the purpose of this thesis. An
investigation into the effectiveness of using SAP-PS as a multidimensional project
control system.

2 Valid inputs chosen

 5 x case study simulated project plans set-up in SAP-PS. The simulated projects
represent the typical type of capital investment engineering projects executed within
the continuous manufacturing chemical plant environment having a value of
between $500,000 and $5,000,000;
 Projects’ scope represented as a WBS structure. Scope estimated and scheduled
using network activities;
 MPCS control points developed from the project stakeholder success criteria
identified through the stakeholder needs and requirements analysis. Control points
used to meet success criteria were configured into the project structure where
required. Other control points identified in the outputs;
 Simulated execution data entered. Execution data representative of the case study
projects in the form of labour hours, procurements and delivery of services.

3 Expected outputs for the inputs determined

 Scope delivery measured as time and cost against WBS elements to produce project
performance data in earned value terms;
 Expected outputs defined for stakeholder success criteria. If the success criteria can
be monitored and controlled within SAP-PS the test records a validation score
against each identified success criteria of k = 1 (achieved) or k = 0 (not achieved).

4 Test scripts constructed with selected inputs

 Test script was developed as an extension of the stakeholder’s requirements listing.
 Each stakeholder requirement listed in the test script with SAP-PS transaction code
on how the requirements is going to be satisfied and expected output after test is
conducted;
 Appendix G SAP-PS Test Script contains the final test script.

25
5 Run tests
 System verification test conducted in non-live test database environment running
SAP ECC 6.0 with the standard SAP-PS module enabled and configured for project
networks;
 Reports generated or on screen displays captured.

6 Actual outputs compared against the expected results

 Results of test recorded in test script against corresponding stakeholder success
criteria;
 Results are represented are either:
− Description of final result
− Screen shot of test result from system
− Tabulated report output from system

7 Success of the test determined

 Verification on whether the system is capable of monitoring and controlling the
stakeholder success criteria is recorded against each identified success criteria
 Verification indicator k = 1 (achieved) or k = 0 (not achieved).

Source: (Copeland 2004)

Results from the test are analysed in the following chapter. The terms of the ethics agreement
require that all case study stakeholder names remain non identifiable and all company
information is commercially confidential. The results of the test are listed against
organisational functional structure roles only and any commercial information displayed is
from fictional scenarios with no relation to real world projects. The outputs from the test and
information gained from the stakeholder needs analysis provide an accurate simulation of a
real engineering projects being executed within a real operating continuous manufacturing
chemical plant environment.

ANALYSIS AND RESULTS

The results from this research are used to evaluate the effectiveness of using SAP-PS as a
multidimensional control tool that can be used to monitor and control the successful
fulfilment of the project stakeholder success criteria. This analysis section follows the
structure of:
1 Analysis of the project stakeholder identification process used to identify the most
influential stakeholders;
2 Analysis of project stakeholder interviews used to establish the stakeholder success
criteria required for the multidimensional project control system verification test;
3 Analysis of the stakeholder success criteria prioritisation;
4 Results from the SAP-PS system verification test;

26
 PROJECT STAKEHOLDER IDENTIFICATION
The primary input into the assessment of SAP-PS as a multiple dimensional controls system is
the stakeholder success criteria. To define the stakeholder success criteria all potential
stakeholders were first identified by using the PASTLE method and then the number of
potential stakeholders filtered until the most suitable individuals and groups for the research
purpose were selected. The filtering process followed The PMI (2013)’s suggestion by first
including decision makers or management roles who have the relevant power and influence to
impact on project outcomes. Then the next selection process was to perform a preliminary
evaluation of the stakeholder’s power and interest relative to the case study projects. Using
this process many of the initial stakeholders identified using the PASTLE method were
excluded from the assessment because their relevance to the projects was deemed to be
scoring Low-Low on the Power-Interest grid.
Figure 10 illustrates where the exclusion lines was drawn against the PASTLE diagram. All of
the individuals and groups identified as being important to the case study projects came from
the internal stakeholders with the structure of their relationships to the case study
organisation following the organisational functional hierarchy structure
Figure 10 – Filtered PASTLE diagram

Source: (Maley 2012)

27
 Figure 11 – Case study project stakeholder functional structures

Manufacturing Engineering
Project Delivery
Plants Department

Finance Operations Maintenance Programme Engineering

Manager Manager Manager Manager Manager

Operations Plant Reliability & Project

Procurements Accounts
Superintendent Maintenance integrity Manager

Purchasing Plant Project

Planner Engineer
Officer Accountant Engineer

Source: (Parent & Deephouse 2007; Robbins 2000)

Figure 11 is an illustration of the participant stakeholder’s organisational structure relative to
the case study projects. The level of projects being assessed during this research did not
warrant the consideration of the external stakeholders. This is because the projects are
technical project with little significant to other stakeholders outside of the organisation.
In situations where the project manager is identifying stakeholders for politically,
economically, environmentally or socially important projects the relevance of the external
stakeholders could rank significantly within the stakeholder identification process and warrant
inclusion in the assessment (Parent & Deephouse 2007). The needs and requirements of the
external stakeholders should then be included in the multidimensional project controls
structure. Extending the MPCS to include the needs and requirements of the external
stakeholder’s within the corporate ERP system is an area requiring further research.

PROJECT STAKEHOLDER SUCCESS CRITERIA

The stakeholder success criteria were defined from the case study interview responses. The
stakeholders were invited to take part in the interviews using standard business meeting
protocol. First the identified stakeholders were informally solicited for participation and then
a formal meeting invitation was communicated via email. All respondents received an
information sheet providing a brief of the research being conducted and an explanation on the
process being undertaken.
The interviews followed the question plan but the conversation was allowed to explore
tangents when the opportunities arose. Although formally arranged and semi-structured the
nature of the interviews did follow O'Leary (2004, p.164)’s recommendations of keeping the
interviews informal with the intention of maintaining a relaxed and natural environment
conducive to open and honest communication. This approach proved very effective with the
interviewees enthusiastically participating in the interview and actively identifying the
necessary success criteria related to their key interests.
Responses to the questions were recorded in an interview question form for later refinement
and analysis within the stakeholder requirements listing table. Each respondent was informed
about the purpose of the interview and requested to sign the ethic consent form. All

28
respondents accepted the terms of the interview and willingly participated. The method used
for gathering the stakeholder requirements was very effective and validated the opinion of the
many sources referenced that the stakeholder engagement method undertaken is one of the
most effective for identifying key stakeholder needs and requirements (Burke 2007; Jepsen &
Eskerod 2013; Maley 2012; PMI 2013).
Responses from the interview were transcribed from the interview form into the stakeholders’
requirements table for prioritisation. It was identified that many of the nominated
stakeholder requirements were very similar and sometimes even identical for subordinate
roles within the same organisational functional hierarchal structure and across functional
departments. Within the same departmental functional structures many of the like
requirements were compounded and shortened for brevity purposes and to produce a useable
list for prioritisation and analysis. Appendix F contains the complete stakeholder requirements
listing after refinement.

PROJECT STAKEHOLDER SUCCESS CRITERIA

PRIORITISATION
Following the stakeholder engagement process each identified requirement received a
performance factor relative to their importance and influence over project success (Jepsen &
Eskerod 2013). Ranking the stakeholder requirements is an essential part of stakeholder
management. Many sources term the ranking index given to the stakeholder requirements as
a success factor and suggest that it is essential for the project manager to rank the many
identified stakeholder requirements in order of importance to the success of the project
(Ackermann & Eden 2011; Jepsen & Eskerod 2013; PMI 2013; Rozenes, Vitner & Spraggett
2004).
The ranking and prioritisation of stakeholder requirements allows the project manager to
concentrate management effort on those stakeholder success criteria that are deemed the
most important (Ackermann & Eden 2011). For the purpose of this research the final
stakeholder listing was filtered to a more manageable level of twelve of the most influential
stakeholders and then their requirements further limited to include only those that ranked
highly in the power interest assessment (Bradley 2010, p.12). Only the stakeholder
requirement’s that scored 0.4 and above were included in the assessment. Stakeholder
success criteria that ranked less than 0.4 were excluded because they fell into the ranges of
Low-Low (monitor) and High-Low (keep Informed).

29
Figure 12 - Stakeholder success criteria with low ranking excluded from the assessment

Source: (Maley 2012; PMI 2013).

EVALUATION OF SAP-PS
The analysis and results are intended to indicate whether the corporate ERP system SAP-PS is
effective at monitoring and controlling the standard project control metrics of scope, time and
costs as well as monitoring and controlling other stakeholder success criteria within a
multidimensional project control system. To determine effectiveness for the control system a
verification test was conducted for each of the stakeholder criteria to determine if the system
is capable for monitoring and controlling the requirements. A validation score was recorded
against each success criteria. If the success criteria can be monitored and controlled within
SAP-PS the test records a verification indicator against each identified success criteria of k = 1
(achieved) or k = 0 (not achieved).
The results from the overall test indicate that the majority of the stakeholder success criteria
(83%) are capable of being satisfied within SAP-PS. When separated into organisational
functional reporting structures the results provide an indication of the functional departments
whose requirements are not fully being measured within SAP-PS.

30
 Table 6 - SAP-PS evaluation results against functional departments

Success Percent
Department Criteria Achieved Achieved
Engineering 5 5 100%
Maintenance 15 15 100%
Finance 16 14 88%
Programme 15 11 73%
Production 15 10 67%
Grand Total 66 55 83%

A look at the requirements that received a verification indicator of k = 0 (not achieved) for
each or the functional departments shows that there are common requirements not being met
and the majority of the organisational roles whose requirements are not achieved originate
from more senior positions in the organisational structure.
Table 7 - Verification test results for k = 0 (not achieved)

Success
No. Department Role Stakeholder Requirements Factor k
Programme Programme Single source of information used "One
0.64 0
3 Manager truth" Projects planned and executed in SAP
Programme Programme Stakeholder needs and requirements
0.8 0
5 Manager effectively identified and managed
Programme Project Project product functions according to
0.6 0
7 Manager original criteria
Programme Project Clear KPIs identified at start of the project.
0.48 0
12 Manager Stakeholder success criteria clearly identified
Finance Finance Project delivers benefit over whole of project
Manager life. Project exists beyond implementation.
0.48 0
Project needs to be assessed for benefit
23 delivery until end of asset life.
Finance Finance Project adds value to the business according
Manager to original promise (e.g. productivity, safety, 0.4 0
24 regulatory)
Production Plant Manager Estimating to liberal, too much contingency
0.8 0
47 on original estimate
48 Production Plant Manager Warranty period on projects group 0.8 0
Production Plant Manager Original criteria / idea delivered. Project
product is fit for purpose and delivers original 0.64 0
52 promise
Production Plant Manager Construction, implementation and training
0.48 0
55 delivered efficiently
60 Production Superintendent Perform the role of commissioning manager 0.6 0

Many of the success criteria that failed the verification test did so because the nature of the
requirement is too intangible for a computer system to calculate or be configured to control.
In contrasts the success criteria that scored a verification indicator of k = 1 (achieved) are
more tangible in nature and thus quantifiable within a computer system.

31
Table 8 - Verification test results for k = 1 (achieved)

Success
No. Department Role Stakeholder Requirements Factor k
Programme Programme Project process flow correctly followed
0.8 1
1 Manager
Programme Programme Schedule, budget and resources effectively
0.8 1
2 Manager planned and managed
Programme Programme Projects planned and executed down to the
0.64 1
4 Manager package level
Programme Project Effective time, scope and cost control
0.6 1
6 Manager
Programme Project Clear expectation around iron triangle Time-
0.6 1
8 Manager Cost - Scope
Programme Project Clear timing of critical milestones (non-
0.6 1
9 Manager project) e.g. shutdown timing
Programme Project Project planned. Accurate project forecasts
0.6 1
10 Manager
Programme Project Easy effective tools for project planning,
0.6 1
11 Manager monitoring and control.
Programme Project Meeting minutes approvals. Ensure all
Engineer mods are approved and signed off prior to 0.4 1
13 implementation
Programme Project Mods design and process needs to start as
Engineer early as possible and continue up to 0.4 1
14 implementation.
Programme Project System simplifies procurement process
0.4 1
15 Engineer
Finance Finance Accurate materials catalogue
0.8 1
16 Manager
Finance Finance Capitalised asset register
0.8 1
17 Manager
Finance Finance Visibility on all project expenditure (No
0.8 1
18 Manager hidden stock)
Finance Finance Components procured through materials
0.8 1
19 Manager catalogue
Finance Finance Budget respected. Time and cost
0.64 1
20 Manager
Finance Finance Good schedule, budget, estimate control
0.64 1
21 Manager
Finance Finance Accurate stock valuation
0.64 1
22 Manager
25 Finance Accountant Budget is respected 0.48 1
Finance Accountant Planned project commitments. Control on
committed costs should be managed in
accordance with business needs i.e. 0.48 1
deferred or accelerated depending in
26 response to business cash flow needs
Finance Purchasing All procurements effectively planned
0.4 1
27 Officer
Finance Purchasing Minimised rework on purchase orders
0.4 1
28 Officer
Finance Purchasing Requisition transparency
0.4 1
29 Officer

32
 Finance Purchasing Stores must goods receipt all components
0.4 1
30 Officer (no services used to purchase components)
Finance Purchasing Materials master data used strategically to
0.4 1
31 Officer deliver maximised value for the business
Maintenance Maintenance Turn around and outage integration. Clear
Manager visibility through the plant maintenance
system on all projects being executed within 0.8 1
scheduled plant maintenance turnaround
32 and shutdowns
Maintenance Maintenance All project components procured through
Manager the material catalogue linked to plant 0.64 1
33 functional location and equipment
Maintenance Maintenance All maintenance strategies and spares in
0.8 1
34 Manager place before project commissioning
Maintenance Maintenance Project components procured through the
Manager maintenance process to ensure adherence
to engineering specifications to ensure
materials are procured based on asset life 0.48 1
cycle and master data is created before
35 requisitions are raised
Maintenance Maintenance Maintains an accurate spare parts catalogue
0.48 1
36 Manager and store stock (right time and right place)
Maintenance Maintenance All plant maintenance resources required
Manager for project purposes must be planned and
scheduled through the PM system 0.64 1
(maintenance resources, reliability
37 engineering, maintenance asset planning)
Maintenance Maintenance All project handover documentation is
Manager available and accessible in the maintenance 0.64 1
38 system prior to commissioning.
Maintenance Maintenance Materials procured through catalogue
0.4 1
39 Planner
Maintenance Maintenance Accurate procurement planning
0.4 1
40 Planner
Maintenance Maintenance Materials Master Data complete
0.32 1
41 Planner
Maintenance Reliability Maintenance strategy in place for all
0.4 1
42 Engineer engineering materials
Maintenance Reliability Engineering materials procured to
0.4 1
43 Engineer maximised common spares
Maintenance Maintenance Centralised procurements to add value for
0.4 1
44 Planner the business
Maintenance Maintenance Systems drives accurate procurement
0.4 1
45 Planner planning
Maintenance Maintenance Maintenance strategy in place before
0.4 1
46 Planner project goes online
Production Plant Manager Efficiency in delivery during the expenses
portion. This cost is immediate and comes 0.8 1
49 off the bottom line.
Production Plant Manager Efficiency in delivery during the capital
portion. This cost is depreciated and 0.8 1
50 increases production's cost per tonne ration
51 Production Plant Manager Project delivered on time and cost 0.64 1

33
 Production Plant Manager Project efficiency, especially during concept
- prefeasibility phase. Efficiency in cost and 0.64 1
53 reaching promised timeframe
Production Plant Manager Material master fully completed before
0.64 1
54 project is delivered
Production Superintendent All operators trained before project goes on
0.6 1
56 line
Production Superintendent All Mods processed effectively and
0.6 1
57 completed
Production Superintendent All safety requirements completed. Full
compliance with site safety management 0.6 1
58 plan (e.g. permit to work)
59 Production Superintendent Owners representatives kept fully informed 0.6 1
Production Superintendent OEM operating documents available and
loaded into system as part of operational 0.48 1
61 readiness
Engineering Engineering Engineering resources working on individual
0.8 1
62 Manager projects planned effectively
Engineering Engineering Control of resource utilisation on projects
0.8 1
63 Manager
Engineering Engineering Accurate engineering estimates planned in
Manager packages and then executed according to 0.8 1
64 plan
Engineering Engineering Project work scope effectively
0.8 1
65 Manager communicated to engineering work team
Engineering Engineering Visibility of all hours worked within projects.
Manager Control of actual hours worked against 0.8 1
66 planned

The stakeholder needs and requirements analysis has identified that the most common and
significant success criteria within the projects remains the traditional metrics of scope, time,
and cost. Controlling the traditional metrics are standard features within SAP-PS. Many of the
success criteria that require multidimensional integration are common across the different
departments and include the multidimensional control points of:
 Procurements planning and control
 Plant maintenance integration
 Integration with the plant equipment and material catalogue
 Document control
The verification test has confirmed that the majority of the success criteria can be controlled
using standard functions in SAP-PS. The multidimensional project control system does
however first need the success criteria identified from the stakeholders and then they can be
used as inputs into the MPCS configuration and setup.
The verification test has identified that the success criteria originating from the subordinate
roles within the departmentalised functional hierarchy structure tend to be more tangible and
are more easily controlled from the corporate ERP system. The most significant observation
from this analysis is that the uncontrollable success criteria originate from the more senior
stakeholder roles within the organisational hierarchy structure. They tend to be intangible in
nature and difficult for a computerised project control system to address.

34
DISCUSSION

DEFINING STAKEHOLDER SUCCESS CRITERIA

Before an investigation into the effectiveness of using SAP-PS as a multidimensional project
control system could be undertaken this study had to first define the dimensions for
multidimensional control. Meredith (2009), Nicholas (2004) and many other sources all agree
that the additional control dimensions needed for MPCS all originate from the various project
stakeholders who can be impacted by or can influence project performance and success. The
most effective method for identifying and prioritising project stakeholders and their various
success criteria has been well defined by many sources reviewed and has even been included
in the last revision of the PMBOK (PMI 2013). The stakeholder identification process does
however have the potential to identify an overwhelming number of stakeholders, which can
make the job of managing their various requirements time consuming and potentially
detrimental for the project manager and project performance (Bradley 2010, p.12).
In this study the PESTLE method was used to resolve the key stakeholder listings into the most
relevant dimensions for the outcomes being sort. The method of stakeholder reduction used
in this thesis is supported by Parent and Deephouse (2007) who suggest stakeholder listings
need to have a level of relevance in terms of their power, legitimacy and urgency. This enables
the project manager to refine the many potential stakeholders into a smaller more relevant
listing and then apply a suitable level of management effort appropriate for the project being
managed.
The stakeholder identification and needs analysis started off in hypothetical terms and
considered the most likely and obvious requirements of all stakeholders according to the
PASTLE model. A preliminary ranking assessment performed without any actual stakeholder
interviews being conducted reduced the potential stakeholder list down to internal
stakeholders categorised according to organisational functional hierarchical structures. This
type of reduction seemed logical given the size and scale of the projects under consideration
and is also supported by Parent and Deephouse (2007), who suggest that a stakeholders
identification process can be structured along hierarchical levels to identify the most salient
stakeholders for the level of management being assessed. The correlation to hierarchy can be
explained by the analogy that a significant project having the potential to influence powerful
stakeholders such as nations or governments would be interested in the needs and
requirements of equally powerful stakeholders (Parent & Deephouse 2007). Given the level
and type of projects being assessed in this research and considering the power, urgency and
legitimacy of the stakeholder’s influence over the projects it was determined that an internal
stakeholder group would be the most suitable for the level of research being conducted.
The stakeholder engagement process started with the most powerful and influential
stakeholders suitable for the level of projects being studied. This group of stakeholders
included the senior functional managers within the organisation from multiple manufacturing
plants. During the course of the internal stakeholder engagement process it was observed that
the requirements of the more senior positions within the organisational structure tended to be
very broad motherhood type statements that are too intangible to effectively define within an
ERP system (e.g. “Deliver business benefit over the whole of asset life”). The superior level

35
stakeholder requirements contrasted with the lower levels of the organisational structure
where the stakeholder requirements tended to be more specific and tangible (e.g. “All
procurements for materials purchased from the system catalogue to retain procurement
history”). Being more tangible, the lower level requirements are easily controlled through the
ERP system because they can be directly related to a business process and compliance in
following the business process can be measured.
The observed difference in requirement levels is consistent with organisational management
principals of cascading objectives (Robbins 2000, p.260). The more senior organisational roles
are visionary concentrating on strategic organisational goals, whereas subordinate roles are
more tactical and interested in operational goals (Davidson, Griffin & French 2003, p.215). It
then stands to reason that if the organisation has successful human resources strategies in
place, the organisation’s people objectives will be aligned with the broader organisational
objectives and then if the subordinate operational goals are successfully achieved the higher
level organisational goals will also be achieved (Stone 1998, p.20).
For internal projects within a corporate environment the observed data indicates that project
stakeholder needs and requirements can be aligned along the organisational functional
hierarchy structure. A correlation can then be drawn that by satisfying the more tangible
lower level needs and requirements should also mean that the higher level needs and
requirements can also be satisfied (Davidson, Griffin & French 2003; Robbins 2000; Stone
1998).
Figure 13 – The functional departmentalisation organisational structure can be used to help refine stakeholder
requirements

Can deliver
success here General
Manager

Finance Production Maintenance Projects

Operational Plant Reliability & Construction Project

Procurement Accounts
Area 1 Maintenance integrity Lead Manager

Project Shift Project Project

Purchasing Planner Engineer
accountant supervisor supervisor engineer

Stores Plant Satisfying

Supervisor accountant requirements here

Source: (Parent & Deephouse 2007; Robbins 2000)

In organisations operating a functional departmentalisation structure Davidson, Griffin and
French (2003, p.215) suggest that success at the subordinate levels will deliver results for
superior levels following the hierarchical functional structure. Taking this observation into
consideration the research level of analysis for this thesis was redefined to limit the
stakeholder identification structure to follow the organisational hierarchical structure. This
change provided a more clear systematic understanding of the relationship between the
stakeholder success criteria and how the SAP-PS system can be utilised to monitor and control

36
achievement of the success criteria across all levels within the organisational functional
structure (Agle & Caldwell 1999).

EVALUATION OF SAP-PS AS A MPCS

DIFFERENT APPROACHES TO MPCS

Controlling the softer aspects of project management and coping with multiple objectives is an
essential part of the project manager’s role; however, contemporary project management
methodology provides little suitable and practicable process to assist the project manager in
achieving effective integrated multidimensional project control (Rozenes, Vitner & Spraggett
2004). Many sources reviewed in this study recognise the importance of multidimensional
project control; however, few offer any guidance on how the methodology can be
implemented within an operational environment.
 Meredith (2009) and Nicholas (2004) recognise the importance of measuring project
performance as an additional dimension to the traditional metrics of time and cost but
offer no suggestion on how the various dimensions can be effectively controlled;
 The PMI (2013) support controlling all ten knowledge areas of the PMBOK but do not offer
a fully integrated solution. Westerveld (2003) even suggests that the PMI’s definition of
project management is unclear and makes it difficult to integrate the different control
dimensions;
 Lauras, Marques and Gourc (2010) have stated that there are no effective tools in
existence that aggregate the many project performance metrics into a multidimensional
system. Lauras, Marques and Gourc (2010) propose a methodology that combines the
many project performance dimensions within a multidimensional approach; however, all
sources reviewed indicate that this methodology remains academic and has not been
implemented in practice;
 Rozenes, Vitner and Spraggett (2004) recognise the lack of effective project management
tools that support a multidimensional project control system. Rozenes, Vitner and
Spraggett (2004) suggest a vectorised mathematical model for evaluating multiple project
performance metrics; however, all sources reviewed indicate that this methodology
remains academic and has not been implemented in practice;
Figure 14 – Multidimensional representations of project control

(Meredith 2009; Nicholas 2004) (Rozenes, Vitner & Spraggett 2004)

37
 (Lauras, Marques & Gourc 2010) (PMI 2013)

The lack of effective and practical multidimensional project control methodology and tools is
the focus of this thesis. All of the sources reviewed within this study agree that effective
application of multidimensional project control and practical tools required for the
implementation of MPCS remains underdeveloped. One of the main reasons identified in the
literature review as to why MPCS is underdeveloped is because integrating the many legacy
control systems and many facets of stakeholder success criteria is difficult (Franz 2009).
Projects can produce vast volumes amounts of data and managing the volumes of data while
trying to integrate and control the many stakeholder requirements requires a level computing
sophistication that is not readily available using traditional approaches and systems in project
control (Franz 2009).
Possibly one of the only systems that can achieve the level of data and business integration
needed for MPCS is the corporate ERP system (Franz 2009; Songer, Hays & North 2004). To
investigate into the effectiveness of using SAP-PS as a MPCS the project stakeholder success
criteria identified during the case study were used as control integration dimensions for a
system verification test conducted within a development database running SAP ECC 6.0.
The results from the verification test indicate that the system is very capable of monitoring and
controlling the tangible stakeholder success criteria as well as the traditional iron triangle
metrics of scope, time and cost. From the list of identified stakeholder needs and
requirements one of the most common and significant success criteria remains the traditional
metrics of scope, time, and cost. This observation suggests that for projects the traditional
iron triangle metrics continue to play a key role in measuring project performance for the
project practitioner as well as other key stakeholders who have an invested interest in the
project.
The common stakeholder requirement for performance metrics reported against scope, time
and cost (EV) puts in question the acceptance of MPCS concepts from Rozenes, Vitner and
Spraggett (2004) and Lauras, Marques and Gourc (2010). Both sources propose MPCS
methods where the traditional EV model is replaced by alternative methods for interpreting,
evaluating and displaying project performance. Given the level of reliance the profession of
project management has developed on the key EV metrics it is probable that any alternative

38
project control methodology which displaces EV may not be very well supported by the project
practitioners or other key project stakeholders.
Results from this investigation suggest that the best approach for a successful implementation
of MPCS is to fully satisfy the traditional iron triangle metrics and extend the project control
dimensions to include a framework for the other stakeholder success criteria that go beyond
the traditional EV performance metrics. This finding is supported by several sources including
Toor and Ogunlana (2010), Meredith (2009) and Nicholas (2004). Figure 15 provides a
graphically representation on how the concept of MPCS can incorporate the traditionally iron
triangle metrics as well as the performance metrics required for MPCS.
Figure 15 – Multidimensional project control dimensions incorporating earned value

Source: (Meredith 2009, p.4; Nicholas 2004, p.10; Rozenes, Vitner & Spraggett 2004)

EFFECTIVENESS OF SAP-PS AS A MPCS

The verification test conducted as part of this study has confirmed that the majority of the
stakeholder success criteria identified can be effectively controlled using standard functions in
SAP-PS. The various stakeholder success criteria do however first need to be configured into
the controls structure before they can be effectively controlled. Configuration of control
dimensions is standard practice in traditional project control methodology. The many sources
of project management practice all nominate the process of defining the scope as a work
breakdown structure (WBS) and developing the estimate and schedule against the WBS
packages (PMI 2013). Configuring the WBS, estimate and schedule establishes the project
control structure for earned value measurement (Burke 2007).
As an extension to the traditional EV approach for project control establishment the other
control dimensions that form the multidimensional project control points should also be
planned and configured into the control structure. Rozenes, Vitner and Spraggett (2004)
advocate such an approach by suggesting the control packages can be configured in a Global
Project Control Specifications (GPCS). During this study practical application of Rozenes, Vitner
and Spraggett (2004)’s concept on the GPCS was investigated within the test project by using
the following methodology:

39
Table 9 - Exploring Rozenes, Vitner and Spraggett (2004)’s MPCS concept

A SAP-PS project structure and network was built to conform with a typical project life cycle
and process flow as recommended by many sources including (Burke 2007; PMI 2013;
Rozenes, Vitner & Spraggett 2004).
Figure 16 – Project WBS example following project lifecycle and process flow

Project
Definition

Capital
Expense
Investment

Concept Prefeasibility Feasibility Implementation

Work Work Work Work

package 1 package 3 package 5 package 7

Work Work Work Work

package 2 package 5 package 6 package n

Source: (Burke 2007; PMI 2013; Rozenes, Vitner & Spraggett 2004)

The application of the WBS and GPCS conformed with the Rozenes, Vitner and Spraggett
(2004)’s theory on MPCS. The WBS structure was used for the planning phase and the GPCS
was used for the implementation and controlling phases. The relationship between WBS and
GPCS is graphically represented by the process flow diagram Figure 17.
Figure 17 - WBS and GPCS relationship to project phases

40
The project stakeholder success criteria were broken into Global Project Control Specification
(GPCS) as described by Rozenes, Vitner and Spraggett (2004). The organisational functional
hierarchy structure was used to identify the superior and subordinate levels in the GPCS.
Figure 18 - GPCS concept structure aligned with project stakeholder success

Global Project GPCS

Control System

Level 1 (SUBJECT) e.g. e.g. e.g.

Functional Area Maintenance Operations Finance

Level n (SUBJECT) Functional Functional Functional Functional

Subordinate levels Level Level Level Level

Level m (CWP) Success Success Success Success

Control Work Packages criteria criteria criteria criteria

Source: (Rozenes, Vitner & Spraggett 2004)

41
The GPCS was constructed in an excel spreadsheet with the success criteria assigned as control
packages and the inputs identified and reported out of SAP as being either successful or
unsuccessful.
Figure 19 - GPCS calculations table

Rozenes, Vitner and Spraggett (2004)’s concept on MPCS did not produce expected results and
the line of investigation was abandoned for the following reasons:

 The black box method of testing used in the research limits the level of system
programming available for data verification. The GPCS structure and computations
could not be programmatically developed within SAP-PS so the GPCS structure and
computations were simulated through a Microsoft Excel spreadsheet. Such a
departure in contradictory to one of the key objectives of this thesis in using the ERP
system to displace the many disparate single dimension control systems commonly

42
 used in project management practice. By using a Microsoft Excel spreadsheet as a
MPCS introduces another disparate system into the control structure;
 Rozenes, Vitner and Spraggett (2004)’s suggestion of applying the GPCS methodology
only to the implementation phase contradicts the case study practices in project
control. Within the case study examples the monitoring and controlling process
groups are used for the planning phases of the project (concept, prefeasibility and
feasibility) as well as the implementation phase. It was considered that only
controlling the implementing phase of the project would not deliver maximum benefit
for the project. Many sources support this point by suggesting that changes derived
from the control process outputs duing the project during early project phases yield
maximum benefit for the project. Taking corrective action late in the project will cost
the most and potentially provide least benefit (PMI 2013).
Figure 20 – Cost and benefit of change over project life

Benefit of change Cost of change

Cost / Benefit

CONCEPT
FEASIBILITY
IMPLEMENTATION
CLOSE

Project Time

Source: (Burke 2010; PMI 2013)

 Applying Rozenes, Vitner and Spraggett (2004)’s concepts is a departure from the proven
practice of managing scope through WBS. A departure of this nature may not be well
supported by the project practitioners of other key stakeholders.
DELIVERING BUSINESS BENEFIT
Results from the verification test indicated that the corporate ERP system SAP-PS is effective at
controlling the success criteria originating from the subordinate roles within functional
hierarchy structure because they are more tangible in nature and controllable within a
computerised system. The test results also identified a number of uncontrollable stakeholder
success criteria which originate from the more senior stakeholder roles within functional
hierarchy structure. The uncontrollable success criteria tended to be intangible in nature and
difficult for a computerised project control system to address.
The uncontrollable stakeholder success criteria identified during the test were all stakeholder
requirements based upon controlling the performance of the project’s finished product to
ensure it delivers business benefit for the organisation through to the end of asset life.
Measuring project success past project closure is an area that has been identified by several
sources as being in need of further development. Shenhar et al. (2001) suggests project

43
management is strategically important to organisational performance and the dimensions of
project control should extend to controlling project success criteria after the project has been
delivered and until end of asset life.
Shenhar et al. (2001) and Cooke-Davies (2002) concur that the dimensions of project control
can change through the project life cycle and could extend beyond project close to ensure the
project is delivering business benefit over the whole of asset life. This opinion is contra to the
PMI (2013, p.35) who consider that the project managers responsibility and accountability
finishes at the close of the project when the authorised stakeholders accept the final product.
Figure 21 - Extending MPCS to control business benefit

Source: (Cooke-Davies 2002; Shenhar et al. 2001)

The results from this study indicate that the dimensions of MPCS should extend beyond
project handover. The senior position stakeholders rank business benefit and product
performance highly as key project success criteria. SAP-PS has been demonstrated effective at
controlling many of the stakeholder success criteria during project delivery; however, the
system does not appear to support stakeholder requirements that extend beyond project
handover. Further studies are needed to investigate into the methodology of extending MPCS
beyond the project handover point to help monitor and control project success criteria based
on ensuring the project delivers the promised benefit to the business until the end of product
life.

44
CONCLUSIONS
Monitoring and controlling the work performed on a project is one of the most important
activities in project management and it can be one of the most difficult aspects of a project
manager’s job. Historically project managers have relied on many different and disparate
project control systems and tools developed during the sixties to monitor and control the
separate project management knowledge areas within singular dimensional control systems
that have little or no integration with other business systems or processes. Strategic demands
from business and the development of project management as a profession is driving a
growing trend in project management to look beyond the traditional project control
methodologies and improve on the singular dimensional approaches to project control by
integrating multiple control dimensions with each other and other business systems to form a
fully integrated Multidimensional Project Control System (MPCS).
The literature review conducted in this thesis defines multidimensional project control as
managing projects to deliver success on the traditional metrics of scope, time and cost and
also control the dimensions required to deliver project success for all key project stakeholder.
The issue facing project practitioners and business managers alike is that there currently is a
lack of project management methodology and tools available to help the project managers
control the many dimensions of MPCS within a fully integrated multidimensional business
environment. Issues being faced by project managers trying to implement MPCS include the
problems that projects can produce voluminous amounts of data that is arduous and
expensive to process and legacy project control systems can be difficult to integrate with each
other and other business enterprise systems. The answer to these issues and the key to
project control system integration may lay with the latest generation of Enterprise Resource
Planning (ERP) systems; which are nowadays in common use throughout major global
organisations.
ERP systems have evolved over recent decades helping business’ integrate legacy systems and
processes across intra-organisational boundaries. If ERPs can successfully solve voluminous
data integration issues between functional business areas then they should also be capable of
solving project control system integration issues. The aim of this thesis was to investigate into
the effectiveness of using the corporate ERP system SAP-PS as a multi dimensional project
control system that can be used to monitor and control the work performed on projects, meet
the needs and expectations of the project manager and supports the requirements of other
key stakeholders within the organisation.
To investigate into the effectiveness of using SAP-PS as a MPCS a mixed methodology research
approach was used. A case study was used to collect data on project stakeholder success
criteria and test the effectiveness of using SAP-PS to monitor and control the criteria within a
multidimensional project control framework. The project stakeholder success criteria
identified during the case study were used as control integration dimensions for a system
verification test conducted within a development database running SAP ECC 6.0. The results of
the test were triangulated with the case study results and the literature review on MPCS to
analyse the effectiveness of use SAP-PS as a MPCS.

45
Results from this study indicated that the corporate ERP system SAP-PS can be effective at
monitoring and controlling the majority of the stakeholder success criteria using standard
functions in SAP-PS. It was identified during the test that the system produces the best results
when the control integration points are derived from the tangible stakeholder success criteria
that can be related back to project and business processes which are easily configured and
analysed within a computerised project control system.
Results from the test also identified a range of stakeholder success criteria that the system
failed to effectively monitor and control. Further analysis into the nature of the unsuccessful
results indicated the uncontrollable success criteria typically originate from the more senior
stakeholder positions in the organisational functional hierarchy structure. The analysis
suggests project stakeholder success criteria can be related back to the organisational
management theory of cascading objectives where the more senior roles within an
organisation are focused on objectives that are strategic in nature and the subordinate roles
are more aligned with tactical objectives. In a correlation of results this thesis suggests that
many of the intangible stakeholder success criteria originating from the senior managerial
roles can be satisfied by following the organisational functional hierarchy structure and
developing the control integration points to align with the tactical and more tangible
subordinate stakeholder success criteria.
This study has also identified a range of higher order uncontrollable stakeholder success
criteria. The uncontrollable success criteria originated from stakeholder requirements centred
upon monitoring and controlling the performance of the project’s finished product to ensure it
delivers business benefit for the organisation through to the end of asset life. Controlling
project success past project handover is not generally a common practice within the discipline
of project management. Many proponents for MPCS believe that project management is
strategically important to organisational performance and the dimensions of project control
should extend to controlling project success after the project has been delivered and until end
of product life.
This study has concluded that project success is intrinsically reliant on identifying and
prioritising project stakeholder needs and requirements to define the necessary project
success criteria. From the outset of the project the project manager should be proactively
working with the project stakeholders to identify and manage the project’s key success
criteria. Monitoring and controlling the project success criteria within the corporate ERP
system will then be achievable as long as the success criteria are tangible enough to be
processed within a computerised system. This investigation into the effectiveness or using
SAP-PS as a multidimensional project control system has resolved that within the corporate
environment the use of the enterprise resource planning system as a project planning and
control system is effective and potentially the only system capable of integrating the many
project control dimensions needs to deliver organisational success, project success and
stakeholder satisfaction.

46
RECOMMENDATIONS FOR FURTHER RESEARCH
The recommendations for further research resulting from this study include:
 Extending the concept of MPCS within the corporate ERP system to include the
external stakeholder success dimensions;
 An investigation into the effectiveness of using SAP-PS as a MPCS on large and mega
scale projects with a much greater range of project stakeholder success criteria, such
as in public sector projects;
 Further investigation into applications of MPCS that include the vectorised
mathematical evaluation of project progress performance and forecasting. Rozenes,
Vitner and Spraggett (2004) and Lauras, Marques and Gourc (2010) both propose
MPCS methodologies worthy of further assessment with a view to integrating the
methodology into the corporate ERP system.
 Further investigation is required into practical methods of assess and measuring
project success in terms of how the project is meeting its original business case and
adding value to the business over the whole asset lifecycle. The ERP systems provide
the right environment for this type of assessment because the original project business
case, the project implementation expenditure data and whole of asset life
management information is all contained within the centralised ERP database.

47
REFERENCES
Ackermann, F & Eden, C 2011, 'Strategic Management of Stakeholders: Theory and Practice',
Long Range Planning, vol. 44, no. 3, pp. 179-196.

Agle, BR & Caldwell, CB 1999, 'Understanding research on values in business', Business and
Society, vol. 38, no. 3, Sep 1999, pp. 326-387.

Amaratunga, D, Baldry, D, Sarshar, M & Newton, R 2002, 'Quantitative and qualitative research
in the built environment: application of “mixed” research approach', Work Study, vol. 51, no. 1,
pp. 17-31.

Andera, FJC, Weirich, TR & Worster, AJ 2012, Maximizing Return on Investment Using ERP
Applications, John Wiley & Sons, Hoboken, NJ, USA.

Annamalai, C & Ramayah, T 2011, 'Enterprise resource planning (ERP) benefits survey of Indian
manufacturing firms: An empirical analysis of SAP versus Oracle package', Business Process
Management Journal, vol. 17, no. 3, pp. 495-509.

Argyropoulou, M, Ioannou, G, Koufopoulos, DN & Motwani, J 2011, The 'Six Imperatives'

Framework for the evaluation of an ERP Project, SAGE Publications India Pvt Ltd, New Delhi,
India
Thousand Oaks, Calif, pp. 161-176.

Atkinson, R 1999, 'Project management: cost, time and quality, two best guesses and a
phenomenon, its time to accept other success criteria', International Journal of Project
Management, vol. 17, no. 6, 12//, pp. 337-342.

Bendoly, E, Kumar, S & Esteves, J 2011, Handbook of research in enterprise systems, SAGE
Publications India Pvt Ltd, New Delhi, India
Thousand Oaks, Calif.

Besner, C & Hobbs, B 2008, 'Project management practice, generic or contextual: A reality
check', Project Management Journal, vol. 39, no. 1, pp. 16-33.

Borrego, M, Douglas, EP & Amelink, CT 2009, 'Quantitative, Qualitative, and Mixed Research
Methods in Engineering Education', Journal of Engineering Education, vol. 98, no. 1, pp. 53-66.

Bradley, G 2010, Benefit Realisation Management : A Practical Guide to Achieving Benefits

Through Change (2nd Edition), Ashgate Publishing Ltd, Farnham, Surrey, GBR.

Brady, JA, Monk, EF & Wagner, BJ 2001, Concepts in enterprise resource planning, Course
Technology, Great Britain :.

Budd, CI & Budd, CS 2010, A Practical Guide to Earned Value Project Management,
Management Concepts, Vienna, VA.

Burke, R 2007, Project management techniques, College ed. edn, Burke Publishing, United
States.

1
Burke, R 2010, Fundamentals of project management : tools and techniques, Burke Publishing,
Ringwood.

Cheung, KKW, Cheung, SO & Suen, HCH 2004, 'PPMS: a Web-based construction Project
Performance Monitoring System', Automation in Construction, vol. 13, no. 3, pp. 361-376.

Cooke-Davies, T 2002, 'The “real” success factors on projects', International Journal of Project
Management, vol. 20, no. 3, 4//, pp. 185-190.

Cooper, KG 2003, Your Project's Real Price Tag, Harvard Business School Publication Corp., pp.
122-122.

Copeland, L 2004, A practitioner's guide to software test design, Artech House, Boston, Mass. ;
London
Norwood.

Darrell, V, Baccarini, D & Love, PED 2010, 'Demystifying the folklore of the accidental project
manager in the public sector', Project Management Journal, vol. 41, no. 5, pp. 56-63.

Davidson, P, Griffin, RW & French, E 2003, Management : an Australasian perspective, 2nd

edn, John Wiley & Sons, Milton, Qld.

de Falco, M & Macchiaroli, R 1998, 'Timing of control activities in project planning',

International Journal of Project Management, vol. 16, no. 1, pp. 51-58.

De Marco, A & Narbaev, T 2013, 'Earned value-based performance monitoring of facility

construction projects', Journal of Facilities Management, vol. 11, no. 1, pp. 69-80.

Deng, MZM & Hung, YF 1998, 'Integrated cost and schedule control: Hong Kong perspective',
Project Management Journal, vol. 29, no. 4, p. 43.

Dowling, K 2008, SAP® Project System Handbook, McGraw-Hill Osborne Media, United States.

Dweiri, FT & Kablan, MM 2006, 'Using fuzzy decision making for the evaluation of the project
management internal efficiency', Decision Support Systems, vol. 42, no. 2, 11//, pp. 712-726.

Essex, DE 2005, 'SPREADING THE PORTFOLIO MANAGEMENT MANTRA', PM Network, vol. 19,
no. 12, p. 62.

Evans, DG, Gruba, P & Zobel, J 2011, How to write a better thesis, 3rd edn, Melbourne
University Press, Carlton, Vic.

Fleming, QW & Koppelman, JM 1999, 'The earned value body of knowledge', in Koppelman, JM
(ed), PMI '99 proceedings of the annual Project Management Institute : 1999 seminars &
symposium : 10-12 October 1999, Philadelphia, Pennsylvania, USA, PMI, Newtown Square, Pa.

Fleming, QW & Koppelman, JM 2003, 'What's your project's real price tag?', Harvard Business
Review, vol. 81, no. 9, p. 20.

Fleming, QW & Koppelman, JM 2007, 'Implementing Earned-Value Project Management in Ten

Easy Steps', Field Guide to Project Management, John Wiley & Sons, Inc., pp. 521-539.

2
Fleming, QW & Koppelman, JM 2010, 'Earned Value Project Management-Fourth Edition', PM
Network, vol. 24, no. 12, p. 69.

Franz, M 2009, Project Management with SAP Project System, SAP Press, US.

Freeman, H 2002, 'Software testing', Instrumentation & Measurement Magazine, IEEE, vol. 5,
no. 3, pp. 48-50.

Geraldi, J & Lechter, T 2012, 'Gantt charts revisited', International Journal of Managing Projects
in Business, vol. 5, no. 4, pp. 578-594.

Gupta, S 2008, 'EARNED VALUE MANAGEMENT CLOGS PROFITS', Industrial Management, vol.
50, no. 3, pp. 12-16,15.

Henderson, H 2009, Encyclopedia of Computer Science and Technology, Facts On File, New
York.

Jepsen, AL & Eskerod, P 2013, Project stakeholder management, New edition edn, Gower,
Burlington, VT :.

Khan, ME & Khan, F 2012, 'A Comparative Study of White Box, Black Box and Grey Box Testing
Techniques', International Journal of Advanced Computer Sciences and Applications, vol. 3, no.
6, p. 12.

Kim, S, Son, J, Park, C & Lee, S 2008, 'Integrated cost and schedule control in the Korean
construction industry based on a modified work-packaging model', Canadian Journal of Civil
Engineering, vol. 35, no. 3, pp. 225-235.

Lau, LK 2005a, 'An Overview of SAP Technology', Managing Business with SAP: Planning
Implementation and Evaluation, IGI Global, pp. 33-43.

Lau, LK 2005b, Managing Business with SAP : Planning, Implementation and Evaluation, Idea
Group Pub, Hershey, PA.

Lauras, M, Marques, G & Gourc, D 2010, 'Towards a multi-dimensional project Performance

Measurement System', Decision Support Systems, vol. 48, no. 2, pp. 342-353.

Leimbach, T 2008, 'The SAP Story: Evolution of SAP within the German Software Industry',
Annals of the History of Computing, IEEE, vol. 30, no. 4, pp. 60-76.

Lipke, W, Zwikael, O, Henderson, H & Anbari, F 2009, 'Prediction of project outcome: The
application of statistical methods to earned value management and earned schedule
performance indexes', International Journal of Project Management, vol. 27, no. 4, p. 400.

Loonam, J & McDonagh, J 2005, 'Principles, Foundations & Issues in Enterprise Systems',
Managing Business with SAP: Planning Implementation and Evaluation, IGI Global, pp. 1-32.

Lukas, JA 2008, 'Earned Value Analysis - Why it Doesn't Work', AACE International
Transactions, pp. EV11-EV19,EV110.

Maley, CH 2012, 'Project Initiation', ESI International Project Management: Project

Management Concepts, Methods, and Techniques, CRC Press, p. 462.

3
Mantel, SJ, Meredith, JR, Shafer, SM & Sutton, MM 2005, 'The world of project management',
in Mantel, SJ (ed), Project management in practice, 2nd ed. edn, John Wiley & Sons, Hoboken,
NJ :, pp. 1-37.

McAfee, A 2002, 'The Impact of Enterprise Information Technology Adoption on Operational

Performance: An Empirical Investigation', Production & Operations Management, vol. 11, no.
1, Spring2002, pp. 33-53.

Meredith, JR 2009, Project management : a managerial approach, 7th edn, Wiley ; John Wiley
[distributor], Hoboken, N.J. : Chichester.

Modi, SB & Mabert, VA 2011, 'The Enterprise Systems Industry Landscape', in Bendoly, E,
Kumar, S & Esteves, J (eds), Handbook of research in enterprise systems, SAGE Publications
India Pvt Ltd, New Delhi, India
Thousand Oaks, Calif, p. 323.

Moszkiewicz, J & Rostek, K 2011, 'Functional Enhancements to Project Management

Information Systems', Foundations of Management, vol. 3, no. 1, pp. 47-66.

Munier, N 2013, 'Project Monitoring and Project Control', Project management for
environmental, construction and manufacturing engineers a manual for putting theory into
practice, Dordrecht, Springer Netherlands.

Naeni, LM, Shadrokh, S & Salehipour, A 2011, 'A fuzzy approach for the earned value
management', International Journal of Project Management, vol. 29, no. 6, pp. 764-772.

Nicholas, JM 2004, Project Management for Business and Engineering : Principles and Practice,
Taylor & Francis, Burlington,

Niebecker, K, Eager, D & Kubitza, K 2008, 'Improving cross-company project management

performance with a collaborative project scorecard', International Journal of Managing
Projects in Business, vol. 1, no. 3, pp. 368-386.

O'Connor, JT & Dodd, SC 2000, 'Achieving integration on capital projects with enterprise
resource planning systems', Automation in Construction, vol. 9, no. 5, pp. 515-524.

O'Leary, Z 2004, The Essential Guide to Doing Research, Sage Publications Ltd., London,

Oracle 2008, Oracle Buys Primavera: Creates First, Comprehensive Enterprise Project Portfolio
Management Solution for Project-Intensive Industries, Oracle, viewed 02/07/2013,
<www.oracle.com/us/corporate/press/017594_EN>.

Parent, MM & Deephouse, DL 2007, 'A Case Study of Stakeholder Identification and
Prioritization by Managers', Journal of Business Ethics, vol. 75, no. 1, 2007/09/01, pp. 1-23.

PMI 2013, A guide to the project management body of knowledge (PMBOK guide) - Fifth
Edition, 4th ed. edn, Project Management Institute, Inc, Newtown Square, Pa.

Rhodes, J, Bergstrom, B, Lok, P & Cheng, V 2014, 'A framework for stakeholder engagement
and sustainable development in MNCs', Journal of Global Responsibility, vol. 5, no. 1, pp. 82-
103.

4
Robbins, SP 2000, Management, 2nd edn, Prentice Hall Australia, New York ; Sydney.

Robert Jacobs, F & ‘Ted’ Weston Jr, FC 2007, 'Enterprise resource planning (ERP)—A brief
history', Journal of Operations Management, vol. 25, no. 2, 3//, pp. 357-363.

Rozenes, S, Vitner, G & Spraggett, S 2004, 'MPCS: Multidimensional Project Control System',
International Journal of Project Management, vol. 22, no. 2, pp. 109-118.

Rozenes, S, Vitner, G & Spraggett, S 2006, 'PROJECT CONTROL: LITERATURE REVIEW', Project
Management Journal, vol. 37, no. 4, pp. 5-14.

SAP 2013, SAP Project System Wiki, SAP promotional website for SAP-PS, updated 03/04/2013,
SAP, viewed 10/05/2013, <http://wiki.scn.sap.com/wiki/display/ESpackages/Project+System>.

Shenhar, AJ, Dvir, D, Levy, O & Maltz, AC 2001, 'Project Success: A Multidimensional Strategic
Concept', Long Range Planning, vol. 34, no. 6, 12//, pp. 699-725.

Songer, AD, Hays, B & North, C 2004, 'Multidimensional visualization of project control data',
Construction Innovation, vol. 4, no. 3, p. 173.

Stone, RJ 1998, Human resource management, 3rd edn, John Wiley &amp; Sons, Milton, Qld.

Taylor, J 2008, Project Scheduling and Cost Control : Planning, Monitoring and Controlling the
Baseline, J. Ross Pub, Ft. Lauderdale, Fla.

Toor, S-u-R & Ogunlana, SO 2010, 'Beyond the ‘iron triangle’: Stakeholder perception of key
performance indicators (KPIs) for large-scale public sector development projects', International
Journal of Project Management, vol. 28, no. 3, 4//, pp. 228-236.

Totin, CM 2012, Effective construction schedule management: Construction project monitoring

with Project Performance Indicators & the Project Status Report, ProQuest, UMI Dissertations
Publishing,

Vanhoucke, M 2009, 'Conclusions', Measuring Time, vol. 136, Springer US, pp. 149-155.

Vanhoucke, M 2012a, 'Earned Value Management', Project Management with Dynamic

Scheduling, Springer Berlin Heidelberg, pp. 215-238.

Vanhoucke, M 2012b, 'Measuring the efficiency of project control using fictitious and empirical
project data', International Journal of Project Management, vol. 30, no. 2, pp. 252-263.

Westerveld, E 2003, 'The Project Excellence Model®: linking success criteria and critical success
factors', International Journal of Project Management, vol. 21, no. 6, 8//, pp. 411-418.

Yang, C & Su, Y-f 2009, 'The relationship between benefits of ERP systems implementation and
its impacts on firm performance of SCM', Journal of Enterprise Information Management, vol.
22, no. 6, 2009, pp. 722-752.

Zikmund, WG 2013, Business research methods, 9th edn, South-Western, Cengage Learning,
Mason, OH.

5
6
Appendix A Research Information Sheet

1
Appendix B Ethics Consent Form

2
Appendix C Permission Request to Undertake
Research

3
 Appendix D Stakeholder Meeting invitation Email

Hi xxxx
As we discussed previously I am currently undertaking a research thesis to investigate the
effectiveness of using SAP-PS as a multidimensional project control system that can be used to
monitor and control the work performed on projects, meet the needs and expectations of the
project manager and supports the requirements of other key stakeholders within the
organisation.
I have identified your role as a key project stakeholder and if you are interested I would like to
discuss your stakeholder needs and requirements. I have 5 questions to ask you and your
responses will be used to help develop project success criteria.
If you accept, the discussion/interview will last a maximum of 30 minutes. All information
recorded will be non-identifiable.
I have included an information sheet that explains the purpose and process of this research.
If you do not wish to be involved in this research please decline this invitation. If you have any
further questions please contact me
Thank you for your interest
Brett Machen

Information Sheet - BRETT MACHEN 110047071.pdf

4
 Appendix E Stakeholder Questionnaire Form

STAKEHOLDER REQUIREMENT RESPONSE

PROJECT: MPM515 Project Management Minor Thesis 2
An investigation into the effectiveness of using SAP-PS as a multidimensional
project control system

Stakeholder Category Stakeholder (Individual or group)

Q1. What are your likely expectations of the projects?

Response:

Q2. What do you see as being your key measurable requirements during project
execution (project success factor)?

Response:

5
Q3. What role would you wish to hold during the projects?

Response:

Q4. What benefit would you normally expect to see from the projects?

Response:

Q5. What negative impacts might there be from the projects?

Response:

6
 Appendix F Stakeholder Requirements Listing

STAKEHOLDER REQUIREMENT LISTING

PROJECT: An investigation into the effectiveness of using SAP-PS as a multidimensional project control system
Stakeholder functional Stakeholder Identified Requirement Power Interest Success
division (Individual or group) Factor
(Sf)
Engineering Engineering Manager Engineering resources working on individual projects 4 5 0.8
planned effectively
Engineering Engineering Manager Control of resource utilisation on projects 4 5 0.8
Engineering Engineering Manager Accurate engineering estimates planned in packages 4 5 0.8
and then executed according to plan
Engineering Engineering Manager Project work scope effectively communicated to 4 5 0.8
engineering work team
Engineering Engineering Manager Visibility of all hours worked within projects. Control of 4 5 0.8
actual hours worked against planned
Finance Purchasing Officer All procurements effectively planned 2 5 0.4
Finance Purchasing Officer Minimised rework on purchase orders 2 5 0.4
Finance Purchasing Officer Requisition transparency 2 5 0.4
Finance Purchasing Officer Stores must goods receipt all components (no services 2 5 0.4
used to purchase components)
Finance Purchasing Officer Materials master data used strategically to deliver 2 5 0.4
maximised value for the business
Finance Purchasing Officer Detailed requisitions itemised with quotations attached 2 3 0.24
Finance Purchasing Officer Materials Master delivering value by maintaining 2 3 0.24
purchasing history
Finance Purchasing Officer Technical procurements to remain with engineers 2 1 0.08
Finance Finance Manager Accurate materials catalogue 4 5 0.8

1
Finance Finance Manager Capitalised asset register 4 5 0.8
Finance Finance Manager Visibility on all project expenditure (No hidden stock) 4 5 0.8
Finance Finance Manager Components procured through materials catalogue 4 5 0.8
Finance Finance Manager Budget respected. Time and cost 4 4 0.64
Finance Finance Manager Good schedule, budget, estimate control 4 4 0.64
Finance Finance Manager Accurate stock valuation 4 4 0.64
Finance Accountant Budget is respected 3 4 0.48
Finance Accountant Planned project commitments. Control on committed 3 4 0.48
costs should be managed in accordance with business
needs i.e. deferred or accelerated depending in
response to business cash flow needs
Finance Accountant Project post implementation review carried out to 3 3.5 0.42
measure project effectiveness. This review should
occur periodically over the whole of asset life.
Finance Finance Manager Project delivers benefit over whole of project life. 4 3 0.48
Project exists beyond implementation. Project needs to
be assessed for benefit delivery until end of asset life.
Finance Accountant Project expenses minimised. Project is progressed as 3 3 0.36
efficiently as possible into the capital phase.
Finance Accountant Project capital expenditure minimised. Project total 3 3 0.36
capital costs delivered as efficiently as possible. Asset
depreciation reduces production efficiency ratio
Finance Finance Manager Project adds value to the business according to original 4 2.5 0.4
promise (e.g. productivity, safety, regulatory)
Finance Accountant High level of control over project finance. Hard budget 3 3 0.36
controls. Notifications of potential overspend.
Forecasting accuracy
Finance Accountant Capital cannot be spent before approval 3 3 0.36
Finance Accountant Project needs to deliver expected results. Delivered 3 3 0.36
according to original idea.

2
Finance Finance Manager Project efficiency. 40hrs of work delivers 40hrs of 4 2 0.32
benefit
Finance Finance Manager Maximised business benefit and profitability 4 2 0.32
Finance Accountant Project commitments planned into the future 3 2 0.24
Finance Accountant Investment delivered in accordance with NPV. Asset 3 2 0.24
delivers results for the business as expected.
Finance Accountant Project scope delivered. Effective scope management. 3 2 0.24
Plant Maintenance Manager Delivering a platform to support financial transparency, 4 2 0.32
Maintenance timely and accurate reporting, customer centricity and
manufacturing excellence
Plant Maintenance Manager Turn around and outage integration. Clear visibility 4 5 0.8
Maintenance through the plant maintenance system on all projects
being executed within scheduled plant maintenance
turnaround and shutdowns
Plant Maintenance Manager All project components procured through the material 4 4 0.64
Maintenance catalogue linked to plant functional location and
equipment
Plant Maintenance Manager All maintenance strategies and spares in place before 4 5 0.8
Maintenance project commissioning
Plant Maintenance Manager Project components procured through the maintenance 4 3 0.48
Maintenance process to ensure adherence to engineering
specifications to ensure materials are procured based
on asset life cycle and master data is created before
requisitions are raised
Plant Maintenance Manager Supports the use of standardised equipment across the 4 2 0.32
Maintenance site and business (common spares)
Plant Maintenance Manager Maintains an accurate spare parts catalogue and store 4 3 0.48
Maintenance stock (right time and right place)

3
Plant Maintenance Manager Supports maintenance and reliability data by ensuring 4 2 0.32
Maintenance all equipment installed has accurate lifecycle costing
and operation history
Plant Maintenance Manager All plant maintenance resources required for project 4 4 0.64
Maintenance purposes must be planned and scheduled through the
PM system (maintenance resources, reliability
engineering, maintenance asset planning)
Plant Maintenance Manager All equipment is established and planned in SAP in 4 2 0.32
Maintenance parallel to project process (not after) and ready prior to
commissioning.
Plant Maintenance Manager All project handover documentation is available and 4 4 0.64
Maintenance accessible in the maintenance system prior to
commissioning.
Plant Maintenance Planner Centralised procurements to add value for the business 2 5 0.4
Maintenance
Plant Maintenance Planner Systems drives accurate procurement planning 2 5 0.4
Maintenance
Plant Reliability Engineer Maintenance strategy in place for all engineering 2 5 0.4
Maintenance materials
Plant Reliability Engineer Engineering materials procured to maximised common 2 5 0.4
Maintenance spares
Plant Maintenance Planner Master data updated before procurement occurs 2 4 0.32
Maintenance
Plant Maintenance Planner Maintenance strategy in place before project goes 2 5 0.4
Maintenance online
Plant Maintenance Planner When material is delivered all requirements are in place 2 3 0.24
Maintenance and ready for operation
Plant Reliability Engineer Accurate spare parts catalogue and store stock (right 2 3 0.24
Maintenance time and right place)
Plant Maintenance Reliability Engineer Materials with selection options 2 3 0.24

4
Plant Maintenance Reliability Engineer Standardisation across the plant for engineering 2 3 0.24
materials
Plant Maintenance Reliability Engineer Materials have accurate life cycle cost 2 3 0.24
Plant Maintenance Maintenance Planner Engineers responsible for engineering spares 2 2 0.16
Plant Maintenance Reliability Engineer Material master data created before requisitions raised 2 2 0.16
Production Operations Manager Cost value ration of projects is too high. 4 2 0.32
Production Operations Manager Estimating to liberal, too much contingency on original 4 5 0.8
estimate
Production Operations Manager Confidence on first run estimate low. When ever an 4 2 0.32
estimate is delivered there always seems room to
reduce the estimate. Why isn't the best price proposed
the first time
Production Operations Manager Warranty period on projects group 4 5 0.8
Production Operations Manager Efficiency in delivery during the expenses portion. This 4 5 0.8
cost is immediate and comes off the bottom line.
Production Operations Manager Efficiency in delivery during the capital portion. This 4 5 0.8
cost is depreciated and increases production's cost per
tonne ration
Production Operations Manager Project delivered on time and cost 4 4 0.64
Production Operations Manager Original criteria / idea delivered 4 4 0.64
Production Operations Manager Project efficiency, especially during concept - 4 4 0.64
prefeasibility phase. Efficiency in cost and reaching
promised timeframe
Production Operations Manager Material master fully completed before project is 4 4 0.64
delivered
Production Superintendent All operators trained before project goes on line 3 5 0.6
Production Superintendent All Mods processed effectively and completed 3 5 0.6
Production Superintendent All safety requirements completed. Full compliance 3 5 0.6
with site safety management plan (e.g. permit to work)
Production Superintendent Owners representatives kept fully informed 3 5 0.6

5
Production Superintendent Perform the role of commissioning manager 3 5 0.6
Production Operations Manager Construction, implementation and training delivered 4 3 0.48
efficiently
Production Operations Manager Projects delivers promised productivity improvements 4 3 0.48
Production Operations Manager Project product is fit for purpose 4 3 0.48
Production Superintendent OEM operating documents available and loaded into 3 4 0.48
system as part of operational readiness
Production Superintendent Personnel informed of project prior to implementation 3 3 0.36
Production Superintendent Smooth process of communication. Effective 3 3 0.36
communication for all stakeholders. Including
operators
Production Superintendent Perform the role of implementation manager 3 3 0.36
Production Superintendent Project delivered as a whole. Completeness 3 2.5 0.3
Production Superintendent Ensure adequate resources are available to perform the 3 2 0.24
project. Project should not be held up by lack of
resources
Production Superintendent Project delivered in accordance with original criteria. 3 2 0.24
Original idea and requirements full satisfied
Project delivers promised improvements
Programme Programme Manager Project process flow correctly followed 4 5 0.8
Programme Programme Manager Schedule, budget and resources effectively planned and 4 5 0.8
managed
Programme Programme Manager Single source of information used "One truth" Projects 4 4 0.64
planned and executed in SAP
Programme Programme Manager Projects planned and executed down to the package 4 4 0.64
level
Programme Project Manager Effective time, scope and cost control 3 5 0.6
Programme Project Manager Project product functions according to original criteria 3 5 0.6
Programme Project Manager Meeting stakeholder success criteria 3 5 0.6

6
Programme Project Manager Clear expectation around iron triangle Time- Cost - 3 5 0.6
Scope
Programme Project Manager Clear timing of critical milestones (non-project) e.g. 3 5 0.6
shutdown timing
Programme Project Manager Project planned. Accurate project forecasts 3 5 0.6
Programme Project Manager Easy effective tools for project planning, monitoring and 3 5 0.6
control.
Programme Programme Manager Stakeholder needs and requirements effectively 4 5 0.8
identified and managed
Programme Project Manager Clear KPIs identified at start of the project. Stakeholder 3 4 0.48
success criteria clearly identified
Programme Project Manager Right option selection during front end loading options 3 4 0.48
analysis
Programme Project Engineer Deliver project to stakeholder expectation 2 5 0.4
Programme Project Engineer Ensure customer is happy with project product 2 5 0.4
Programme Project Engineer Meeting minutes approvals. Ensure all mods are 2 5 0.4
approved and signed off prior to implementation
Programme Project Engineer Mods design and process needs to start as early as 2 5 0.4
possible and continue upto implementation.
Programme Project Engineer System simplifies procurement process 2 5 0.4
Programme Project Manager Project quality control. 3 3 0.36
Programme Project Manager Effectively management of people and process 3 3 0.36
Programme Project Manager Clear end date. This helps to motivate project 3 3 0.36
personnel
Programme Project Manager Being able to identify when urgency is required 3 3 0.36
Programme Project Manager Being ready to take advantage of good business 3 3 0.36
environment to realise best opportunity and business
benefit
Programme Project Manager Clear delivery milestones. Project gates clear 3 2.5 0.3
Programme Project Engineer Cost Time & Scope 2 3 0.24

7
Programme Project Engineer Clearance from project owner - Design criteria 2 3 0.24
established prior to commencement of project.
Programme Project Engineer Measure success for meeting design criteria 2 3 0.24
Programme Project Engineer Maintaining trust amongst all stakeholders 2 3 0.24
Programme Project Engineer Ability to procure bulk materials and deliver to 2 3 0.24
contractors
Programme Project Manager Delivery of business benefit - Production, maintenance, 3 2 0.24
operation
Programme Project Manager Brown fields integration. 3 2 0.24
Programme Project Manager Delivering business benefit. Cost benefit ration high 3 2 0.24
Programme Project Engineer Systems provides accurate and easy material master 2 2 0.16
Programme Project Engineer Stores accurately receive all goods into store 2 2 0.16
Programme Project Manager Project delivers value for the business - Business benefit 3 1 0.12
Programme Project Engineer Project practitioners have trust and confidence in stores 2 1 0.08
Programme Project Engineer Materials master data has accurate lead time for 2 1 0.08
procurements

8
 Appendix G SAP-PS Test Script

No. Stakeholder Requirements Success SAP Tx Input Expected Actual

Factor Code
Programme
Programme Manager
1 Project process flow correctly followed Project scope in WBS form Project process flow that represents the
Project lifecycle defined project lifecycle translated into a WBS
structure.
CONCEPT => PREFEASIBILITY => FEASIBILITY
=> IMPLEMENTATION

0.8 1 CN41N

Project lifecycle translated into WBS structure. WBS’ released was project progress through
lifecycle phase gates. This process mandates compliance with stakeholder requirement.

2 Schedule, budget and resources effectively Project estimate translated into Project estimate converted represented in
planned and managed project cost plan. Network activities SAP as a cost plan within each activity rolled
schedule. On project release budget op to WBS. All activities scheduled.
= cost plan = estimate Budget assigned according to project plan

CJ20N
0.8 1
CN41N

Project scheduled in SAP-PS down to activity level

1

3 Single source of information used "One
truth" Projects planned and executed in
0.64
SAP
4 Projects planned and executed down to
0.64
the package level
5 Stakeholder needs and requirements
effectively identified and managed
0.8
Project Manager
6 Effective time, scope and cost control
SAP-PS used as single point of all
project control data
0
Project scope represented in WBS
1 Same as requirement No. 1
structure and network activities
List of stakeholder requirements
with success factors and
0
achievement indicator
Project management dashboard
displaying project key metrics (scope
WBS, schedule, costs)
There are no requirements for additional
disparate control systems outside of SAP-PS.
Data entered once in SAP
Stakeholder identification and needs
analysis. Stakeholder management plan
Portfolio dash board displaying key project
management metrics
All activities with planned durations, costs, and schedule logic. This becomes the project cost
plan. At time of releasing the budget the project cost plan can be copied to the budget which
is assigned at WBS level.
SAP-PS goes a long way to providing a single project control system; however there are still
systems in use that cannot be fully satisfied by SAP-PS. Within the case study example
necessary disparate systems include: Document Management, Change Management,
Engineering Standards, and many other registers.
Stakeholder requirements listing are not represented in SAP. Stakeholder management plan
remains a disparate control system that exists outside of SAP-PS. SAP-PS can be used to
deliver on the individual success criteria; however, integrating the stakeholder register within
SAP-PS is an area that requires further research.

0.6 1 CN41N

 Single point display for whole portfolio or select specific project groups
 All projects displayed as either rolled up portfolio list or expanded for individual

2

7 Project product functions according to
original criteria
9 Clear expectation around iron triangle
Time- Cost - Scope
10 Clear timing of critical milestones (non-
project) e.g. shutdown timing
0.6 0 Not a function able to be performed in SAP-PS. This is an area requiring further research.
Project management dashboard
0.6 1 CN41N displaying project key metrics (scope
WBS, schedule, costs)
Plant maintenance workorder linked
to shutdown maintenance schedule.
Maintenance schedule maintained
by maintenance planner
detail
 All live project scope, time and cost information accessed from single interface
Same as requirement No. 6
Maintenance planner creates shutdown
plan and assigns a revision code (Tx OIOB).
Maintenance workorder linked to shutdown
plan revision.

Workorder dates drive project schedule

CN41N
0.6 1 IW32
OIOB
 Project schedule activity linked to plant maintenance work order
 Workorder has a revision date assigned by maintenance planner. Workorder is
the driver for project activity. Project schedule will change according to plant
maintenance shutdown plan. When maintenance planner changes revision date
project schedule is also changed
 This logic can be applied to other critical milestone throughout the organisation
11 Project planned. Accurate project Project management dashboard
CN41N
forecasts 0.6 1 displaying project key metrics (scope Same as requirement No. 2
CJ20N
WBS, schedule, costs).
12 Easy effective tools for project planning, Project builder interface for creating
CJ20N
monitoring and control. and changing projects. Upload and
0.6 1 OpenP Same as requirement No. 6
download from Microsoft Projects
S
for easy scheduling options
14 Clear KPIs identified at start of the project.
Stakeholder success criteria clearly 0.48 0 Not a function able to be performed in SAP-PS. This is an area requiring further research.
identified
Project Engineer
17 Meeting minutes approvals. Ensure all Documents attached to project Documents attached where approval status
mods are approved and signed off prior to objects (WBS or network activities) can be monitored and controlled
implementation

CJ20N
0.4 1
CV01N

 All project documentation linked to project DMS. Documents can reside

3

18 Mods design and process needs to start as
early as possible and continue up to
implementation.
19 System simplifies procurement process
internally within SAP or linked via URL to external sources. This allows the status
of the documentation to be monitored and reported through CN41N
Activity created during early project MODS approvals linked through document  Project structured so the document object is created in the early project phases
0.4 1 CJ20N life phase. Physical completion of management system of the project. Document status monitored
activity monitored
Interface for planning and raising Object orientated drag and drop
procurements environment that guides requisitioner
through the procurement process and
meditates necessary fields.

CN22
0.4 1
CJ20N

 Drag and drop function for procurements

 Easy interface with predefined and mandatory field guide user through the
procurements process
 Visual display of all items ordered, received or waiting not delivered
Finance

4
 Finance Manager
20 Accurate materials catalogue Materials catalogue available for Components available from materials
purchasing catalogue

CN22
0.8 1
CJ20N

 Procurement of stores stock materials available from catalogue

 Option to purchase non-stock items
 Visual display of all procured items through project dashboard
 Project manager can easily determine if project’s bill of materials has been
procured according to staleholder’s requirements
21 Capitalised asset register All costs from project settling into All project costs settle into asset register  SAP-PS integration with investment management module is standard feature;
asset under construction object
 Assets Under Construction (AUC) balance sheet object automatically created
before capitalisation. Accurate data
AS03 when project is released. By using the correct project structure costs can be
available for audit process of final
0.8 1 CJ20N directly settled from WBS into corresponding AUC;
asset
CJ74
 Follow the prescribed process creates an audit trail from lowest level cost
element back to final asset.
22 Visibility on all project expenditure (No CN41N Accurate list of all components All project procurements visible
0.8 1
hidden stock) CJI3 procured through the project.

5
  Visual display through project management dashboard CN41N
 Detailed listing through transaction report CJI3
 All information immediately available when transaction occurs.
 Single point of data entry, visible to all stakeholders;
23 Components procured through materials CN22 Materials catalogue available for Material selection from stores catalogue.
catalogue 0.8 1 CJ20N purchasing All components related back to site asset
IH01 and functional location

6
  Stores catalogue available for procurements
 All equipment, components and BOMs linked back to functional location
24 Budget respected. Time and cost Budget developed from approved Budget assigned to project from investment  Project budget is protected from overspend through a system control termed
CJ02
0.64 1 project plan management module availability control. Project expenditure cannot exceed budget
CJBV
Budget protected by hard controls
25 Good schedule, budget, estimate control Project management dashboard
CJ20N
0.64 1 displaying project key metrics (scope Same as requirement No. 4
CN41N
WBS, schedule, costs)
26 Accurate stock valuation Procurement of components either Stock items procured through material  If components are procured as item category L they will be assigned a stock valuation
non-stock or stock items component. and when receive the stock will be posted to the correct location;
CN22
0.64 1
CJ20N  This feature is however not available if the component is procured as item category N
(non-stock).

27 Project delivers benefit over whole of

project life. Project exists beyond
implementation. Project needs to be 0.48 0 Not a function able to be performed in SAP-PS. This is an area requiring further research.
assessed for benefit delivery until end of
asset life.
28 Project adds value to the business
according to original promise (e.g. 0.4 0 Not a function able to be performed in SAP-PS. This is an area requiring further research.
productivity, safety, regulatory)
Accountant

7
29 Budget is respected
0.48
30 Planned project commitments. Control on
committed costs should be managed in
accordance with business needs i.e.
deferred or accelerated depending in
response to business cash flow needs
CJ02 Budget developed from approved
1 Same as requirement No. 24
CJBV project plan
Project scope broken down in a WBS Procurement activities planned. Delivery
structure. Structure is subdivide into dates defined in activity schedule
procurement packages

0.48 1 CJ20N

 Each procurement activity is planned within the project schedule;

 Start and end dates are driven by the schedule logic. These dates translate into
accurate procurement planning data.
Purchasing Officer
32 All procurements effectively planned Project scope broken down in a WBS
0.4 1 CJ20N structure. Structure is subdivide into Same as requirement no. 30
procurement packages
33 Minimised rework on purchase orders Accurate procurement packages Procurement activities accurately planned  Procurement packages are planned as packages. The supplier delivery data is
planned and released when in accordance with supplier terms. Delivery entered into activity duration. Delay the release of the activity until risk of
0.4 1 CJ20N required. dates defined in activity schedule. schedule delays in driving activities is minimised. This prevents prevents the need
for delivery date changes
34 Requisition transparency Details procurement information Item text contains any agreed special terms  Procurement item long test contains any special terms and conditions required to
entered in requisition and conditions of procurement contract. be printed on the purchase order, which are printed on the purchase order;
CJ20N Supplier quotation attached to requisition
0.4 1
ME52N  Supplier quotation is attached to purchase requisition;
 All items to be procured are listed as individual items and not included as a

8
 service stating “as per quote”
35 Stores must goods receipt all components Items listed as components. Either Itemised procurements entered as
(no services used to purchase components) stock or non-stock component material

0.4 1 CJ20N

 Components entered to facilitate stores processing

 No components procured as a service

36 Materials master data used strategically to All components entered as Itemised procurements entered as
deliver maximised value for the business components with correct material component material
class

0.4 1

 Procurements correctly entered

 Material group made a mandatory field
 Procurements configured correctly to facilitate reports on material class and types
Plant Maintenance
Maintenance Manager
37 Turn around and outage integration. Clear Plant maintenance workorder linked Maintenance planner creates shutdown
visibility through the plant maintenance to shutdown maintenance schedule. plan and assigns a revision code (Tx OIOB).
system on all projects being executed Maintenance schedule maintained
within scheduled plant maintenance by maintenance planner Maintenance workorder linked to shutdown
turnaround and shutdowns plan revision.

Workorder dates drive project schedule

CN41N
0.8 1 IW32
OIOB
 Planning level workorder created with shutdown revision assigned;
 Project schedule activity linked to plant maintenance work order;
 Workorder is the driver for project activity. Project schedule will change
according to plant maintenance shutdown plan. When maintenance planner
changes revision date project schedule is also changed
 This logic can be applied to other critical milestone throughout the organisation
38 All project components procured through Materials catalogue available Components available from materials
the material catalogue linked to plant CN22 through purchasing module. catalogue.
0.64 1
functional location and equipment CJ20N Engineering materials contained with Equipment and functional location
BOMs linked to the stie functional reference identifiable when procurement is

9
 locations. raised.

 Procurement of stores stock materials available from catalogue

39 All maintenance strategies and spares in
place before project commissioning
0.8
40 Project components procured through the
maintenance process to ensure adherence
to engineering specifications to ensure
materials are procured based on asset life
0.48
cycle and master data is created before
requisitions are raised
41 Maintains an accurate spare parts
catalogue and store stock (right time and
right place)
0.48
42 All plant maintenance resources required
for project purposes must be planned and
scheduled through the PM system
(maintenance resources, reliability
0.64
engineering, maintenance asset planning)
Reliability engineering review project
BOM and creates material master
CN41N
1 before components are procured.
CJ20N
Reliability engineering reviews
project BOM and creates material
master before components are
CN41N procured.
1 made or the project is delivered.
CJ20N Engineering specifications available
from vendor.
Project spares BOM
Material master data completed
before project is delivered.
IH01
1 made or the project is delivered.
CN41N
Plant maintenance workorder
created and planned into the
maintenance schedule
1 IW32
List of project BOM through project
dashboard
One source access for all BOM data
List of project BOM through project
dashboard
One source access for all BOM data
Engineering specifications linked to
procurement object.
List of project BOM through project
dashboard
One source access for all BOM data
All spares entered into the system before
the project goes on line;
Plant maintenance order created;
Maintenance resources and all work
instruction nominated with the
maintenance order. Workorder is planned
and scheduled through normal maintenance
process.
 Selection of engineering materials is performed through the functional location
structure. As the procurement is selected all location master data is record in the
transactions meta data;
 Project BOM is entered into system before procurements are created
 Reliability engineer has ready access to complete project BOM through CN41N.
This enables them to keep material master updated before the procurement is
made or the project is delivered.
 Project BOM is entered into system before procurements are created
 Reliability engineer has ready access to complete project BOM through CN41N.
This enables them to keep material master updated before the procurement is
 All engineering specifications uploaded into system and attached to engineering
material object
 Project BOM is entered into system before procurements are created
 Reliability engineer has ready access to complete project BOM through CN41N.
This enables them to keep material master updated before the procurement is
 All engineering materials spares procured and loaded into stores inventory before
project goes on line.
 Workorder created through IW32 and linked into the project through settlement
rule
 Workorder is assigned required resources, work instructions and user status
PLANNED assigned
 Plant maintenance scheduler schedules workorder through normal maintenance
procedures

10
43 All project handover documentation is
available and accessible in the
0.64 1
maintenance system prior to
commissioning.
Maintenance Planner
44 Materials procured through catalogue
0.4 1 Same as requirement no. 23
45 Accurate procurement planning
0.4 1 Same as requirement no. 33
46 Materials Master Data complete
0.32 1 Same as requirement no. 40
Reliability Engineer
47 Maintenance strategy in place for all
engineering materials 0.4 1 Same as requirement no. 39
48 Engineering materials procured to
0.4 1 Same as requirement no. 41
maximised common spares
Maintenance Planner
23 Centralised procurements to add value for
the business 0.4 1 Same as requirement no.
24 Systems drives accurate procurement
0.4 1 Same as requirement no.
planning
25 Maintenance strategy in place before
0.4 1 Same as requirement no.
project goes online
Production
Plant Manager
26 Estimating to liberal, too much contingency
on original estimate 0.8 0 Not a function able to be performed in SAP-PS.
27 Warranty period on projects group
0.8 0 Not a function able to be performed in SAP-PS.
28 Efficiency in delivery during the expenses Project scope in WBS form Project effectively planned and delivered to
portion. This cost is immediate and comes Project lifecycle defined expectations. Full visibility of phase
off the bottom line. Expenses portion identified
Accurate project plan

0.8 1 CN41N

 Expenses portion identified in project structure

 Time, scope and costs effectively managed

11
29 Efficiency in delivery during the capital Project scope in WBS form Project effectively planned and delivered to
portion. This cost is depreciated and Project lifecycle defined expectations. Full visibility of phase
increases production's cost per tonne Expenses portion identified
ration Accurate project plan

0.8 1 CN41N

 Expenses portion identified in project structure

30 Project delivered on time and cost
31 Original criteria / idea delivered. Project
product is fit for purpose and delivers
original promise
32 Project efficiency, especially during
concept - prefeasibility phase. Efficiency
in cost and reaching promised timeframe
Time, scope and costs effectively managed
Project scope in WBS form Project effectively planned and delivered to
Project lifecycle defined expectations. Full visibility of phase
0.64 1 CN41N
Expenses portion identified
Accurate project plan
0.64 0 Not a function able to be performed in SAP-PS. This is an area requiring further research.
Project scope in WBS form Project effectively planned and delivered to
Project lifecycle defined expectations. Full visibility of phase
Expenses portion identified
Accurate project plan

0.64 1 CN41N

 Expenses portion identified in project structure

Time, scope and costs effectively managed
33 Material master fully completed before
0.64 1
project is delivered
34 Construction, implementation and training
0.48 0 Not a function able to be performed in SAP-PS.
delivered efficiently
Superintendent
37 All operators trained before project goes
0.6 1
on line
38 All Mods processed effectively and
0.6 1
completed
39 All safety requirements completed. Full Covered previously
compliance with site safety management 0.6 1
plan (e.g. permit to work)
40 Owners representatives kept fully
0.6 1
informed

12
41 Perform the role of commissioning
0.6 0  Not a function able to be performed in SAP-PS. This is a project organisational structure requirements
manager
42 OEM operating documents available and Documents attached to project Documents attached where approval status All project documentation linked to project DMS. Documents can reside internally
loaded into system as part of operational CJ20N objects (WBS or network activities) can be monitored and controlled
0.48 1 within SAP or linked via URL to external sources. This allows the status of the
readiness CV01N
documentation to be monitored and reported through CN41N
Engineering
Engineering Manager
43 Engineering resources working on
0.8 1
individual projects planned effectively
44 Control of resource utilisation on projects 0.8 1
45 Accurate engineering estimates planned in  All engineering requirements are managed through the plant maintenance system
packages and then executed according to 0.8 1  Internal engineering packages are estimated, planned and executed through workorders
plan  The workorders are included as part of the project setup
46 Project work scope effectively
0.8 1  Progress is monitored and trolled through CN41N
communicated to engineering work team
47 Visibility of all hours worked within
projects. Control of actual hours worked 0.8 1
against planned

13
1