Journal of Applied Sciences Research, 5(11): 1904-1914, 2009

© 2009, INSInet Publication

Project Management Maturity Model (PMMM) in Developing On-line Statistical Process

Control Software: An Integrated Approach

M. A. Wazed and Shamsuddin Ahmed

Department of Engineering Design & Manufacture, Faculty of Engineering, University of Malaya

(UM), 50603 Kuala Lumpur, Malaysia.

Abstract: Project Management concept is gaining increasing popularity to product developers,

manufacturers, and especially Engineers because of its uniqueness in versatility and its ability to control
time and costs most efficiently. W ith the ever growing competitive market, project commencement lead
time is becoming a more and more crucial issue. Project management maturity model (PMMM) can
integrate the pertinent aspects and contribute to the cost and time management. This paper covers all
aspects of managing a real time engineering statistical process control (SPC) software development project,
ranging from project conceptualization to cost control, risk management and performance measurement.
Along the way, various tools and techniques have been used. The main conclusions drawn out of this
work are that all aspects of project management should be considered in an integrated manner. Should
any one of them be overlooked, it may cause poorer results. W ith project management approach and SPC
solution, any project may be managed within the scheduled time and the budgeted costs.

Keywords: Project management, Management maturity model, Statistical process control

INTRODUCTION At times, it often takes several meetings before the

Project Management is the planning, organizing,
directing, and controlling of resources for a finite
period of time to complete specific goals and
objectives. In the day to day work environment, project
management is one of the most efficient ways to do
business. In business environment change is constant,
competition between organizations is vital, and the
need for more complex and customer-focused
products/service are necessary. The term is better
understood to the construction and infrastructure
developers and less familiar to the manufacturing
personnel and software producers. It has evolved as an
answer to some of the management problems that
result from complex business and production systems.
In the past, changes did not occur as quickly, and an
organization could adjust and develop new products,
processes, and systems through the use of the classical
line organization. As the needs increase and the
systems and processes used to develop, responses to
the changing environment become more complex, the
ability of functional organizations to respond effectively
is even more difficult. Organizations normally institute
project management when complex or non-routine jobs
that cut across departmental lines need to be
completed.
management decides that the project approach should
be led by a project manager. The internal resources of
the organization then are generally tapped. The project
receives the assets - both human capital and monetary.
After estimating these, the progress of the project in
terms of resource usage and expenditure are closely
monitored till completion. Termination of the project
takes place only after post-completion work is carried
out.
In recent years, there has been a considerable
change in the world economic situation. Many
manufacturing companies have begun to change their
management ways. These ways stress the systematic
use of statistical methods for continual improvement.
This has led to a great demand for statistical
knowledge among in manufacturing industry. Therefore,
statistical methods are important for product quality
improvement, communicating data, manufacturing
process control and developing a product in a
systematic approach.
Statistical Process Control (SPC) chart is one of
the famous SQC tools. It was introduced by W alter A.
Shewart in 1942 and popularized by Dr. W . Edwards
Deming in Japan in 1950. SPC chart is used where
data collected on a sampling basis is plotted
chronologically on a chart, and used to distinguish the

