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 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.
At times, it often takes several meetings before the 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:
[email protected]. 1904
J. Appl. Sci. Res., 5(11): 1904-1914, 2009 controlled and non-controlled variation from sample-tosample. 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,
input sampling data, view control chart, attend to outof-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
1905
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
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 manhours, 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.
1906
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 Com pletion D ate 1 Issue of Purchase Order (PO ) 5 Aug 2006
Criteria of Com pletion
Paym ent Percentage of Total Cost (% )
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.
2.
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. Informatio n d istribution— making needed information available to project parties involve in a timely manner.
3.
4.
Perfo rmance rep o rting— co llecting and disseminating performance information. This includes status reporting, progress measurement, and forecasting. 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
1911
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
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.
1912
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).
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
1913
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.
5.
6.
REFERENCES 7. 1.
2. 3.
4.
George Eckes, ‘The Six Sigma Revolution: How General Electric and others turned process into profits’. 2001, New York NY, W iley. Hubert and Stuart Dreyfus, ‘Mind over M achine’. 1986, New York NY, Macmillan, The Free Press. Harold Kerzner, ‘Strategic Planning for Project Management Using a Project Management Maturity Model’. 2001, New York NY, W iley. Aladwani, A. M. IT Project uncertainty, planning and success: An empirical investigation from Kuwait. Information Technology and People. 2002, 15(3): 210-226.
8.
1914
CMMI Product T eam, 2002. Capability Maturity Model Integration. Retrieved January 3, 2006, fromhttp://cmsu2.cmsu.edu/public/classes/sam/cis 4655/cmmi.pdf Gray, C.F. and E .W . Larson, Project management: The manageriel process. 2000, Singapore: Mc Graw-Hill. Hughes, B. ans M . Cotterell, 2006. Software project management. (4th ed.). London, UK: McGraw-Hill. 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.
