WORKING TOWARDS THE VISION OF "THE BEST SAP PLANT

MAINTENANCE IMPLEMENTATION IN SOUTH AFRICA

EVER" AND ACHIEVING SUCCESS THROUGH STAKEHOLDER
PARTICIPATION AND BUY IN.
Martin Smit1 and Ingrid Pistorius2
1
Eskom Generation, 2Accenture

Abstract

Many IT implementations are unsuccessful in that projects are terminated before completion or they
are completed late and exceeds the budget by far. In many instances the users are not satisfied with
the system or they are not effectively using the system to its fullest potential. In very few instances
are any real benefits measured and realised.

Eskom Generation is in the process of implementing SAP R/3 Plant Maintenance (PM) version
3.1H at 10 power stations. The objective of this presentation will be to share the project
management approach being followed and the lessons learnt to ensure successful implementation.
The paper is a case study of a real-world implementation and the authors will present an objective
account of the project with specific focus on the PMBOK knowledge areas (i.e. integration, scope,
time, cost, quality/performance, human resources, communications, procurement, and risk
management).

1 INTRODUCTION

Effective plant maintenance is critical to the Eskom Vision of lowest cost electricity in the world
and the Generation objective of world class technical performance (90:7:3). To achieve this vision
and objective it is essential to have a world class Plant Maintenance (PM) system with embedded
best practices. You also need an empowered workforce utilising the system to its fullest potential to
maintain the Generation plant assets (book value of R24.044bn and annual maintenance cost of
R1.642 for 2000).

The current Plant Maintenance system Permac is at the end of its development life cycle and does
not serve the needs of the power stations. Permac does not have the functionality of “world class”
PM systems and is not integrated with the plant, financial and other systems. A detailed business
case was compiled investigating the cost and associated benefits for different software products and
implementation options for an integrated plant maintenance system. Approval was obtained from
the Generation Executive Committee to install SAP PM at 10 power stations (9 fossil and 1
nuclear).

2 PROJECT OVERVIEW

The project has been divided into three separate projects:

2.1 A detailed business case and approval project

The business case and approval project started on 26 July 1999 and was completed on 25 August
2000 when contracts were signed with the successful implementation partners and software vendor.
The objective of this part of the project was to make a recommendation considering 4 options:

Paper presented at African Rhythm Project Management Conference 22 – 24 April 2002, Johannesburg, South Africa
Hosted by: Project Management Institute of South Africa (PMISA): www.pmisa.org.za ISBN Number: 0-620-28853-1
 • Plant maintenance functionality integrated with the financial and commercial systems (i.e.
SAP);
• Plant maintenance functionality integrated with the plant configuration management system (i.e.
PiGo);
• Plant maintenance functionality using a “best of breed” system (i.e. Maximo); or
• Do nothing, keep the status quo (i.e. Permac and PiGo).

The second part of the project objective was to obtain buy-in from all the relevant stakeholder
forums, to obtain approval form the relevant management bodies, to obtain approval for the capital
expenditure and to negotiate contracts with the recommended software and hardware vendors as
well as the implementation partners.

2.2 Implementation project

The project for the Implementation of the SAP PM system started on 04 September 2000 and is
planned for completion in August 2002. The objective of this part of the project is to implement the
SAP PM system at 10 power stations in the Generation Group (approximately 2500 users). Figure 1
shows the implementation phases of the project.
22000000 22000011 22000022
SSept
ept OO ct
ct NN ov
ov DDec
ec JJan
an FFeb
eb MM ar
ar AApr
pr MM ay
ay JJun
un JJul
ul AAug
ug SSept
ept OO ct
ct NN ov
ov DDec
ec JJan
an FFeb
eb MM ar
ar AApr
pr MM ay
ay JJun
un JJul
ul AAug
ug

DD EESSIIGGNN
PH
PH AASSEE

DD EELLIV
IVEERRYY
PH
PH AASSEE

PI
PILO
LO TT::
TTutuk
utukaa
GGRROO UU PP 11
DD uvh
uvhaa,, LeLeththaabbo,
o,
MM aati
timm bbaa
GGRROO UU PP 22
HH eend
ndri
rina
na,, MM aajub
jubaa,,
KKend
endal al

GGRROO UU PP 33
KKrieell
ri ,, MM atl
atl aa

KKOO EEBBEERRGG

Figure 1. Implementation phases of the project

2.3 Benefits realisation project