Corresponding Author: M. A. Wazed, Department of Engineering Design & Manufacture, Faculty of Engineering, University
of Malaya (UM), 50603 Kuala Lumpur, Malaysia (Phone: 60-143-605425;
E-mail: awazed@gmail.com.
1904
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009
controlled and non-controlled variation from sample-to-
sample. Control limits and some zone tests are used to
determine out of control conditions. Any out of control
point will signal a variation caused by special cause
that can be linked to the cause of a problem.
This paper presents a case study on use of project
management maturity model approach to implement
online in-process SPC monitoring software in a W afer
Fabrication Company. This SPC software development
project is named as MEX (fictitious name). Each of the
steps of project management maturity model is
followed and discussed. The application of SPC is
highly significant in the manufacturing arena nowadays.
SPC is a very useful method in industries and SPC
software could be a solution to the majority of
manufacturing problems for better control and use of
existing corporate resources. The implied objectives
are: i) to automate the current workflow in the
production floor; ii) to ensure an effective out of
control feedback systems; and iii) to provide a more
effective solution all over the processes through online
in-process SPC implementation to the company.
Perspective of M EX: Company ‘DXS’ is a silicon
wafer fabrication company, using SPC chart to achieve
better process control for outgoing product since 2004.
Figure 1 shows the evolution of SPC application in the
Company. Online in-process SPC System (i.e. MEX) is
an integrated software system that provides company
an IT infrastructure to enhance the effectiveness and
efficiency throughout the processes in the production
floor. MEX allows collecting real-time control data
across the plant at every stage of the wafer
manufacturing process. It facilitates everyone to have
a current, accurate picture of what is happening in the
process. It alarms and signals when any parameter goes
out of control (OOC) or any exception is allowed by
production engineers. It can compare performance,
identify problem areas and accelerate decision making.
Historical reports can store, run and use for analysing
p ro b lem s and com paring p e rfo rm a nc e fo r
benchmarking.
M EX Software System: Online in-Process SPC system
acts as a standalone application that helps the
production floor in implementing the SPC during the
processes. At high-level architectural view (Fig. 2), it
consists of a SPC server which interacts with AS 400
server and Lotus Note server as well as all client PCs.
This client-server architecture allows the SPC server to
act as a central controller that controls the
communication between client PCs with other servers.
There are twelve client workstations placed in
production floor to allow user to setup control plan,
1905
input sampling data, view control chart, attend to out-
of-control (OOC) events and perform sampling plan.
Besides two workstations are there for production
office and QC office with additional features such as
system and user configuration, reporting and analysis.
MEX perform engineering analysis on out of
control (OOC) events: i) Periodic in-process SPC
reporting; ii) Periodic in-process SPC Review (sampling
plan, control limits and out of control Analysis); iii) In
process SPC activities Trail; and iv) Data archiving.
Figure 3 and Fig. 4 show that manual SPC charting
and proposed online in-process SPC software (i. e.
MEX) activity flow charts respectively. Figure 5 shows
the major modules of M EX. The team structure and the
graphical user interface of MEX are shown Fig. 6 and
Fig. 7 respectively. Table 1 shows the team members’
roles and responsibilities of the MEX project.
Project M anagement Approach for M EX: In project
management approach, a standard series of diagrams
and documents such as work breakdown structure,
Gantt Chart & PERT Chart can be used to assist in the
process of product based planning. These can act as a
p o w e rful a id to a na lyz ing , s c h e d uling and
communicating different aspects of the overall project
plans. Gantt and PERT charts are the visualization
tools commonly used by project managers to control
and administer the tasks required to complete a project.
A complex project is made manageable breaking it
down into individual components in a hierarchical
structure, known as work breakdown structure. Such a
structure defines tasks that can complete independently
of other tasks, facilitating resource allocation,
assignment of responsibilities, and measurement and
control of the project. A Gantt chart lists tasks in a
project on a timeline with their interdependencies. It is
especially useful for planning tasks in a project, and
monitoring progress as the project goes on. Gantt
charts emphasize time rather than task relationships. A
PERT chart, in comparison to Gantt chart, looks more
like a flow chart and concentrates on the relationships
between tasks (especially their dependencies) and less
on the timeline. PERT charts emphasize task
relationships rather than time. The work breakdown
structure and PERT chart for MEX project are shown
in Fig. 8 and Fig. 9 respectively.
Budgeting and Cost Control: Budgeting and cost
control is one of the most important aspects in any
project management because it is a time-limited and
cost-limited activity. Company, itself or may
assign/appoint contractor to design and implement a
new project. If company decides to design and
implement a new project itself, then the management
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009
assigns a project team, lead by a project manager. The
team may assign one or more vendors to perform
certain tasks. MEX is developed using the concept of
project team (Fig. 6) lead by a project manager.
Bottom-up budgeting is a method where elemental
activities and their schedules, descriptions and labour
skill requirements are used to construct detailed budget
requests. An ad hoc committee is formed to manage
the project (refer to work breakdown structure, Fig. 8).
They who are familiar with specific activities are
requested to provide cost estimates (Table 2). Estimates
are made for each activity in terms of labour time,
materials and so on. The estimates are then converted
to an appropriate budget. Before a budget is approved
by the top management, the project manager presents
a cost estimate to them, which consists of managing
director, financial controller, plant director and heads of
department. The estimate is done based on several
quotations received from suppliers.
The estimated budget is presented to the top
management in the form of a capital expenditure
request (CER) report. O nce the CER has signed by all
the relevant personnel, the finance department shall
keep a record and return the form to the project
manager indicating that the budget has been approved.
Cost Benefit Analysis: In calculating the project
amortization, projects that are completed within a year
are simply evaluated by payback period. The payback
period is the exact length of time needed for the
company to recover its initial investment as calculated
from expected savings. The major rejection and
payback period are shown in Table 3. The expected
savings resulting from this project is mainly generated
from improved process yield.
Actual cost: After the budget has been approved (RM
498,160.75), the contractor is selected and actual cost
is obtained. The actual price of the entire MEX project
as given by the contractor is shown in Table 4. The
balance (RM 45,100.45) is only an initial expected
balance which may not remain the same when
unexpected events occur that incur costs.
Cost Control: As the project progresses, costs must be
monitored and evaluated to identify areas of
unacceptable cost performance. Cost control is done by
monitoring costs, recording data and also analyzing the
data in order to take corrective action before it is too
late. Cost control is actually a subsystem of the
management cost and control system (MCCS). The
MCCS is represented as a two-cycle process: a
planning cycle and an operating cycle. In the case of
MEX, the planning cycle has been implemented by a
1906
Progressive M ilestone Payment Schedule (Table 5).
This schedule is planned before the project commences
in order to monitor the cost usage closely during the
project itself. The planned date of completion is based
on the project schedule prepared earlier.
The operating cycle is composed of four phases: i)
work authorization and release; ii) cost data collection
and reporting; iii) cost analysis; and iv) reporting
(Customer and management). W hen these phases
combined with the planning cycle, they constitute a
closed system network that forms the basis for the
management cost and control system. Project work
authorization form, is a contract that contains the
narrative description, organization, and time frame for
each W BS level. This multipurpose form is used to
release the contract, authorize planning, record detail
description of the work outlined in the work breakdown
structure, and release work to the functional
departments.
If a cost centre needs additional time or man-
hours, then a cost account change notice (CACN) form
must be initiated, usually by the requesting cost centre
and approved by the project office. However, there was
no cost account change encountered throughout this
MEX project. Actual cost for work performed (ACW P)
and B udgeted cost for work performed (BCW P) for the
project are accumulated in detailed cost accounts by
cost centre and reported to the project team and
management every month. Budgeted cost for work
scheduled (BCW S) is the budgeted amount of cost for
work scheduled to be accomplished plus the amount or
level of effort scheduled to be completed in a given
time period The cost is controlled by variances: i) cost
variance (BCW P - ACW P) and schedule variance
(BCW P – BCW S). A negative variance indicates a
behind-schedule condition.
The values of the variances are used to indicate
the status of the project in terms of cost and schedule.
From the Fig. 10 starting cost variance is zero, which
means that the budgeted cost and actual cost are equal.
So there is no over-spending. A positive cost variance
indicates that the amount of budget still exceeds the
actual cost, so more spending is allowed. A negative
variance indicates a cost overrun condition. But there
is no negative variance in this project, which shows a
good cost control. It is observed that there is a
negative schedule variance. This means that the
budgeted cost for work schedule (BCW S) has exceeded
the amount of budgeted cost for work performed. A
negative variance indicates a behind-schedule condition.
A zero variance indicates that the project item is
exactly on schedule. A positive schedule variance
shows that the project is commencing even earlier than
the planned schedule.
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009

Table 1: Team m em bers’ roles and responsibilities

N o Com pany Com m ittee Roles & Responsibilities
1 Vendor & Custom er Steering Com m ittee Providing m anagem ent support to the team ; A pprove Functional Specification; A pprove
U serAcceptance Testing; Resolve critical issues.
2 Vendor Project M anager: In-charge of overall project tim eline, cost and custom er satisfaction; U pdate on status;
M anage project to achieve m ilestones; Resolve problem s and issues
----------------------------------------------------------------------------------------------------------------------------------------------
SPC consultant Application and SPC functional specification review and advice
----------------------------------------------------------------------------------------------------------------------------------------------
Technical Consultant D esign & codes review and advice
----------------------------------------------------------------------------------------------------------------------------------------------
System analyst System analysis and design and Test planning
----------------------------------------------------------------------------------------------------------------------------------------------
Team Leader D esign & Code Review; Technical Research and D evelopm ent; Integration testing
Coders/Software
Engineers
3 Client Project M anager: Coordinate users and internal team for requirem ent capturing, testing and im plem entation;
Attend project status m eeting and update to m anagem ent; Coordinate functional spec, U ser
acceptance testing (U AT) review and approval; Coordinate Hardware, software and
network installation at shop floor.
----------------------------------------------------------------------------------------------------------------------------------------------
U ser Representatives Coordinate and provide system requirem ents; Conduct system test; Coordinate actual
im plem entation.
----------------------------------------------------------------------------------------------------------------------------------------------
Electronic data Providing technical docum entation and requirem ents for AS400 and e -m ail server;
processing (ED P) Coordinate AS400 & e-m ail server testing; Provide support in actual im plem entation.
representatives
----------------------------------------------------------------------------------------------------------------------------------------------
Project Representative: Coordinate network cabling, power points and hardware installation