This project is planned to start on 01 June 2002 with a planned finish date of 31 December 2003.
The objective is to attain the maximum return on the SAP PM investment by facilitating actions
across all 10 power stations in order to realise the benefits following the implementation of the SAP
PM system in the Generation Group.

3 APPLICATION OF PMBOK KNOWLEDGE AREAS

3.1 Project Integration Management

3.1.1 Project plan development
One project plan was developed for the business case. For the implementation project, project plans
are developed prior to the start of each of the phases. The Accenture Business Integration
Methodology© and historical information from other, similar Accenture system implementation
projects are used as a basis to develop the integrated project plan. During all project phases, the
interaction and dependency between the different teams on the project are two important factors to
keep in mind to make the plan work effectively for everyone.

Another challenging factor during project plan development is the fact that there are many
organisations involved in the project – each with their own methodologies and thinking. However,
the project plan is not developed in isolation. Input from all organisations is sought throughout the
planning process.

Reports from MS Project are used to guide the project execution and project control. The Theory of
Constraints (TOC) buffer management methodology is used where non-critical paths are protected
by feeding buffers, and the critical path is protected by the project buffer.

3.1.2 Project plan execution

The project plan is actively managed throughout all the project phases. Each team leader has the
responsibility to update his/her part of the plan on a weekly basis, based on the team’s progress for
the week. The overall project progress is then summarised in an Excel-based graph, which
indicates the project buffer penetration (TOC model), as well as the overall project and team
progress. This is discussed in a weekly progress meeting, attended by all team leaders.

3.1.3 Overall change control

The initial project plans for each project and each phase are approved by the Project Manager and
saved as a baseline against which changes can be controlled. The project plans are updated weekly
to indicate the progress. New changes are incorporated into a revised project baseline once the
change requests are approved.

3.2 Project Scope Management

3.2.1 Initiation
The need for the project was initiated from within the business, not from Information Management.
The Power Station Managers Forum who realised the need for replacing the plant maintenance
system initiated the project. A Maintenance Manager with project management experience from one
of the power stations was seconded to lead the project.

3.2.2 Scope planning

A project scope statement was developed for each of the three projects and covered the following
elements:
• Project statement of work with reference to the detailed specifications;
• Project objectives in terms of time, cost and performance;
• Key performance areas and quality criteria for each of the PMBOK knowledge areas; and
• Management plan that includes the project organisation, accountabilities, master plan and
implementation methodology/approach.

The scope statements were supported by the Steering Committee and authorised by the Project
Sponsor.

3.2.3 Scope definition

As scope definition is critical to project success. Detailed specifications were compiled during the
business case for the following:
• Specification for Software Implementation;
• Specification for Software; and
• Specification for Hardware.
3.2.4 Scope verification
The specifications were reviewed by some of the Power Station Managers, the Steering Committee
and the Generation Tender Committee, the purpose being to ensure a detailed and accurate project
scope accepted by the business that will result in few scope changes.

3.2.5 Scope change control

It was decided to implement SAP PM “Vanilla” to keep the scope changes to a minimum. The only
scope changes that were allowed was to ensure that the system works effectively to cater for
specific business needs e.g. nuclear and cold reserve power stations. A detailed position paper is
compiled for each scope change and is approved by the Steering Committee to ensure that the
changes are beneficial.

3.3 Project Time Management

3.3.1 Activity definition
The Accenture Business Integration Methodology©, project scope statement and historical
information from similar Accenture projects are the main inputs for the activity definition. These
activities are depicted in the overall project plan and performed to produce the various project
deliverables.

3.3.2 Activity sequencing

Based on the Accenture Business Integration Methodology©, historical information and work
experience, the dependencies between the different project activities are determined, and entered in
Microsoft Project (the tool used for the project plan).

3.3.3 Activity duration estimation

Activity duration estimates are based on historical information, resource availability and resource
capabilities, as well as expert judgement that is obtained from various stakeholders.

3.3.4 Schedule development

MS Project is used to assist with the schedule development and resource levelling. Theory of
Constraints (TOC) was adapted after assistance from the Goldratt Institute to assist with the
compilation of the initial project schedules for the design and development phases of the
implementation project.

3.3.5 Schedule control

Few changes are made to the schedule activities, duration estimates and sequences other than
adding new activities due to new scope changes. No schedule change control procedures are used
other than the overall project plan revisions.

3.4 Project Cost Management

3.4.1 Resource planning
The Accenture Business Integration Methodology©, historical information, the project scope
statement and the resource pool available are the major inputs for determining what resources
(people, equipment, etc) and what quantities of each are to be used to execute the project activities.

The resource planning is not done in isolation by the management team. Being a relatively small
project team, it is easy to obtain constant input from the team members regarding their preferences
and career aspirations. This ensures that the team members are motivated and they accept the
overall project plan.
3.4.2 Cost estimating
Cost estimating involved developing an approximation of the costs of the resources needed to
complete the project activities after consideration was given to various costing alternatives. Cost
estimates were compiled from information obtained from the potential software and hardware
vendors and implementation partners.

3.4.3 Cost budgeting

The cost baseline was derived from the cost estimates and included the following:
• External cost (including escalation) for contracts to procure software licences, buy/hire
hardware and implementation partner resources;
• Internal cost (including escalation) for own resources and general project expenses;
• Cost of cover and IDC (interest during construction); and
• Project contingency of 4%.

Execution Release Approval (ERA) for the project was obtained for the final cost baseline from the
Eskom Capital Investment Committee.

3.4.4 Cost control

The cost baseline is changed following approval of the scope and cost changes by the project
Steering Committee. The total cost for scope changes are monitored against the project
contingency. It was decided to have a formal cost management plan. Cost is monitored during the
weekly progress meetings by comparing the estimate at completion with the budget (ERA value).
See figure 7.

3.5 Project Quality Management

3.5.1 Quality planning
The Quality Plan is the major output of this activity. The Quality Plan aims to ensure that the
defined quality objectives are met and stakeholders and sponsors’ expectations are fulfilled or even
exceeded.

3.5.2 Quality assurance

Various processes and tools are used to evaluate the overall project performance on a regular basis
to ensure that the project would satisfy the quality standards. One of these is the Client Quality
Management Assessment (CQMA). An Accenture on a regular basis does this assessment. The
objective of such an assessment is to monitor the overall satisfaction of the various stakeholders of
the project as well as to monitor the overall quality processes and suggesting improvements.

Eskom Corporate Audit is closely involved with the project. They review project deliverables,
monitor solution testing (including user tests) and are present during the final conversion of data
into the live system.

The system testing process is used to ensure that the solution fulfils the requirements of all
stakeholders. It includes different tests for each Power Station, namely unit testing, string testing,
system testing, user acceptance testing and dress rehearsal testing. Each of these tests is conducted
by different stakeholders, which include project team members and end users.

3.5.3 Quality control

The weekly progress meeting is used as the forum to manage the Quality Plan. During this
meeting, the list of project deliverables is reviewed and sign-off dates are recorded.
Project management team members, team leaders, site representatives and end users sign off the
project deliverables. This records the satisfaction and approval of the various stakeholders with the
solution and the overall project.

Each project phase is concluded with a Phase Closeout Report. This report is a summary of all the
activities and deliverables (with references) that are executed and completed during that phase. The
Steering Committee approves and signs-off this report which formally concludes each project
phase.

3.6 Project Human Resource Management

3.6.1 Organisational planning
Steering
Committee
Journey and FSC
Change Mgt
Project Project
Quality Management Administration Support
Assurance

Data Solution Human Performance Solution

Systems
Preparation Prep & Site Preparation Support
Integration

Data Training
Software Site User
Purification Solution Material
Factory Readiness Profiles
Confirmation Update
& Support

Environment Conversion
Management Testing Configuration Training
(incl Project Coordination
infrastructure)
Solution
Testing
Production
Architecture &
Infrastructure

Figure 2. Project Team Organisation

Figure 2 illustrates the project team organisation and reporting relationships. The project team
consists of 5 teams, namely the project management team, the systems integration team, the data
preparation team, the solution preparation team and the human performance & site preparation
team.

The Steering Committee plays an overseeing role. They provide overall leadership, guidance and
approval of the project. During monthly Steering Committee meetings, the project management
team gives status feedback, highlights issues and risks and obtains their input and approval as and
when necessary.

During rollout/implementation phases, the project team is split in two, due to the fact that some
team members have to be at the Power Station sites. The one major challenge that the team is faced
with then, is to maintain good communication channels between the central and site based teams.
Figure 3 below illustrates the team organisation during Rollout phases:
 Change
Change Project Mgmt FSC
FSC
Mgmt

Central
Data Purif & Conversion Solution Preparation

Solution/
Solution/
Interfaces
Integration

Change
Rollout Mgmt
Mgmt
Mgmt