Table 2: Cost estim ate

No Item Estim ated am ount
1.0 Software Solution – inclusive of:- 216,000.00
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Requirem ent study 10,000.00
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Solution design 70,000.00
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Software developm ent & testing 80,000.00
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
System im plem entation 20,000.00
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
3-days on-site standby support during pilot run 8,000.00
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
O ne training session 8,000.00
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Com puter software 15,000.00
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2.0 N etworking Infrastructure 100,000.00
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3.0 IT H ardware: Com puters and accessories 130,160.75
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4.0 Supporting Software & H ardware 52,000.00
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Grand Total 498,160.75

Table 3: Breakdown of m ajor rejects in the wafer m anufacturing process

N o. N ature of rejection % reduction
---------------------------------------------------------------------------------------------------------------------
W ithout SPC W ith M EX Reduction in rejection
1 Contam ination 0.10 0.09 0.01
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2 Lapping scratch 1.60 1.49 0.11
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 W ire m ark 1.30 1.21 0.09
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4 Flatness out of specification 3.20 2.99 0.21

1907
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009

Table 3: Continue
5 Surface strain 0.60 0.56 0.04
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6 O thers 0.80 0.75 0.05
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total current rejection 7.60 7.10 0.50
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
M onetary rejection value 4,548,600.00 4,248,392.00 300,207.0
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total investm ent 498,160.75
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Payback period 1.659 years (considering unit price U S$45; and production rate 350,000 pieces of wafer in a
m onth and US$1=RM 3.8)

Table 4: The actual price of the entire M EX project

No Item Am ount (RM )
1.0 M EX Software Solution – inclusive of:- 209,119.20
Requirem ent study; Solution design; Software developm ent & testing; System
im plem entation; 3-days on-site standby support during pilot run; O ne training
session; IBM D B2 U D B Express 8.1 with 12 CAL; M S W indows Server 2003
Standard; W indows Server 2003 Open D D evice CAL
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2.0 N etw orkin g In f r a s t r u c t u r e (U TP N etw ork P oin t; UTP B ackbone; F i b r e -o p t i c B ackbone; E le c t r i c a l)
87,350.00
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3.0 IT H ardware: Com puters and accessories 118,130.10
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4.0 Supporting Software & H ardware 38,461.00
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Grand Total 453,060.30

Table 5: Progressive m ilestone paym ent schedule

Stage Event Planned Criteria of Com pletion Paym ent Percentage
Com pletion D ate of Total Cost (% )
1 Issue of Purchase Order (PO ) 5 Aug 2006 O fficial PO received by
GeniurSoft (Contractor) 20
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2 Approval of Functional Specification 29 Sept 2006 Signed by S.E.H .
M anaging D irector 20
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 1st Phase hardware and software delivery 23 N ov 2006 D elivery acknowledged by
S.E.H . Project M anager 10
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1st Phase on-site test
(Configuration & data entry) 10 D ec 2006 N o m ajor bugs within 2 weeks -
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2nd Phase on-site test
(Integration, Em ail & O O C) 10 D ec 2006 N o m ajor bugs within 2 weeks -
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3rd Phase on-site test
(Analysis & Reporting system ) 10 D ec 2006 N o m ajor bugs within 2 weeks -
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4 Final hardware & software delivery 13 D ec 2006 S.E.H.ProjectM anager
signs upon delivery 10
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
5 Training 6 Jan 2007 All persons involved
attended training 20
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6 U AT (U ser acceptance test) 13 Jan 2007 U AT approved by S.E.H .
Project O wner 10
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
O perational test 21 Jan 2007 N o m ajor bugs within 1 m onth -
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
7 H and-over 28 Feb 2007 S.E.H . Project M anager
signs upon receipt 10
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total paym ent 100

1908
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009

Fig. 1: Evolution of SPC application in Company DXS

Fig. 2: Architectural view of MEX

Fig. 3: Manual SPC activity flow chart.

Fig. 4: Online in-process SPC software (i. e. MEX) activity flow chart

1909
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009

Fig. 5: Main modules of MEX

Fig. 6: MEX team structure

Fig. 7: Example of graphical user interface of MEX

Fig. 8: W ork break down structure (W BS) for MEX development