Site
PS 1
Roles
Roles && Training
Training Technical
Technical Dress
Dress
PS 2 Profiles
Profiles
Training
Training
Logistics Environm Rehearsal
Outages
Outages
Logistics Environm Rehearsal
PS 3

Figure 3. Project team organisation during rollout phases

3.6.2 Staff acquisition

Each organisation involved in the project has its own policies & procedures with regards to staff
acquisition. The project team organisation plan (figure 3 above), staffing pool description and
recruitment policies are the major inputs to this process. Eskom resources are seconded to the
project.

3.6.3 Team development

This is the activity of developing individual and group skills to enhance the overall project
performance. In the beginning of the project the team formulated the project vision of “being the
best SAP PM implementation in South Africa ever”. The vision serves as a psychological contract
between the organisation, the team members and the project manager. The project vision is
constantly communicated to all stakeholders in various forums.

The team also attended detailed SAP PM training to help them understand the system that they are
working with. Successes are celebrated after key milestones have been achieved, e.g. through
activities such as team sport events, social dinners, etc.

Much attention is also given to do regular knowledge transfer sessions. This entails that an expert
in a subject/area spends time to transfer his/her knowledge to other team members. Individual
growth and motivation is a natural result of this effort.

Performance contracts are negotiated with each team member to include project objectives as well
as individual performance objectives. Team members are provided with regular performance
feedback. This leads to clear performance improvements.

3.7 Project Communications Management

3.7.1 Communications planning
The main objective of communication is to give the right information to the right people, at the right
time, in the right format. There are also other reasons for communicating with the project
stakeholders (i.e. users, Steering Committee members, Power Station Representatives, etc.). The
objectives of communication are to:
 • Ensure consistent messages across all stakeholder groups;
• Inform, involve and educate all stakeholders whose commitment is required, on the changing
maintenance processes and technology (SAP);
• Address concerns and fears of the people impacted by the SAP PM implementation, thereby
beginning and sustaining the acceptance process by promoting buy-in from stakeholders;
• Ensure that all stakeholder groups know how and when they will be affected by the
implementation of the SAP PM; and
• Create realistic expectations through open and honest communication.
All of these objectives are taken into account when the project communication plan is developed for
each phase.

The communication plan is a matrix that indicates exactly which message is sent to which audience
group, when and which communication channel is used. The matrix is a ‘living’ document that is
updated regularly, due to the fact that additional communication needs may arise during the
project/phase, audience groups may change, etc.

3.7.2 Information distribution

The cascading model below is the basis of how project information is made available to the various
stakeholders:

dy the
bo t
h i s w er s j e c t m e n
• T m p o p r o m p le
e K+ o i
Pr M2 am t ; w
te P P M ll o
M2K+ o fo
A ls
o je S
ya n
tio
Sp wn

Communications he ta
ck

T
• he m e n
ct
Coordinators t ple s & if
O

im o c e s n e s
on er
ba

Sp
pr e r v e ar y
in t c e s s
on
so sh

ne
ed

PSMs, PSRs &

so r
PS Communication Practitioners
rs ip
Fe

Project Champions
hi
p

All M2K+ End Users

Figure 4. Cascading model of communication

Figure 4 illustrates the general flow of messages to the stakeholders. Each stakeholder group is
responsible to ensure that messages are communicated to the stakeholders on the level below.

Power Station Representatives (PSR’s) were identified and formally appointed at each Power
Station to ensure that the power stations actively participate in the SAP PM system implementation.
These individuals co-ordinate all the actions for their power stations to ensure that the requirements
of their station are met. They are also responsible for the data purification effort at their power
station. All project communication is directed to the PSR. He/she is then responsible to disseminate
the information to the right individuals on site.

The project sponsors are the Steering Committee members and functional owners. This body
empowers the project team to implement SAP PM. They follow the implementation process closely
and intervene when necessary.
The feedback loops are an essential part of the model. Each stakeholder group is responsible to
communicate any feedback (e.g. questions, issues, etc.) to the level above, or directly to the project
communication co-ordinators. The feedback is tracked in order to customised future messages.

3.7.3 Performance reporting

The project team leaders compile a weekly status report. These status reports and the project Key
Performance Indicators (KPI’s) are reviewed at the weekly progress meeting. The Project Manager
compiles a bi-weekly status feedback report to the Project Sponsor on all aspects as per the project
knowledge areas. See figures 5, 6 and 7 for examples of the key performance Indicators (KPI’s). On
a monthly basis a performance report presentation is made to the Steering Committee.

Group 2 Roll Out Phase • Contractual go-live finish date: 2002/03/31

• Planned go-live finish date: 2002/03/25
• Expected go-live finish date: 2002/03/25
• Planned support finish date: 2001/04/25
• Project buffer: 4 days
• Project buffer consumption: 0 days
Figure 5. KPI for time management

Data Purification Group 3 Target as at 04 Mar 02: 90% (Completion target date is 15 Apr 02)
Progress (measured • Matla: 86.75%
based on data loaded into • Kriel: 90.02%
the purification tool) • Koeberg: 91.19%
Figure 6. Data purification progress

ACTUAL TO DATE BUDGET (ERA ESTIMATE AT

IN RAND VALUE) IN RAND COMPLETION IN
RAND
Accenture
Arivia.kom
FSC
Generation
Expenses
Infrastructure
Hardware
Software
IDC
TOTAL
Figure 7. Total project cost as at 08 Mar 02 (escalation and scope changes included)

3.7.4 Administrative closure

On completion of each of the projects/phases the documentation for each deliverable is signed-off
and filed. A sign-off document for each project/phase with reference to the key documents is
compiled and signed off by the Steering Committee. After sign-off by the Steering Committee the
project file with documentation is presented to Corporate Audit for review.

3.8 Project Risk Management

3.8.1 Risk management planning
It was decided to follow a team based risk assessment process. Although the initial process to
identify, assess, quantify and compile a response plan for the risks takes some time, it is simple and
very effective.

3.8.2 Risk identification

For each of the project deliverables the question is asked what can go wrong. Team members then
brainstorm the possible risks than can impact each deliverable.
3.8.3 Risk assessment
In order to understand each risk the reason for each risk is identified and documented.

3.8.4 Risk quantification

The impact and probability of each risk on scales of 1 to 10 is established (1-3 is low, 4-7 is
medium and 8-10 is high). A risk rating is then calculated by multiplying the impact of the risk by
the probability.

3.8.5 Risk response planning

Countermeasures for all risks with an unacceptable risk rating as established by the project sponsor
are mitigated. In the case of the SAP PM project it was all the risks with a risk rating > 40.

3.8.6 Risk monitoring and control

The risks, reasons for the risks, impacts, probability, risk ratings and countermeasures are
documented in a risk response plan spreadsheet. Bi-weekly risk control meetings are held to
identify and review the risks as well as monitor the execution of countermeasures for the risks with
a risk rating > 40. See figure 8 for an example of the risk response plan.

Risks Impact Proba- Reasons for Risks Countermeasures Risk Comments

bility Rating

Data not converted in time 8 7 Limited time for Detailed planning to 56

conversions to complete work in
production due to half- time available.
year month end and
volume of Koeberg data.
Koeberg users not trained 7 7 Koeberg will be busy Meeting held with 49 Many users will
with an outage during Koeberg to discuss be trained after
user training. High impacts. Start training the outage.
number of users to be earlier and train
trained. critical mass.
Figure 8. Example of risk response plan

In order to ensure that risks are not overseen a standing agenda item has been added to the two
weekly management meetings and weekly project progress meeting to identify any new risks.

3.9 Project Procurement Management

3.9.1 Procurement planning
A specialist in the disciplines of contract and procurement was involved early during the business
case. Approval was also obtained from the relevant procurement and tender committees regarding
the procurement strategy before starting with the procurement process. It was also decided to go out
on tender and to compile the business case from the tender information received.

The NEC Professional Services Contract was used for the procurement of implementation partner
services with different main options to be negotiated during each phase of the project e.g. target or
termed contracts.

3.9.2 Solicitation planning

Due to the complexity of the decision a decision model was developed to facilitate commitment to
the decision in the selection of the software and the implementation partner. The decision model in
Figure 11 was agreed with the Steering Committee and Power Station Managers.
 EVALUATION CRITERIA WEIGHT
Software (SW):
Evaluation workshop 15%
SW vendor profile 8%
Implementation partner profile 17%
Cost/benefit (NPV) 35%
Strategic:
Non quantifiable benefits 5%
Eskom future direction 5%
IT support 5%
SMME/BEE policy:
SW vendor 2%
Implementation partner 8%
TOTAL 100%
Figure 11. Decision model

Evaluation criteria were developed to rate and score the proposals.