1910
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009
Fig. 9: PERT chart for MEX development
Fig. 10: Graph of Cost variance and Schedule variance
Project Communication Plan: Project communications
management includes the processes required to ensure
timely and appropriate generation, co llection,
dissemination, storage, and ultimate disposition of
project information. It provides the critical links among
people, ideas, and information that are necessary for
success. Everyone involved in the project must be
prepared to send and receive communications in the
project “language” and must understand how the
communications they are involved in as individuals
affect the project as a whole. For MEX the following
communication plans are used:
1. Communications planning— determining the
information and communications needs of the
parties involve:who needs what information,
when will they need it, and how will it be given
to them.
2. Informatio n d istribution— making needed
information available to project parties involve in
a timely manner.
1911
3. Perfo rmance rep o rting— co llecting and
disseminating performance information. This
includes status reporting, progress measurement,
and forecasting.
4. Administrative closure— generating, gathering,
and disseminating information to formalize phase
or project completion.
These processes interact with each other and with
the processes in the other knowledge areas as well. The
communication methods that are used throughout this
project include project status documents; project
planning and control documents; e-mail and meetings.
Project status report consist of monthly report that are
send out to all team member on monthly basis to info
overall progress of a project and reason of delay if
any. T his report also consists of an outstanding issue
during the time of report preparation and upcoming
activity for the next month. This report is prepared by
project manager (client). Project planning and control
document is set of the document use throughout the
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009
project implementation such as change request form,
requisition request, project schedule and etc. These
communications also cater for detailed planning of an
activity such as training plan, testing plan, and software
bugs report. E-mail are use for inter and intra office
communication to distribute any information on a need
to know basis for all team member. Meetings call for
discussing any outstanding issue (as need basis) and
also for project progress reporting (monthly basis).
Conflict M anagement: Conflict in project management
is inevitable. The potential for conflict in information
systems development projects is usually high because
it involves individuals from different backgrounds and
orientations working together to complete a complex
task. The cause of conflict in team projects can be
related to differences in values, attitudes, needs,
expectations, perceptions, resources, and personalities.
Proper skills in dealing with conflict can assist project
managers and other organization members to handle
and effectively resolve conflicts. Conflict management
is a critical issue of project management, in which if
left uncontrolled, conflict can literally tear a project
apart. In order for conflict to be effectively managed
by the project managers in MEX, conflict management
plan is establish and clear channel for conflict
resolution is made to all parties (Fig. 11). Five modes
for conflict resolution are used to solve conflict during
the project implementation. T hese modes are
Confronting, Compromising, Smoothing, Forcing, and
Avoiding.
R isk A ssessment and M anagement: Software
applications have grown in size and complexity
covering many human activities of importance to
society. Unfortunately developing software is still a
high-risk activity. There have been many approaches to
improving this situation, mostly focused on increasing
productivity via improvements in technology or
management. Despite the recent improvements
introduced in software processes and automated tools,
risk assessment for software projects remains an
unstructured problem dependent on human expertise.
Solving the risk assessment problem with indicators
measured in the early phases would constitute a great
benefit to software engineering.
Risk M anagement Plan and Process: Effective risk
management involves a continuous process of risk
identification, assessment mitigation, monitoring, and
c o n tin ge n cy p lanning th ro u g ho u t th e syste m
development, fielding, and Post-Deployment Software
Support (PDSS) phases. The risk management process
should include monitoring of key development and
management practices through the implementation of
1912
select metrics and risk indicators. These measures will
not only enable managers to identify, prioritize, track,
and mitigate risks, but will also serve to gauge the
effectiveness of the risk management process.
The risk management process is straightforward
and, from a process standpoint, one of the easier
disciplines to plan and implement. Projections are that
a fully functional process including policy, plan,
procedures, essential training tool loaded with an initial
set of risks and an initial risk identification session can
be completed within 30 days of identification of the
requirement. Cultural acceptance and integration of the
process where it is a valued and essential management
tool supported and used effectively by management
may take years to achieve. Policy and underlying
commitment; Designate risk coordinator and risk
officers; Identify risks; Analyze risks; Prioritize risks;
Report risks; and Establish a risk reserve are very
important issues to manage the risk. In MEX project,
the authors used Failure Mode and Effect Analysis
(FMEA) as the risk assessment tool.
Change M anagement: As a project progresses, the
people involved with the project develop a better
understanding of what the end product should be and
what they need to do to produce the product. This
increased understanding manifests itself as changes to
the stage activities, and changes to the products. This
will disrupt the project and stage schedules, project and
stage costs, project scope. Such changes cannot always
be avoided, but their impact can be predicted and
controlled. A change control cycle for the MEX project
management plan start with initiation of change by
member of the project team (Fig. 12). A project
member can request change regarding to the job under
their supervision by firstly issuing a change request
form. The form will then be submitted to the project
m a n a g e r s ( V e n d o r a n d c l i e n t) d u r in g th e
communication meeting. Upon officially receive the
change request; the change request loop will be
initiated by the project manager and he will review the
change request with the parties involve for the change
item. Alternative and specific requirement will
determine during this review. At the end of the review,
ranking classification will be provided and the effect of
the change on the project cost and timeline is estimated
during this stage. After the review, project manager
will decide on the status of the change request either
it is approved, rejected or defer to a specific date in
the future. If it is approved, verification will be done
after the changes are implemented. Total of four (4)
changes requested during the period of the project:
three (3) cases with influence to overall project cost
and one (1) case for schedule change to accommodate
unexpected delay.
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009
Fig. 11: Conflict management cycle for MEX.
Fig. 12: MEX change control cycle.
Fig. 13: Basic Feed Back Loop.
Performance M easurement: Performance measures
quantitatively tell us something important about our
products, services, and the processes that produce them.
They are a tool to help us understand, manage, and
improve what our organizations do. Performance
measures let us know: How well we are doing; If we
are meeting our goals; If our customers are satisfied; If
our processes are in statistical control; and If and
where improvements are necessary. A performance
measure is composed of a number and a unit of
measure. The number gives us a magnitude (how
much) and the unit gives the number a meaning (what).
MEX project is measure to quantify a situation, to
regulate, or to understand what affects things. It can
help worker understand and improve performance. It is
exciting to measure, to benchmark, and to stretch to do
better. MEX, can develop control charts, auto generates
and plot directly. W hile using manual SPC chart one
must draw the chart by oneself. In MEX, when the
results are plotted, values are observed in relation to
the center (median) line. Once MEX show the output,
it is in statistical control, the process is performing to
its natural limits and can be improved only by system
improvements, which is a management function. The
performance of the MEX project is measured based on
six categories: Effectiveness; Efficiency; Quality;
Timeliness; and Productivity. The basic feedback loop
shown in Fig. 13 presents a systematic series of steps
for maintaining conformance to goals/standards by
communicating performance data back to the
responsible worker and/or decision maker to take
appropriate action(s).
1913
Conclusions: After having studied this particular
project, it is found that several project management
tools could be used in order to improve the project
planning, monitoring and successful implantation itself.
Based on project data, the authors used and analyzed
work breakdown structure, PERT/CPM diagram, cost
benefit analysis, cost control, responsibility assignment
matrix, conflict management and failure mode and
effect analysis.
Planning and scheduling activity helped to assign
responsibilities to a specially identified organizational
e le m e n t, a n d e s ta b lis he s sc he d ule s fo r the
accomplishment of the work. The actual project
commencement did not deviate very much from the
planned schedule because of its systematic approach of
implementation. In budgeting and cost control, there
was only delay in payment time as shown by the
schedule variance. This is because the project manager
purposely breakdown the payment by phase of software
delivery. In workforce management, the responsibility
assignment matrix help to clearly identify each person’s
job function so that there is no overlapping. Risk
management performing with FMEA to enable all
project members to be aware of the potential risks in
the project and thus try to avoid them. Change
management helps to create a systematic documentation
for future reference. Performance measurements make
sure that requirements are met along the way.
A successful project management can be defined
as having achieved the project objectives within time
and cost with the desired performance/technology level
and utilizing the assigned resources effectively and
 J. Appl. Sci. Res., 5(11): 1904-1914, 2009
efficiently. In any project-driven organization,
particularly large multi-national manufacturing
companies, project management methodology is a must
for handling large projects to meet cost and time
constraints.
REFERENCES
1. George Eckes, ‘The Six Sigma Revolution: How
General Electric and others turned process into
profits’. 2001, New York NY, W iley.
2. Hubert and Stuart Dreyfus, ‘Mind over M achine’.
1986, New York NY, Macmillan, The Free Press.
3. Harold Kerzner, ‘Strategic Planning for Project
Management Using a Project Management
Maturity Model’. 2001, New York NY, W iley.
4. Aladwani, A. M. IT Project uncertainty, planning
and success: An empirical investigation from
Kuwait. Information Technology and People.
2002, 15(3): 210-226.
1914
5. CMMI Product T eam, 2002. Capability Maturity
Model Integration. Retrieved January 3, 2006,
fromhttp://cmsu2.cmsu.edu/public/classes/sam/cis
4655/cmmi.pdf
6. Gray, C.F. and E .W . Larson, Project
management: The manageriel process. 2000,
Singapore: Mc Graw-Hill.
7. Hughes, B. ans M . Cotterell, 2006. Software
project management. (4th ed.). London, UK:
McGraw-Hill.
8. Muriithi, N. and L. Crawford, 2003. Approaches
to project management in Africa: Implications for
international development projects, International
Journal of Project Management, 2(5): 309-319.