3.9.3 Solicitation
The software vendors submitted the names of accredited implementation partners for their products.
An enquiry was issued to all potential software and implementation partners during a site meeting
where the scope, specifications, contract documents and conditions, etc. were discussed. Proposals
were submitted at the time of tender closing.

3.9.4 Source selection

Representatives from each power station participated in the evaluations of the software
functionality. The evaluation of the competency and company information of the implementation
partner and software vendors was more subjective and was rated by Senior Managers as identified
by the Steering Committee. Following the evaluations the decision model was populated and a
score calculated. Internal and external auditors verified the results of the evaluations. Following the
approval of the business case contracts were negotiated with the successful software vendor and
implementation partners.

3.9.5 Contract administration

During the start of the implementation project all the project team members underwent training on
the NEC contracts. This afforded all to understand the “rules of the game” and has reaped a lot of
benefits, as there are few contract issues.

3.9.6 Contract close out

Contract close out will follow after the completion of the implementation project.

4 KEY LESSONS LEARNT AND CONCLUSIONS

4.1 Project Integration Management

• The application of the PMBOK principles work, also for very complex IT projects;
• Facilitation skills is an essential part of the project managers toolkit;
• During the start of the implementation project the project team attended a two-day project
management course – “The TOC Way”. A key lessons is: It is not important to complete each
task in time, it is essential to complete the project in time.
4.2 Project Scope Management
• Need came from the business who initiated the project which implies that there was business
commitment
• The scope statement is the foundation and guide of all project activities/happenings. It is
therefor critical that it is supported by the Steering Committee and authorised by the Project
Sponsor.
• Involve all the stakeholders during the initial scope definition and verification. It is the first step
to obtain buy in for the new system.

4.3 Project Time Management

• The TOC principle is applied. Buffer consumption is used to monitor and evaluate project
progress.

4.4 Project Quality Management

• A Client Quality Management Assessment (CQMA) process added value to the project by
having an experienced external person broadening the visions, challenging thinking and
providing creative ideas and guidance for resolving complex project problems, as well as to
ensure that there are no key issues and risks overlooked.

4.5 Project Human Resource Management

• A project team vision (created by the project team) serves as a psychological commitment and
motivates the project team to achieve success.
• Correct project KPI’s ensure project success:
• It is the primary method of accounting for the results of actions being taken within the
project;
• It is the primary source of feedback to the project sponsors and project team members alike;
• It has a huge influence on the actions that project team members choose to take since they
do more of what has a positive impact on their measurements;
• Empowerment (alignment between responsibility and authority) of the project manager, team
leaders and members is a necessary condition for an effective project organisation:
• Apply simple, effective techniques to remove obstacles preventing empowerment;
• Communication, i.e. give clear instructions; and
• Team work (synergy).

4.6 Project Communications Management

• Communication is directly proportional to project success, the more successful your
communication is the more successful your project will be;
• Build stakeholders’ buy-in and commitment by involving them in the activities of the project
that will impact them, e.g. process design, solution testing and training delivery;
• Involve site change management specialists and give them the responsibility to execute site
interventions, as they are familiar with the site culture and the users’ typical reactions to change
and are able to customise interventions to assist users to go through all phases of transformation;
and
• Ensure integration between communication and change management efforts.

4.7 Project Risk Management

• The project team members that participate in the process enjoy the team based risk assessment
approach. The identification, assessment, quantification and response planning has been
entrenched in the thinking of the project team members when looking at risks.
4.8 Project Procurement Management
• Obtain approval for the procurement strategy before starting with the procurement process
• Seek the support from specialists in the disciplines of contract and procurement and involve
them early in the process as a member of the project team.
• Involve all the sites with the evaluation of the software functionality. It is the commitment to the
decision that counts.

References

1. A Guide to the project management Body of Knowledge. 2000 Edition. Exposure Draft.
2. William R Duncan. Scoping out a Scope Statement. PM Network December 1994.
3. Peg Thomas. Creating a Shared Vision with a Project Team. PM Network January 1997.

Martin Smith

Martin Smit is a Project Manager and is working for Eskom Generation. He has National Diplomas
in Civil and Mechanical Engineering and Datametrics. He also has a Mechanical Engineers
Certificate of Competency. He has been a PMP since 1992 and also is a Professional Technologist
(Engineering). He is a member of a number of Institutes and has been a Member of the Project
Management Institute (USA) since 1988. He held various management positions in construction,
project and maintenance management.