Integrated business applications like Enterprise Resource Planning system (ERP) is a strategically important business tool for long-term success in an increasingly competitive global marketplace. Such systems require the integration of data and business processes across the Organization or whole Enterprise. Being a part of software development team we knows that such systems requires to achieve customers coordination and commitment from management, user and vendor down to the requirement level, and without detailed knowledge of their business and efficient control of requirements, implementers waste large amounts of time.
          This arise a need for finding suitable process or standard to follow which may cover all possible aspects of ERP's Project Management Processes because the quality of a product is largely determined by the quality of the processes that are used to develop and maintain it. For this purpose applying multiple models that are not integrated within and across an organization have proven useful to many organizations. But it has been problematic for those organizations that would like to focus their improvement efforts across the disciplines within their organizations it becomes more costly in terms of training, appraisals, and improvement activities. The differences among discipline-specific models, including their architecture, content, and approach, have limited these organizations ability to focus their improvements successfully. On the other hand CMMI presents a set of integrated models that successfully addresses multiple disciplines and has integrated training and appraisal support to solve these problems.
          Objective of this thesis is to introduce and analyse an authentic suitable Process or standard for Software Project Management specially for ERP systems that will help the Projects Managers to control every side of implementation, enabling it to occur much faster, saving months, even years of valuable time by tracking vendor commitments and promises at the requirement level and tightly track performance and irregularities.
          This thesis describes analysis and implementation of Advance Project Management Process Area (APMPA) of CMMI model, which includes set of processes and practical guidance that force Project Manager toward continuous process improvement of Enterprise Business for more reliable and higher-quality delivery of software products and services to the customers. This thesis describes and discusses each specific practice, which comes under each Individual sub process area of CMMI's APMPA using case study of General Internationals ERP system.

ABSTRACT ii
TABLE OF CONTENTS iii
LIST OF FIGURES v
LIST OF TABLES vi
ACKNOWLEDGEMENTS viii

Chapter 1 INTRODUCTION 01
1.1 Background 01
1.2 CMMI's Advance Project Management Process Area 02
1.3 Justification for the Research 02
1.3.1 What Organization requires achieving Goals 02
1.3.2 What Project Management is 02
1.3.3 Focusing on ERP 03
1.3.4 Why process and its models 03
1.3.5 What is CMMI Project Model and why recommended for ERP 03
1.3.6 CMMI's Project Management Process Area 03
1.3.7 CMMI's Basic Project Management Process Area 03
1.3.8 CMMI's Advance Project Management Process Area 03
1.4 Methodology followed 04
1.4.1 Brief exploration of Project Management Process Area 04
1.4.2 ERP Case Study as an implementation of APMPA 04
1.5 Delimitations of scope and Key Assumptions 04
1.6 Thesis Overview 04
1.7 Thesis Work Flow 05
1.8 Conclusion 06

Chapter 2 THEORETICAL BACKGROUND 07
2.1 Importance of ERP systems 07
2.2 What Customer desires for their ERP systems 07
2.3 Need for a proper Project Management Framework 07
2.4 Capability Maturity Model Integration 08
2.4.1 Model History 08
2.4.2 About CMMI 09
2.4.3 Selecting CMMI discipline 09
2.4.4 CMMI model Representation 09
2.4.5 CMMI's Process Areas Categories 10
2.5 Project Management Process Area 10
2.5.1 Basic Project Management Process Area 11
2.5.2 Advance Project Management Process Area 12
2.6 Conclusion 13

Chapter 3 CMMI'S ADVANCE PROJECT MANAGEMET PROCESS AREA 14
3.1 Advance Project Management Process Area 14
3.2 Conclusion 16

Chapter 4 CMMI'S ADVANCE PROJECT MANAGEMET PROCESS 17
AREA; GI's CASE STUDY
4.1 Introduction to our Client's Business 17
4.2 Project Management Steps 30
4.3 Generic Goals and Increasing Capability levels 30
4.4 Project Planning 32
4.5 Project Monitoring and Control 36
4.6 Supplier Agreement Management 39
4.7 Integrated Project Management 40
4.8 Risk Management 43
4.9 Quantitative Project Management 44
4.10 Conclusion 47

Chapter 5 COMMENTARY ON END RESULTS 48
5.1 Expected Benefits 48
5.2 Actual End Results Achieved 48
5.3 Commentary 49
5.3.1 Things to Remember 49
5.3.2 CMM v/s CMMI 50
5.3.3 CMMI 50
5.4 Conclusion 51

Chapter 6 CONCLUSIONS 52
6.1 Conclusion And Future Requirements 52

Appendix A Terminologies 54
A.1 Common Terminology with special meanings 55
A.2 CMMI-Specific Terminology 57

Appendix B Availability of Sources 59
B.1 Source Publicly Available 60
B.2 Source Not Publicly Available 60

References 61

Glossary 64

Figure 1.1: CMMI bridges gap between system and software Engineering 02
Figure 1.2: Visualization of need of Goal Achievement 02
Figure 1.3: Pictorial view of Project Management 03
Figure 2.1: Interaction diagram of CMMI Project Management Process Area 11
Figure 3.1: Practice to goal relation ship for Project Planning 14
Figure 3.2: Practice to goal relationship for Project Monitoring and Control 15
Figure 3.3: Practice to goal relationship for Supplier Agreement Management 15
Figure 3.4: Practice to goal relationship for Integrated Project Management 15
Figure 3.5: Practice to goal relationship for Risk Management 16
Figure 3.6: Practice to goal relationship for Quantitative Project Management 16
Figure 4.1: Selection Process 17
Figure 4.2: Our Requirements 17
Figure 4.3: Project Methodology followed 18
Figure 4.4: Business Information 18
Figure 4.5: End Result 18
Figure 4.6: Definitions and Acronyms 18
Figure 4.7: Hardware and Software requirements 19
Figure 4.8: Project Phases and WBS 19
Figure 4.9: Information description 26
Figure 4.10: Estimations 27
Figure 4.11: Team members 27
Figure 4.12: Earned Value Analysis 28
Figure 4.13: Gant chart to make Time lines for tracking milestone 28
Figure 4.14: Task network diagram PERT chart 28
Figure 4.16: Risk Management 29
Figure 4.17: Quantitative Analysis technique (sample graph) [3] 30
Figure 5.1: Improved Schedule and Budge Predictability graph 49
Figure 5.2: Increased Productivity and Quality graph 49

Table 4.1: Clients Demand 17
Table 4.2: Quality and Process-performance objectives QPO's (Sample) [3] 30
Table 4.3: Manage Project Performance (Sample value) [3] 30
Table 5.1: Improved Schedule and Budge Predictability 48
Table 5.2: Increased Productivity and Quality 49

          First of all I would like to acknowledge Allah and his blessings in every area of my life. Then to my mother (Mrs. Razia Sultana widow of Advocate Syed Dabir Ahmad) whom I have found the most sincere and dedicated Allah's angel on earth for me.
I would also like to acknowledge all those valuable persons including my friends who have given me priceless encouragement and support throughout the itinerary of the research that include my teachers (Mr. Aleem Khalid Alvi and Mrs. Mehnaz Adnan), members of CMMI online help team specially to Miss. Sandra Shrum and Manager Cyber Angels "The IT solution providing company" (Mr. Faher-el-Sharif) whose coordination and input has been of great significance that helped me in completing this very first, one of its kind a case study based thesis in my university.
          In last a very distinctive thank to my sister Mechelle N. Shute who really helped me a lot in correcting my grammatical mistakes to finally make this thesis book complete.

1.1 Background to Research
Enterprise Resource Planning systems look at connective data, processes and plans in an integrated fashion to help us develop not only the best practices but also methods that work to outperform normal business processes.
It is a fact that quality of a product is largely determined by the quality of the process that is used to develop and maintain it, where as a model is a structured collection of processes those proven by experience to be effective. With a proper process framework, we can control every side of implementation, enabling it to occur much faster and save months even years of valuable time by tracking vendor's commitments and promises at the requirement level and tightly track performance and irregularities. So there is a need to find out what is best suitable process or standard to follow which may cover all possible aspects of ERP's Project management process.
Over the past thirty years, these theories have been used to address problems common to many organizations. Solutions have been discovered, but a gap existed between the state of the practice and the state of the art. Many of these concepts have been used to build process-improvement models, which are the structured collection of elements that describe characteristics of effective processes proven by experience. [2]
Historically models were depended on the discipline that we want to model like software engineering, systems engineering, software acquisition or systems security etc. Still the problem was systems and software disciplines have traditionally not been well integrated and the importance of software in systems has increased dramatically. There were different structures, formats, terms, and ways of measuring maturity which causes confusion, especially when using more than one model and it was hard to integrate them in a combined improvement program and hard to use multiple models in supplier selection. Department of defence has emphasized the need to make the systems and software interface more seamless. Then Capability Maturity Model Integration comes to rescue by integrating systems and software disciplines into one process improvement framework. It differs by discipline i.e. software, systems, acquisition, etc. and structure i.e. staged versus continuous and how maturity is defined means process improvement path and how capability is defined i.e. institutionalisation.
Its process improvement benefits fall into one of seven general categories: improved schedule and budget predictability, cycle time, productivity, quality as measured by defects, customer satisfaction, employee morale, increased return on investment and decreased cost of quality.

Figure 1.1: CMMI bridges gap between system and software Engineering

It has four major process areas, which are basically a cluster of related practices, among which we are focusing on project management process area, which basically comprise of basic and advance level of process areas.
1.2 CMMI's Advance Project Management Process Area
It addresses activities like establishment of a defined process that is tailored from the organization's set of standard processes, coordination and collaboration with relevant stakeholders including suppliers, risk management, forming and sustaining integrated teams, and quantitatively managing the project's defined process [1].
1.3 Justification for the Research
1.3.1 What organization requires to achieve Goals?
Every organization or program creates and implements projects to help it move toward its goals. Project manager uses standard practices for achieving goal successfully.

Figure 1.2: Need of Goal Achievement

1.3.2 What Project Management Is?
Project management is the discipline that uses skills and knowledge to achieve project goals through various project activities.

Figure 1.3: Project Management

1.3.3 Focusing on ERP systems
Enterprise Resource Planning (ERP) systems look at connective data, processes and plans in an integrated fashion to help us develop not only best practices but also methods that work to outperform normal business methods
1.3.4 Why Process and its Model?
The quality of a product is largely determined by the quality of process that is used to develop and maintain it. Adaptation of proper model is important because it gives us a place to start, benefit of a community's prior experiences, a common language, a shared vision and a framework for prioritising actions [2].
1.3.5 What is CMMI Process Model and why recommended for ERP Systems?
The CMM Integration Service mark of Carnegie university project was formed to sort out the problem of using multiple CMMs. Integrates systems and software disciplines into one process improvement framework. It is recommended because it helps to see the enterprise view of process improvement. Provides a framework for introducing new disciplines as needs arise.
1.3.6 CMMI's Project Management Process Area
A framework for Project management tasks that is required to manage a high quality successful delivery of software. It covers activities related to planning, monitoring, and controlling the project. Gives two levels of Project management process area Basic and Advance.
1.3.7 CMMI's Basic Project Management Process Area
Basic project management process area consists of Project Planning (PP), Project Monitoring and Control (PMC) and Supplier Agreement Management (SAM).
1.3.8 CMMI's Advance Project Management Process Area
Advance project management process area consists of Integrated Project
Management (IPM), Integrated Supplier Management (SS), Risk Management (RSKM), Quantitative Project Management (QPM) and Integrated Teaming (IT) and (IPM) is (IPPD).
1.4 Methodology followed
This thesis describes and discusses each specific practice, which comes under each Individual sub process area of CMMI's advance project management process using case study of General Internationals ERP system.
1.4.1 Brief exploration of Project Management Process Area
As advance project management process area is highly integrated with basic project management process area therefore it will explain basic project management process area first and then actual process areas of advance project management process area.
1.4.2 ERP Case Study as an implementation of APMPA
A leading garment manufactures and exporters General International's ERP system has been taken as a case study. That includes general ledger, accounts payable, accounts receivable, inventory management system, human resource with payroll, export invoicing and website.
1.5 Delimitations of scope and Key Assumptions
Explicit boundary of this thesis includes only those process areas of advance project management process area, which comes under project management process area. As our focus is only on project management process area so all those process areas are excluded from advance project management process area that are involved in it but are not the part of project management process area. Excluded process areas include that comes under Process management process area, Engineering process area and Support process area of CMMI.
1.6 Thesis Overview
This thesis is divided into six chapters. First chapter introduces the background as well as defines the main focus of the thesis. It gives a broad overview of the topics covered as well defines the limits in which the thesis will be confined to. Second chapter deals with the theoretical background that is needed to understand CMMI model. Third chapter discusses short explanation of advance project management process area. Fourth chapter will give sample case study to justify how advance project management process area covers all project management activities those are necessary for a successful delivery of ERP system. Fifth chapter gives end results achieved and commentary on actual end results. The last and sixth chapter provides final conclusion to the work done in the thesis and future studies.
1.7 Thesis Work Flow

1.8 Conclusion
This chapter laid the foundations for the thesis. It introduced the research objective, which is to give analysis and implementation of CMMI's advance project management process area. Then the research was justified, methodology was briefly described, and the boundaries are well defined, limitations given and the thesis outlined. On these foundations, the thesis will proceed by following above-mentioned methodology.

2.1 Importance of ERP Systems
Enterprise Resource Planning system is an industry term for the broad set of activities supported by multi-module application software that help a manufacturer or other business manage the important parts of its business, including product planning, parts purchasing, maintaining inventories, interacting with suppliers, providing customer service and tracking orders. ERP systems also include application modules for the finance and human resources aspects of a business. ERP systems use or are integrated with relational database system. The deployment of an ERP system can involve considerable business process analysis, employee retraining, and new work procedures.
Studies show that seventy to eighty percent of fortune thousand firms have or will soon install ERP systems, which will boost the global ERP market from fifteen billion dollar now to fifty billion dollar over the next five years. ERP applications make up the largest portion of Information Technology budgets. ERP Systems can help an organization to reduce operating costs, increase the organization's time efficiency. Having an ERP system means increased information availability for the organization that means that the organization can access information quickly and easily.
2.2 What Customer desires for their ERP systems
Being an implementer we knows that our ERP customers wants to achieve coordination and commitment from management, user and vendor down to the requirement level. Without detailed knowledge of their business and tight control of requirements, implementers may waste large amounts of time. We need a process that may handle this detail work to complement the software expert's general implementation plan. With proper process framework, we can control every side of implementation, enabling it to occur much faster, saving months, even years of valuable time by tracking vendor commitments and promises at the requirement level and tightly track performance and irregularities.
2.3 Need for a proper Project Management Framework
So there is a need for the best suitable process or standard to follow which may cover all possible aspects of ERP's project management process. As the quality of a product is largely determined by the quality of the process, that is used to develop and maintain it. Over the past thirty years, these theories have been used to address problems common to many organizations. Solutions have been discovered, but a gap existed between the state of the practice and the state of the art. Many of these concepts have been used to build process-improvement models.
2.4 Capability Maturity Model Integration
Capability Maturity Model Integration is a reference model of mature practices in a specified discipline that is used to assess a group's capability to perform that discipline.
2.4.1 Model History
The CMMI project work is sponsored by the U.S. Department of Defence (DoD), specifically the office of the under secretary of defence, acquisition, technology, and logistics (OUSD/AT and L). The systems engineering committee of the National Defense Industrial Association (NDIA) provides industry sponsorship. Organizations from industry, government, and the Software Engineering Institute (SEI) joined together to develop the CMMI framework comprise of a set of integrated CMMI models, a CMMI appraisal method, and supporting products. These organizations donated the time of one or more of their people to participate in the CMMI project [1].
The CMMI project team has been working to provide guidance that encourages process improvement in organizations of any structure. Since 1991, CMMs have been developed for a myriad of disciplines. Although these models have proven useful to many organizations, but the use of multiple models has been problematic. Many organizations would like to focus their improvement efforts across the disciplines within their organizations. However, the differences among these discipline-specific models, including their architecture, content, and approach, have limited these organizations ability to focus their improvements successfully. Further, applying multiple models that are not integrated within and across an organization becomes more costly in terms of training, appraisals, and improvement activities [1].
The CMMI product team's mission was to combine following three source models Capability Maturity Model for Software (SW-CMM) v2.0 draft C, Electronic Industries Alliance Interim Standard (EIA/IS) 731 and Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 in to a single improvement framework for use by organizations pursuing enterprise-wide process improvement. [1].
It supports the future integration of other discipline-specific CMMI models and that all of the products developed are consistent and compatible with the International Organization for Standardization and International Electro Technical Commission (ISO/IEC) 15504 Technical Report for Software process assessment. As with any release of CMMI, however, the opportunity for further improvement remained. Version 1.1 accommodates further improvements from early use as well as more than 1,500 change requests.
2.4.2 CMMI
A process is a leverage point for an organization's sustained improvement. The purpose of CMMI is to provide guidance for improving organization's processes and our ability to manage the development, acquisition, and maintenance of products or services. CMMI is compliant to ISO/IEC and it is derived from SW-CMM that is applicable to Softwares, SECM that is applicable to business process and IPD-CMM that is applicable to integrated products [1]. A selected CMMI model can serve as a guide for improvement of organizational processes. Professional judgment is required to interpret CMMI specific and generic practices. Although process areas depict behaviour that should be exhibited in any organization, all practices must be interpreted using an in-depth knowledge of the CMMI model being used, the organization, the business environment, and the circumstances involved.
2.4.3 Selecting CMMI discipline
CMMI is applicable to software engineering, system engineering and integrated product and process development disciplines. We have adopted here CMMI for software engineering discipline because we desires to improve only our project management process area.
2.4.4 CMMI Model Representation
There are multiple CMMI models available, as generated from the CMMI Framework. Consequently, we need to be prepared to decide which CMMI model best fits your organization's process-improvement needs. We select a representation, either continuous or staged, but it is required to determine the bodies of knowledge that we want to include in the model of organization that we are working on.
There are many valid reasons to select one representation or the other. The following lists describe some of the possible advantages and disadvantages to selecting each of the two representations.
If we choose the Staged representation for our organization, expect that the model will Provide a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels, each serving as a foundation for the next. Permit comparisons across and among organizations by the use of maturity levels. Provide an easy migration from the SW-CMM to CMMI. Provide a single rating that summarizes appraisal results and allows comparisons among organizations. Whether used for process improvement or appraisals, both representations are designed to offer essentially equivalent results. Here its continuous representation is adopted.
If we choose the Continuous representation for our organization, expect that the model will allow us to select the order of improvement that best meets the organization's business objectives and mitigates the organization's areas of risk. It enables comparisons across and among organizations on a process area by process area basis or by comparing results through the use of equivalent staging. Provide an easy passage from Electronic Industries Alliance Interim Standard (EIA/IS) 731 to CMMI. Afford an easy comparison of process improvement to International Organization for Standardization and International Electro technical Commission (ISO/IEC) 15504, because the organization of process areas is similar to ISO/IEC 15504. Here adopted its continuous representation to focus only on Project management process area.
2.4.5 CMMI Process Areas Categories
Process areas are grouped into four categories Process Management, Project Management, Engineering and Support. Grouping of process areas in this way is for ease to discuss interactions between different process areas. Process areas often interact and have an effect on one another regardless of their defined groups.
2.5 Project Management Process Areas
According to CMMI-SW discipline the interactions among the project management process areas is divided in two process area groups [1]:
i. The Basic Project Management process areas are:
- Project Planning
- Project Monitoring and Control
- Supplier Agreement Management
ii. The Advanced Project Management process areas are:
- Integrated Project Management for IPPD
- Risk Management
- Integrated Teaming
- Quantitative Project Management
- Integrated Supplier Management

2.5.1 Basic Project Management Process Areas
The basic project management process areas address the basic activities related to establishing and maintaining the project plan, establishing and maintaining commitments, monitoring progress against the plan, taking corrective action, and managing supplier agreements.

Figure 2.1: CMMI's Project Management Process Areas (note: grey areas are not covered)

See figure 2.1 to view the interactions among the basic project management process areas and with other process area categories. Planning begins with requirements that define the product and project ("what to build" in the figure). The project plan covers the various project management and engineering activities that will be performed by the project. The project will review other plans that affect the project from various relevant stakeholders and establish commitments with those relevant stakeholders for their contributions to the project.
The project monitoring and control process area includes monitoring activities and taking corrective action. The project plan specifies the appropriate level of project monitoring, the frequency of progress reviews, and the measures used to monitor progress. Progress is primarily determined by comparing progress to the plan. When actual status deviates significantly from the expected values, corrective actions are taken as appropriate. These actions may include re-planning.
The supplier agreement management process area addresses the need of the project to effectively acquire those portions of work that are produced by suppliers. Once a product component is identified and the supplier who will produce it is selected, a supplier agreement is established and maintained.
2.5.2 Advanced Project Management Process Areas
The advanced project management process areas address activities such as establishing a defined process that is tailored from the organization's set of standard processes, coordinating and collaborating with relevant stakeholders, risk management, forming and sustaining integrated teams for the conduct of projects, and quantitatively managing the project's defined process.
See figure 2.1 to view the interactions among the advanced project management process areas and with other process area categories. Each of the advanced project management process areas is strongly dependent on the ability to plan, monitor, and control the project. The basic project management process areas provide this ability. Both versions of the integrated project management process area (IPM and IPM for IPPD) establish and maintain the project's defined process that is tailored from the organization's set of standard processes. The project uses and contributes to the organization's process assets. The project ensures that the relevant stakeholders associated with the project coordinate their efforts in a timely manner. It does this by providing for the management of stakeholder involvement; the identification, negotiation, and tracking of critical dependencies; and the resolution of coordination issues within the project with relevant stakeholders.
The integrated project management for IPPD process area also creates the shared vision for the project. This shared vision should align both horizontally and vertically with both the organizations and integrated teams shared visions, created in the organizational environment for integration and integrated teaming process areas, respectively. These shared visions collectively support the coordination and collaboration among stakeholders. Finally, the integrated project management for IPPD process area implements an integrated team structure to perform the work of the project in developing a product. This team structure is typically based on the decomposition of the product itself, much like a work breakdown structure.
Although risk identification and monitoring are covered in the project planning and project monitoring and control process areas, the risk management process area takes a more continuing, forward-looking approach to managing risks with activities that include identification of risk parameters, risk assessments, and risk handling.
The quantitative project management process area applies quantitative and statistical techniques to manage process performance and product quality. Quality and process-performance objectives for the project are based on those established by the organization. The project's defined process comprises, in part, process elements and sub processes whose process performance can be predicted. Corrective action is taken when special causes of process variation are identified.
The integrated supplier management process area proactively identifies sources of products that may be used to satisfy project requirements and monitors selected supplier work products and processes while maintaining a cooperative project-supplier relationship [1].
2.6 Conclusion
This chapter has covered all necessary background issues related to this thesis that includes: Importance of ERP, what are the customer desires for their ERP systems, need for a proper project management framework, details about CMMI model and in last Project management process area i.e. about its basic and advance process area.

3.1 Advance Project Management Process Areas
From previous chapters as we have seen that Advance project management process area also covers elements of Basic project management process area, now this chapter will give definition all and Project management process area and listing of all Specific Goals (SG) and their corresponding Specific Practices (SP) that are required to achieve any particular process area successfully.
For further details you can see product manual of Capability Maturity Model Integration "CMMI, Version 1.1 for Software Engineering Continuous representation Improving processes for better products" by CMMI Product Team August 2002 Release.
Advance project management process area comprise of project planning, project monitoring and control, supplier agreement management, integrated project management, risk management and quantitative project management sub process areas.
3.1.1 Project Planning
The purpose of Project Planning is to establish and maintain plans that define project activities [1].

Figure 3.1: Practice to Goal relation ship

3.1.2 Project Monitoring and Control
The purpose of Project Monitoring and Control is to provide an understanding of
the project's progress so that appropriate corrective actions can be taken when the project's performance deviates significantly from the plan [1].

3.1.3 Supplier Agreement Management
The purpose of Supplier Agreement Management is to manage the acquisition of products from suppliers for which there exists a formal agreement [1].

Figure 3.3: Practice to Goal relationship table

3.1.4 Integrated Project Management
The purpose of Integrated Project Management is to establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization's set of standard processes [1].

Figure 3.4: Practice to Goal relationship table

3.1.5 Risk Management
The purpose of Risk Management is to identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the
product or project to mitigate adverse impacts on achieving objectives [1].

Figure 3.5: Practice to Goal Relationship

3.1.6 Quantitative Project Management
The purpose of the Quantitative Project Management process area is to quantitatively manage the project's defined process to achieve the project's established quality and process-performance objectives [1].

Figure 3.6: Practice-to-Goal Relationship Table

3.2 Conclusion
This chapter has covered information about Advance project management process area that includes: Purpose of all Project management process areas and listing of Specific goals and their Specific practices.

4.1 Introduction to our Client's Business
The Industrial automation program for General International is an ERP system, which will integrate all the department of the company. The main system will comprise of seven major sub-systems the integration of theses sub-system will form the main system. All the sub-systems will be tightly integrated so as to give unanimity to user.
The current client set-up does not have any automation. Therefore, every department and the section will be developed from the scratch as all departments are currently working manually. Most of the work has been carried out manually; therefore, the system will be limited to the working boundary of the customer as there is no communication with any external interface of the system.
Application Title Client Title Modules Time Frame
ERP System General International Co. - Accounts - Personal + Payroll- Inventory- Export Invoicing- Website 120 Days

Table 4.1: Clients Demand

A number of factors influenced the client's decision to go with us for this important project:- Customer Satisfaction, because we are PSEB registered members. Already successfully delivered many - Critical systems.- Vast skills of our team and consultant members.- Two-month Maintenance period.- Cost effective solution using customized template models.

Figure 4.1: Selection Process

Here we need to analyse client's actual business process formally. Because we have large amounts of historic maintenance data from different projects. Our team was totally independent to suggest our clients all required Standard sub-system processes.

Figure 4.2: Our Requirements

The project started with a system study by our Analyst team. The development started from making of Accounts section (both receivable and payables) module because other modules were dependent over it. Our team consisted of the one-project manager, one-senior software engineer, three system analysts and four other team members. This project has followed all necessary quality guidelines during its entire lifecycle. Communication between PSEB Project manager and our team is through e-mails, weekly and ad-hoc visits of member from PSEB team to tract our monthly progress. Here we have maintained data backups on daily basis to avoid disasters.

Figure 4.3: Project Methodology

Location - Korangi Industrial area Company Management hierarchy consist of following posts:- General Manager- Production Manager- Production In-charge- Merchandisers- Quantity Controller- Pattern Master- Manager Accounts- Office AssistantProduction Facility:- We have 100 Machines, including a variety of special machines capable of making Jeans, Shirts, Pants, Blouses, Jumpers, and Shorts etc.Production Capacity:- 25000 Pieces to 35000 Pieces per month.Processing:- Latest Treatment Technology is used.Land Holding of Factory:- 5840 Sq Yards.Construction Area of Factory:- 43000 Sq Ft.Main Market:- We have been doing business in the US, Canada and Europe.Quota Holdings:- Categories 340, 341, 336, 347, 647, 359-C, 6.Stitching:- 50% is on Chain Stitching.Lead Time:- Categories 340, 341, 336, 347, 647, 359-C, 6.Fabrics- As our country is specialized in Twills, Drills, Denim, Solids Plaid, Stripes, Canvas, Sheeting, Madras Plasids, Fannels and Textile Fabrics etc.We are using all these fabrics etc. as per orders from our buyers and as well we can use Imported fabrics.

Figure 4.4: Business Information

Time to deployment Project meet delivery dead line strictly.Development cost savingsDue to past experience and customisable modules the cost savings were unexpectedly high.Operational savingsAll internal Operations are standardized now and after reasonable training our clients are enjoying efficient solution for their business.

Figure 4.5: End Result

PSEB -- (Pakistan Software Export Board) Financer -- PSEB Client -- General International Co. Supplier -- Cyber Angels "IT Solution Providers" SRS -- Software Requirement Specifications

Figure 4.6: Definitions and Acronyms

Hardware1. Server Machine1. Pentium 4 Processor2. Intel Mother Board3. 128 MB RAM4. Hard Drive 40 GB5. 10/100 LAN Card6. 1.44 MB Floppy Drive7. 52 X CD ROM Drive8. ATX Casing9. SVGA Colour Monitor2. Work Station(s)1. Pentium I/II/III Processor2. Intel Mother Board3. 32/64 MB RAM4. Hard Drive 1 - 40 GB5. 10/100 LAN Card6. ATX Casing7. SVGA Colour MonitorSoftware1. Operating System1. Microsoft Windows Server 2000 (for Server Machine)2. Microsoft Windows 95/98 (for Work Station(s))2. Database1. Microsoft SQL Server 20003. Front-end1. Microsoft Visual Basic 64. Reports1. Crystal Report 6/7/85. Other 1. Microsoft Office 2000 Professional Edition

Figure 4.7: Hardware and Software requirements

Project Life Cycle Phases1. Analysis2. Designa. Data design ERDb. Architecture design Client Serverc. Interface design GUId. Component design3. Implementation4. Testinga. Unitb. Integrationc. Stress testingFinal Work Breakdown Structure1. Inventory Management System: 7 - Screens and 9 Reports2. Human Resource System: 10 Screens and 6 Reports 3. Account Payable System: 6 Screens and 7 Reports4. Account Receivable Systems: 3 Screens and 8 Reports5. General Ledger System: 6 Screens and 13 Reports6. Export Invoice: 4 Screens and 7 Reports7. Web Site

Figure 4.8: Project Phases and WBS

1. INVENTORY MANAGEMENT SYSTEM (IMS)Purchase Contract is the first document that is generated between Supplier and General International. The No. Of Item(s) required for Specific Job are recorded in Purchase Contract. After that when the Supplier supplies the ordered item, Inspection Report is made after inspection, to check the quality as well as quantity of Items supplied. If items are found according to standard criteria, then GIRN (Goods Inward Receipt Note) is prepared which in turn raises the Stock Inventory. But if items are not found according to Desired standard, Gate pass is being made through which items are returned back to Supplier. Whenever any department requires raw material from Stock, It raises a document called Issue Requisition Slip. In reply Store issues the items to concerned department along with Material Issue Note. When Finished Good is prepared, Finished Good Inventory is raised.This application bears following flow of entities:I. Purchase ContractII. Inspection ReportIII. Gate pass (Purchase Return)IV. GIRN (Goods Inward Receipt Note)V. Issue Requisition SlipVI. Material Issue NoteFlaws in existing system:The flaw in this system is that after inspection, if material does not meet the desired criteria, then it is returned back to supplier without keeping any track in existing system. When the consignment enters the premises, its item wise quantity is not recorded, so gate pass of rejected items cannot be prepared. The position and job wise quantity in hand of each item is also not maintained.Proposed Validation(s) for automated system:Validations that will be incorporated during development and implementation of software will include date and time validation, quantity flow in each process, unit of measure conversions and referential integrity. To remove the flaws from the existing system entity flow should by as followI. Purchase ContractII. Inward Delivery Challan (proposed)III. Inspection ReportIV. Gate pass (Purchase Return)V. GIRN (Goods inward Receipt Note)VI. Issue Requisition SlipVII. Material Issue Note1.1 ReportsI. Purchase ContractII. Inward Delivery ChallanIII. Inspection ReportIV. Item ListingsV. Inventory in handVI. Item Minimum Level ReportVII. 2Item Maximum Level ReportVIII. Item Reorder Level ReportIX. Suppliers List2. HUMAN RESOURCES AND PAYROLL SYSTEMCandidate Resume/Information is the first document of Personnel System. Whenever company has vacancy, it calls suitable candidate(s) from previously dropped Resume. If candidate is found suitable then company offers him/her job. Upon acceptance of job offer, the candidate is given Appointment Letter. The next step is Posting/Transfer of new/existing employee. There are no salary heads in existing system. Tax is also not deducted from Employees. Advance against salary and Loan exist in current manual system. Half day and Late coming deduction is also performed in current system. Salary is prepared on 1st of next month. This application bears following flow of entities:I. Candidate InformationII. Interview CallIII. Appointment LetterIV. Posting/ TransferV. AttendanceVI. Advance against salaryVII. LoanVIII. Half day and Late coming deductionIX. Salary PreparationX. Pay Slip2.1 Reports:I. Interview Call LetterII. Appointment LettersIII. Employee List (Name Wise)IV. Employee List (Designation Wise)V. Employee Pay SlipVI. Leaves Transaction Report3. ACCOUNTS PAYABLE SYSTEMPurchase Contract is the first document generated in this system. When Supplier supplies items, it also gives Purchase Invoice with it. If items do not meet standard criteria, Gate pass is prepared and items are returned. Next step is Payment .If payment is made before items inspection, and items are returned, then Debit Note is prepared. This application bears following flow of entities:I. Purchase Contract (Same for Inventory Management System)II. Purchase InvoiceIII. PaymentsIV. Gate pass (Same for Inventory Management System)V. Debit NoteVI. Voucher postingFlaws in existing system:The flaw in this system is that Payment is made but company does not know which invoices actually it is knocking off. So ageing is not maintained. The automated system will maintain track of ageing of invoices.3.1 Reports I. Aged Accounts PayableII. Purchase JournalIII. Purchase OrderIV. Purchase Order (By Location, by Department)V. Payment registerVI. Vendors ListVII. Vendors Phone Book4. ACCOUNTS RECEIVABLE SYSTEMSales contract is the first document generated between General International and Buyer. Sales Invoice is the second document of this system. Payment is the third process of this system. This application bears following flow of entities:I. Sales Contract II. Sales InvoiceIII. ReceivablesFlaws in existing system:Ageing is not maintained in manual system. The automated system will maintain track of ageing of invoices.4.1 Reports I. Aged Accounts ReceivableII. Sales JournalIII. Sales ContractIV. Party LedgerV. Invoice Detail ListingVI. Master Customer List (Active)VII. Master Customer List (In Active)VIII. Customer Phone Book5. EXPORT INVOICING SYSTEMSales Contract is the first document generated between Buyer and General International. After production of Garments mentioned in Sales Contract, Packing list is prepared which contains size, colour, no. of cartons in current consignment. Customer Invoice is next document in current system flow, which contains information regarding No. of pieces, rate/ piece and total value of Sales Contract. Custom Invoice is also generated for Custom, which contains value of Sales Contract, and it is generated for the purpose of Rebate claim. Accounts department books the receivable from Buyer. This application bears following flow of entities:I. Sales Contract II. Packing ListIII. Customer InvoiceIV. Custom Invoice5.1 Reports I. Sales Contract II. Packing ListIII. Customer InvoiceIV. Custom InvoiceV. Customer's Year to DateVI. Order HistoryVII. Print Sales Contract 6. GENERAL LEDGER SYSTEM (GL)Chart of Accounts is the first process through which levels of Accounts and financial statements are determined. Voucher types such as cash payment, cash receipt, bank payment, bank receipt, sales journal, purchase journal, general voucher. Fiscal year is used to set the financial year. Opening balances are used to set the opening amount, which can be either8 debit or credit. Voucher transactions is the process through which voucher are generated as well as printed. These vouchers can also be posted by this process, which reflects the balances in financial statements such as Trial balances, Profit and Loss statement, Balance Sheet etc. YEAR-END Process is process, which closes the financial year and transfers the closing balance of that fiscal year to the opening balance of next fiscal year. This application bears following flow of entities:I. Chart of AccountsII. Opening BalancesIII. Fiscal YearIV. Voucher TypesV. Voucher TransactionsVI. Year end Process6.1 Reports I. Journal/ TransactionsII. General Journal III. Trial Balance (Opening)IV. Trial Balance (6 Columns)V. Trial Balance (Closing)VI. Profit and Loss statementVII. Balance SheetVIII. Ageing of Accounts Payable and ReceivableIX. Voucher ListX. Voucher PrintingXI. Accounts LedgerXII. Bank BookXIII. Cash Book 7. INTEGRATED PLAN WITH ACCOUNT DEPARMENTFigure bellow is the proposed plan for integration of all systems.8. WEBSITEA website is required for promotion of products for general international. With the help of proposed website, buyers from all over the world can access general international's products, its quality and can contact for any further queries that they may have.

Figure 4.9: Information description

COCOMO' Basic Model for Semi-detached type of projectsModel: The Basic COCOMO model is a static, single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code (LOC).Software project ab bb cb db
Organic (relatively small, simple software projects in which small teams with good application experience work to a set of less than rigid requirements) 0.8 1 1.5 .32
Semi-detached (an intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements) 1.1 1.10 1.5 .29
Embedded (software project that must be developed within a set of tight hardware, software and operational constraints) 1.6 1.10 1.5 .30
The COCOMO models are defined for three classes:Note: Component data a, b, c and d is driven according to Pakistani software development market.E = ab KLOC bbD = cb E dbWhere E is the effort applied in person-months, D is the development time in chronological months and KLOC is the estimated number of delivered lines of code for the project (express in thousands). ab and cb and the exponents bb and db are given in above Table.E = 1.1 (KLOC) 1.10 = 1.1(30) 1.10 = 46 person-monthsTo compute project duration, we use the effort estimate described above: D = 1.5 E 0.29 = 1.5 (46) 0.29 = 4.5 monthsThe value for project duration enables the planner to determine a recommended number of people, N, for the project: N = E/D = 46/5 9 peoples Total Cost calculated = No of months [(No of peoples expenses per month * Total No of People) + Other Expenses per month]Total cost calculated = 4 [(10,000 * 9)+3000] = 372,000 Rupees

Figure 4.10: Estimations

Project Manager --1Senior Software Engineer --1System Analyst --3Programmer --4

Figure 4.11: Team members

Earned Value Analysis (Parameters for assessing progress Quantitatively)1. EV= measure of progress2. BCWS=Budgeted cost of work scheduled each task3. BAC= sum (BCWS k), Budgeted cost of all k no of work tasks 4. BCWP=sum (BCWS k) up till time t, Budgeted cost of work performed 5. SPI = BCWP/BCWS, schedule performance index, value close to 0.1 indicate effective execution of project schedule. 6. SV= BCWP - BCWS, schedule variance7. Percent complete = BCWP/BCWS, provide quantitative indication of % of work should have been completed by time t8. Percent schedule for completeness = BCWS/BAC, provide quantitative indication of % of completeness of project at time t9. ACWP= Sum (effort actually expanded on work tasks that have been completed by a point in time on project schedule--h), Actual cost of work performed 10. CPI = BCWP/ACWP, cost performance index, value close to 0.1 indicate project is within its defined budget.11. CV = BCWP - ACWP, Cost Variance, absolute indication of cost saving against planned cost.

Figure 4.12: Earned Value Analysis

Figure 4.13: Gant chart to make time lines for tracking milestone

Figure 4.14: Task Network diagram PERT chart

Risk IdentificationRisk Item Check List a focus on Product specific Predictable risks includes following sub category:1. Product size - No 2. Business Impact -- No3. Customer characteristics -- No4. Process definition --No5. Development environment --No6. Technology to be build --No7. Staff size and experience -NoRisk Component and Drivers list along with their probability of occurrence.Risk Drivers, actions that effect risk components' performance cost support and schedule.Risks Components Category of Risk Probability Impact RIS No
Funding will be lost Cost 30% 1 001
Staff turnover will be high Support 80% 2 002
Risk components include:1. Performance: product meets requirement2. Cost risks: project budget increase3. Support Risks: easy enhancement in resultant software 4. Schedule Risks: component deliver in timeCategory made for drivers:1. Catastrophic - tragic actions --12. Critical - important --23. Marginal - minor --34. Negligible - unimportant - 4Risk Projection/Estimation, Risk rating based on probability of its occurrence Risk Table 1. Scale was established to remark possibility of a risk2. Mark out consequences/penalty of the risk3. Estimate the impact of risk on product or project (risk categories as defined above) Note over all risk accuracy for no misunderstandings.Risk Information Sheet
Risk ID: 002 Date: 19/3/02 Probability: 80% Impact: Critical
Reason: One of the programmers left and moves to another company.RE estimated: 50,000 Rs. approx.Trigger: Mitigation steps unproductive as of 25/2/02Current Status: Interviews for new hiring started

Originator: Project Manager Assigned: Human Resources Manager
Cut-off line: high impact value limit has made so that if any risk had crossed that line than it can be managed, pointer value of Risk information sheet was assigned in RMMM column.--- If risk probability increases more than 80% Assessment Risk Impact ---consequences or penalty of riskRisk Exposure was calculated using probability of risk occurrence and Cost that risk should occur on project RE = P * C, Total risk exposure cost provide mean for adjusting final cost estimate or predict probable increase in resources required at various point during scheduling.Risk assessment for accuracy of estimates was made that may help in thinking about its control strategiesA risk component as given above was taken as a referent level to make decision if degradation occurs and breakpoint will come than project may be terminated. Risk Refinement -condition transition consequences CTC used to refine risk in set of more detailed risk, its possible in case of COTS. - No refinement doneRisk Mitigation Monitoring and Management, strategy for dealing with risks contain Risk avoidance, for proactive approach to risk avoidance is best strategy; risk mitigation plan was made to reduce turn over. Turnover Li * Xi likelihood and impact for risk Ri. Risk monitoring is done to identify more or less likely risks and to take possible actions before risk impact increased.Risk management, if risks fail than we did backup activity ---- new hiring.

Figure 4.15: Risk Management

Figure 4.16: Analysis technique, Statistical Process Control (XmR, to drive limit and analyse data), monitoring performance of selected sub process, Measures selection, defect density a measure of product quality (sample graph)

Table 4.2: Quality and Process-performance objectives QPO's (sample values)

Project Process Performance Baseline
Life Cycle Phase Project's Measures Process ID Measure Specification from projects QM Mean UCL LCL Units
Test PEM20 DDr .0005 + - .00005 .3168 1.1674 0.5339 Pages
Test PEM20 DDt .0005 + - .00005 .0604 0.3247 0.2040 Pages

Table 4.3: Manage Project Performance (sample values)
4.2 Project Management Steps
This framework comprise of three basic and four advance processes including project planning, project monitoring and control, supplier agreement management, integrated project management, risk management and quantitative project management. First we go through generic practices then discuss specific goals one by one in detail.
4.3 Generic Goals and Increasing Capability levels
As generic practices are the checkpoints for reminding us that we have done things right. Performing each generic goal is equivalent to improving its corresponding level of capability. Below discussed is a brief relation ship between capability levels and their respective generic goals, which we have to follow after completion of specific goal of each Sub process areas.
Capability level number zero is known as Incomplete. It is a process that is either not performed or partially performed. One or more of the specific goals of the process area are not satisfied.
To achieve generic goal one, we have to perform base practices i.e. its corresponding specific practices. We have to perform generic goal one in order to achieve Capability level one which is known as Performed. A critical distinction between an incomplete process and a performed process is that a performed process satisfies all of the specific goals of the process area.
To achieve generic goal two i.e. Institutionalize a managed process; we have to perform all previous goals and following practices i.e. to establish an organizational policy, plan the process, provide resources, assign responsibility, train people, manage configurations, identify and involve relevant stakeholders, monitor and control the process, objectively evaluate adherence and review status with higher level management. Generic goal two corresponds to capability level two which is known as Managed. Critical distinction between a performed process and a managed process is the extent to which the process is managed. A managed process is Planned (capability level 1) and the performance of the process is managed against the plan. Corrective actions are taken when the actual results and performance deviate significantly from the plan. A managed process achieves the objectives of the plan and is institutionalized for consistent performance.
To achieve generic goal three i.e. Institutionalize a defined process; we have to perform all previous goals and following practices i.e. to establish a defined process and collect improvement information. Generic goal three corresponds to capability level three, which is known as Defined. A defined process is a managed (capability level 2) process that is tailored from the organization's set of standard processes according to the organization's tailoring guidelines, and contributes work products, measures, and other process-improvement information to the organizational process assets.
To achieve generic goal four i.e. Institutionalize a Quantitatively Managed Process we have to perform all previous goals and following practices i.e. to establish quantitative objectives for the process and stabilize sub process performance. Generic goal four corresponds to capability level four which is known as Quantitatively Managed. A quantitatively managed process is a Defined (capability level 3) process that is controlled using statistical and other quantitative techniques.
To achieve generic goal five i.e. Institutionalise an Optimising Process; we have to perform all previous goals and following practices i.e. to ensure continuous process improvement and correction of root causes of problems. Generic goal five corresponds to capability level five which is known as Optimising. An optimising process is a quantitatively managed (capability level 4) process that is changed and adapted to meet relevant current and projected business objectives.
As specific goals and practices are the actual project management steps that a project manager should follow therefore they are discussed in more detail here.
4.4 Project Planning
In this process area we have to perform three specific goals.
4.4.1 Establish Estimates
This is the first goal to achieve by performing its four specific practices.
First practice is Estimating the Scope of the Project. Its typical work products include: Descriptions of tasks, Work package, and Work Breakdown Structure (WBS).
See figure 4.8 for WBS, in this project it permits identification of the following items risks and their mitigation tasks, tasks for deliverables and supporting activities, tasks for skill and knowledge acquisition, tasks for development of needed support plans, such as configuration management, quality assurance, and verification plans. Work packages were identified in sufficient detail to specify estimates of project tasks, responsibilities, and schedule. The top-level WBS is intended to help in gauging the project work effort in terms of tasks and organizational roles and responsibilities. The amount of detail in the WBS at this more detailed level helps in developing realistic schedules, thereby minimizing the need for management reserve. The main divisions of the system are: General Ledger, Accounts Payable, Accounts Receivable, Inventory Management System, Export Invoicing System, Payroll System and Website.
Second practice is Establishment of estimates of the Work product and task attributes. Its typical work products include: Technical approach adopted, Size and complexity of tasks and work products, Estimating models and Attribute estimates.
Technical approach that was taken is a distributed client server application. Work products for which size estimates were made included: Non-deliverable work products daily activity sheets, Documents SRS, System Operational Manuals and Operational Modules. Method that we have used is based on historical data and lines of code for this software.
Third Practice is Defining Project Life Cycle. Its typical work product includes: Project Life cycle Model.
RAD model was used because of following reasons: shorter development, business focus, lower cost and stakeholder commitment.
Fourth practice is Determination of Estimates of Effort and Cost. Its typical work product includes: Estimation grounds, Project effort estimates and Project cost estimates.
Effort and cost inputs used for estimating include the following: Judgmental estimates provided by an expert or group of experts, Technical approach, WBS, Size estimates of work products and anticipated changes, Selected project life-cycle model and processes, Life-cycle cost estimates, Skill levels of managers and staff needed to perform the work, Knowledge, skill, and training needs, Facilities needed (e.g., office and meeting space and workstations) and the Level of security required for tasks, work products, hardware, software, personnel, and work environment. See figure 4.10 above for cost and effort estimation.
4.4.2 Developing a Project Plan
This is the second goal to achieve by seven specific practices.
First practice is Establishment of the Budget and Schedule. Its typical work product includes: Project schedules, Schedule dependencies and Project budget.
Microsoft project 2000 was used to generate basic scheduling and dependency charts i.e. Gantt chart and PERT chart (Program Evaluation and Review Technique). Because Time frame was very short and critical that is why Corrective action criteria is when ever any task may take four more days as compared to its scheduled time, after this time we have taken immediate action over it. Which include revising the original plan, establishing new agreements, or including mitigation activities within the current plan. See figure 4.13 above for Gantt chart and figure 4.14 for PERT chart.
Second practice is Identification of Project Risks. Its typical work products include: Identified risks, Risk impacts and probability of occurrence and Risk priorities
We had used following risk identification and analysis tools: Risk assessments and Checklists. Risks were document properly, and agreements were obtained with relevant stakeholders on the completeness and correctness of the documented risks. Major risks involved were: Unavailability of any of team member or Stakeholder (Manager of Cyber Angels), Shortage in Allocated resources. Identified risks were revised when: New risks were identified, Risks become problems and Risks get retired. See figure 4.16 above for the summary of risk management.
Third practice is Plan for Data Management. Its typical work products include: Data management plan, Master list of managed data, Data content and format description, Data requirements lists for acquirers and for suppliers, Privacy requirements, Security requirements, Security procedures, Mechanism for data retrieval, reproduction, and distribution, Schedule for collection of project data and Listing of project data to be collected.
To ensure privacy and security of the data related to project plan and management only access was allowed to our data resource manager and our project manager on relevant dates. Documented issuance dates were also monitored separately. Separate files were maintained to store every record including daily task sheet.
Fourth practice is Plan for Project Resources. Its typical work products include: WBS work packages, WBS task dictionary, Staffing requirements based on project size and scope, Critical facilities/equipment list, Process/workflow definitions and diagrams and Program administration requirements list.
A well-defined process was identified, defined, and coordinated with all the relevant stakeholders to ensure efficient operations during project execution to manage project. The staffing of a project was done after the decomposition of the project requirements into tasks, roles, and responsibilities for accomplishing the project requirements as lay out within the work packages of the WBS. By considering the knowledge and skills required for each of the identified positions, as defined in the specific practice plan for needed knowledge and skills. A list was compiled as shown in figure 4.7 of hardware and software requirements that contain facilities, equipment, and parts (e.g., number of computers for the personnel working on the project, software applications, office space, etc.).
Fifth practice is Plan for Needed Knowledge and Skills. Its typical work products include: Inventory of skill needs, Staffing and new hire plans and Databases (e.g., skills and training).
The required knowledge and skills were already identified before staffing team member. No training was as such required. Study of CMMI's project management process area was required by the Project manager to fulfil all required steps. Mechanisms for providing needed knowledge and skills were attached with identification and removal or risks include: Staffing and New hires no out sources were required. Whole project was developed in-house. All above selected criteria was mentioned in our project plan file.
Sixth practice is Plan for Stakeholder Involvement. Its typical work products include: Stakeholder involvement plan.
Material that was included in the plan for stakeholder interaction include the following: List of all relevant stakeholders, justification for stakeholder involvement like manager Cyber Angels was responsible to provide in-house resources that includes machines staffing support software's etc and like our client was responsible and committed to provide full cooperation during system analysis and regression testing phase at client site. Relationship between relevant stakeholders was also defined like for new staffing Project Manager was committed to interact with manager Cyber Angels to hire new team members.
Seventh practice is Establishing the Project Plan. Its typical work products include: Overall project plan.
Software project plan document is the one, which addressed all relevant planning items that were necessary to achieve the mutual understanding, commitment, and performance of individuals, groups, and organizations that must execute or support the plans. The plan generated for the project has defined all aspects of the effort, tying together in a logical manner: project life-cycle considerations; technical and management tasks; budgets and schedules; milestones; data management, risk identification, resource and skill requirements; and stakeholder identification and interaction. Infrastructure descriptions include responsibility and authority relationships for project staff, management, and support organizations.
4.4.3 Obtain Commitment to the Plan
This is the third goal to achieve by performing its three specific practices.
First practice is Reviewing Plans that Affect the Project. Its typical work products include: Record of the reviews of plans that affect the project.
Separate records were maintained in a project plan file if any of project plans were reviewed.
Second practice is Reconciliation of Work and Resource Levels. Its typical work products include: Revised methods and corresponding estimating parameters (e.g., better tools, use of off-the-shelf components), Renegotiated budgets, Revised schedules, Revised requirements list and Renegotiated stakeholder agreements.
To obtain commitment from relevant stakeholders, it is really important to resolve any differences between the estimates and the available resources, by lowering or deferring technical performance requirements, negotiating more resources, finding ways to increase productivity, outsourcing, adjusting the staff skill mix, or revising all plans that affect the project or schedules.
Third practice includes Obtaining Commitment Plan. Its typical work products include: Documented requests for commitments and Documented commitments.
Obtaining commitment involves interaction among all relevant stakeholders both internal and external to the project. The individual or group making a commitment with confidence that the work can be performed within cost, schedule, and performance constraints. Often, a provisional commitment is adequate to allow the effort to begin and to permit research to be performed to increase confidence to the appropriate level needed to obtain a full commitment. Needed support and negotiate commitments with relevant stakeholders was first identified. WBS was used as a checklist for ensuring that commitments were obtained for all tasks. The stakeholder interaction plan has identified all parties from whom commitment was to be obtained. All organizational commitments were documented, both full and provisional, ensuring appropriate level of signatories with senior management as appropriate.
4.5 Project Monitoring and Control
In this process area we have to perform two specific goals.
4.5.1 Monitor Project Against Plan
This is the first goal to achieve by performing its seven specific practices.
First practice is Monitoring Project Planning Parameters. Its typical work products include: Records of project performance and Records of significant deviations.
For actual completion of activities and milestones, weekly measurements were performed that included the comparison of the actual completion of activities and milestones against the schedule documented in the Gantt chart of software project plan and identification of significant deviations from the budgets in the project plan. Effort and cost monitoring typically includes periodically measuring the actual effort and cost expended and staff assigned by comparing actual effort, costs, staffing, and training to the estimates and budgets documented in the software project plan and identification of significant deviations from the budgets in the project plan. The actual attributes of the work products were measured on a monthly basis. Tasks, such as size or complexity and the changes to the attributes by comparing the actual attributes of the work products and tasks and the changes to the attributes to the estimates documented in the project plan, identified significant deviations from the estimates in the project plan. Provided resources were monitored and used that included all hardware and software resources as given in figure 4.7, used in design, manufacturing, testing and operation and project staff. Knowledge and skills of project personnel were also monitored that included measuring weekly the growth of knowledge and skills by project personnel, particularly the project manager, by comparing the actual training obtained to that documented in the project plan and identifying significant deviations from the estimates in the project plan. At the end of each monitoring activity, significant deviations in the project planning parameters were documented and attached with the software project plan.
Second practice is Monitoring Commitments. Its typical work products include: Records of commitment reviews.
Regular review of commitments (both external and internal) was taken and those commitments were identified that had not been satisfied or which were at a significant risk of not being satisfied, such as a delay in hiring. The results of the commitment reviews were documented previously. See RIS in figure 4.16 for risk management.
Third practice is Monitoring Project Risks. Its typical work products include: Records of project risk monitoring.
The documentation of the risks in the context of the project's current status and circumstances was reviewed weekly and revised as additional information became available to incorporate changes. Communication about risk status to relevant stakeholders was performed regularly because its delay mostly resulted in change in the probability that the risk occurred.
Fourth practice is Monitoring of Data Management. Its typical work products include: Records of data management.
Data management activities against their description in the project plan were weekly reviewed, identified and significant issues and their impacts were documented.
Fifth practice is Monitoring Stakeholder Involvement. Its typical work products include: Records of stakeholder involvement.
The status of stakeholder involvement was reviewed weekly. Significant issues and their impacts were identified and documented.
Sixth practice is Conducting Progress Reviews. Its typical work products include: Documented project review results.
Daily progress sheets were maintained for regular communication to find out the status on assigned activities and work products to relevant stakeholders, this was done to keep stakeholders informed. Managers and team members within the organization were included in the reviews. Results of collecting and analyzing measures were reviewed for controlling the project. Significant issues and deviations from the plan were identified and documented. Change requests and problems identified in any of the work products and processes were documented. Results of the reviews were also documented at the end of the review document.
Seventh practice is conducting milestone reviews. Its typical work products include: Documented milestone review results.
Reviews were conducted at meaningful points in the project's schedule, such as the completion of selected stages, with relevant stakeholders. Managers, staff members, and customers within the organization are included in the milestone reviews as appropriate. Review the commitments, plan, status, and risks of the project. Identify and document significant issues and their impacts. Document the results of the review, action items, and decisions. Track action items to closure.
4.5.2 Manage Corrective Action to Closure
This is the first goal to achieve by performing its three specific practices.
First practice is Analysing Issues. Its typical work products include: List of issues needing corrective actions.
Issues were gathered for analysis from reviews and the execution of other processes like: Issues discovered through performing verification and validation activities, Significant deviations in the project planning parameters from the estimates in the project plan, Commitments (either internal or external) that have not been satisfied, Significant changes in risk status, Data access, collection, privacy, or security issues, Stakeholder representation or involvement issues and Issues were analysed to determine need for corrective action. Corrective action was required when the issue, if left unresolved, might prevent the project from meeting its objectives.
Second practice is Taking Corrective Action. Its typical work products include: Corrective action plan.
Appropriate actions were determined and documented which were needed to address the identified issues, like: Modifying requirements, Renegotiating commitments and Revising project risks. Actions to be taken were reviewed and agreements obtained with relevant stakeholders. Changes were negotiated to internal and external commitments.
Third practice is Managing Corrective Action. Its typical work products include: Corrective action results.
Corrective actions were monitored for completion. Results of corrective actions were analyzed to determine the effectiveness of the corrective actions. Appropriate actions to correct deviations from planned results for corrective actions were determined and documented. Lessons learned as a result of taking corrective action were inputted to planning and risk management processes.
4.6 Supplier Agreement Management
In this process area we have to perform two specific goals.
4.6.1 Establish Supplier Agreement
This is the first goal to achieve by performing its three specific practices.
First practice is Determination of Acquisition Type. Its typical work products include: List of the acquisition types that will be used for all products and product components to be acquired.
There are many different types of acquisition that can be used to acquire products and product components that will be used by the project like: Purchasing commercial off-the-shelf (COTS) products, Obtaining products through a contractual agreement, Obtaining products from an in-house vendor and Obtaining products from the customer.
Second practice is Selection of Suppliers. Its typical work products include: List of candidate suppliers, Preferred supplier list, Rationale for selection of suppliers, Advantages and disadvantages of candidate suppliers, Evaluation criteria and Solicitation materials and requirements.
The only supplier involved in this project was a computer hardware shop for buying machines as given in figure 4.7 hardware and software requirements for the clients and to help them in finding vendors for implementing LAN Network for the client to deploy this system. Finally we refer the selected vendor to our clients.
Third practice is Establishment of Supplier Agreements. Its typical work products include: Statements of work, Contracts, Memoranda of agreement and licensing agreement
Vendor prepared related delivery and service documents to the client for satisfactory service. The supplier agreement contained a statement of work, a specification, terms and conditions, a list of deliverables, a schedule, a budget, and a defined acceptance process. All parties were made to understand the agreement and consent to all requirements before implementing the agreement.
4.6.2 Satisfy Supplier Agreement
This is the third goal to achieve by performing its four specific practices.
First practice is Reviewing COTS products. Its typical work products include: Trade studies, Price lists, Evaluation criteria, Supplier performance reports and Reviews of COTS products.
Supplier performance was tracked before mid-completion of our ongoing project to guarantee timely LAN installation before the deployment of this project.
Second practice is Execution of the Supplier Agreement. Its typical work products include: Supplier progress reports and performance measures, Supplier review materials and reports, Action items tracked to closure and Documentation of product and Document deliveries.
Supplier progress was monitored during Quality assurance process. Final review was conducted with the supplier as specified in the supplier agreement. Results of management reviews were taken to improve the supplier's performance and to establish and nurture long-term relationships with preferred suppliers.
Third practice is Acceptance of the Acquired Product. Its typical work products include: Acceptance test procedures, Acceptance test results and Discrepancy reports or corrective action plans.
Here acceptance procedure was that the installed network and hardware must perform accurately after installing our system. After verifying that the acquired products fulfilled their requirements, confirmation was made that the non-technical commitments associated with the acquired work product were satisfied. That included confirmation of the appropriate license, warranty, ownership, usage, and support or maintenance agreements is in place and that all supporting materials are received. Acceptance was finally documented after satisfactory verification and confirmations.
Fourth practice is Transitioning of Products. Its typical work products include: Transition plans, Training reports and Support and Maintenance reports.
It was ensured that distribution, and usage of the acquired products are performed according to the terms and conditions specified in the supplier agreement or license.
4.7 Integrated Project Management
In this project there was no remarkable difference between standardized and defined processes because of the availability of customised modules and no major changes in our client's standard business processes. In this process area we have to perform two specific goals.
4.7.1 Use the Project's Defined Processes
This is the first goal to achieve by performing its five specific practices.
First practice is Establishment of the Project's Defined Process. Its typical work products include: The project's defined process.
Selection was made for a life-cycle model from those available from the organizational process assets. Here already only those standard processes from the organization's set of standard processes were taken which best fulfill the need of the project. No major tailoring was required so there was no need to seek approval to deviate from what was required by the organization. Because we were already using lessons-learned (documents, templates, example documents and estimating models) from our asset library, so projects standard processes were taken as project's defined processes. Peer review was conducted for the project's defined process.
Second practice is Use of Organizational Process Assets for Planning Project Activities. Its typical work products include: Project estimates and Project plans.
No new estimates and plans required at this stage because no dissimilarities were found in the work product and task attributes, application domain, design approach, operational environment and in experience of the people.
Third practice is Integration of Plans. Its typical work products include: Integrated plans.
Here we integrated all plans that affect the project with the project plan that includes the following: Quality assurance plans, Configuration management plans, Risk management strategy and Documentation plans.
This thesis is only highlighting project management related process areas so process, support and engineering process areas were left that were involved in this project (like Quality assurance plans, Configuration management plans). Because of complete analysis no product and project interface risks were identified that usually included incomplete interface descriptions, unavailability of tools or test equipment, and no COTS were required to buy. Peer reviews on the work products of the project's defined process were taken for verification. No additional training plans were required that typically involved negotiating with the organizational training group the support they will provide. Objective entry and exit criteria was established during the analysis phase to authorize the initiation and completion of the tasks described in the work breakdown structure.
Fourth practice is Management of the Project using the Integrated Plans. Its typical work products include: Work products created by performing the project's defined process, Collected measures ("actual") and progress records or reports, Revised requirements, plans, and commitments and Integrated plans.
Integrated Plan was on focus for actual implementation of project with no changes in standard business process. Monitoring and control activities are then transferred to it with understanding of the relationships among the various tasks and work products of the project's defined process, and of the roles to be performed by the relevant stakeholders, along with well-defined control mechanisms (e.g., peer reviews), achieves better visibility into the project's performance and better control of the project. Weekly reviews were taken to meet the project's needs and to support coordination. No addition of new tools, no additional networks, equipment, training, and support were required. No alignments were required.
Fifth practice is Contribution to the Organizational Process Assets. Its typical work products include: Proposed improvements to the organizational process assets, Actual process and product measures were collected from the project and documentation (e.g., exemplary process descriptions, plans, training modules, checklists, and lessons learned).
Remarkable improvements were proposed to organizational process assets.
4.7.2 Coordinate and Collaborate with Relevant Stakeholders
This is the second goal to achieve by performing its three specific practices.
First practice is Management of Stakeholder Involvement. Its typical work products include: Agendas and schedules for collaborative activities, Documented issues (e.g., issues with customer requirements, product and product-component requirements, product architecture, and product design) and Recommendations for resolving relevant stakeholder issues.
Coordination was maintained with the relevant stakeholders who were supposed to participate in the project's activities. The relevant stakeholders were already being identified in the project plan. Recommendations were developed here and coordination was made for actions to resolve misunderstandings and problems with the product and product-component requirements, product and product-component architecture, and product and product-component design.
Second practice is Manage Dependencies. Its typical work products include: Defects, issues, and action items resulting from reviews with relevant stakeholders, Critical dependencies, Commitments to address critical dependencies and Status of critical dependencies.
Separate reviews were conducted with relevant stakeholders like manager Cyber Angels to identify each critical dependency. Also, the establishment of needed dates and plan dates for each critical dependency based on the project schedule reviews were completed after the review agreements were made on the commitments to address each critical dependency with the people responsible for providing the work product and the people receiving the work product.
Third practice is Resolve Coordination Issues. Its typical work products include: Relevant stakeholder coordination issues and Status of relevant stakeholder coordination issues.
Issues were identified and documented regarding late critical dependencies and commitments as well as product and product-component requirements, design defects and product-level problems and the unavailability of critical resources or personnel. Issues always are notified and discussed with relevant stakeholders to resolve them. If not, resolved tracks were made and discussed further for remedy.
4.8 Risk Management
In this process area we have to perform three specific goals.
4.8.1 Prepare for Risk Management
This is the first goal to achieve by performing its three specific practices.
First practice is Determination of Risk Sources and Categories. Its typical work products include: Risk source lists (external and internal) and Risk categories list.
First we determine risk sources. Our risk source list only contains one major risk, which is unavailability of our team member. See figure 4.16 risk management for details.
Second practice is Defining Risk Parameters. Its typical work products include: Risk evaluation, categorization, and prioritization criteria and Risk management requirements (control and approval levels, reassessment intervals, etc.).
Thresholds and boundaries were defined for risk category.
Third practice is Establishing a Risk Management Strategy. Its typical work products include: Project risk management strategy. See figure 4.16 risk management for details
4.8.2 Identify and Analyse Risks
This is the second goal to achieve by performing its two specific practices.
First practice is identification of risks. Its typical work products include: List of identified risks, including the context, conditions, and consequences of risk occurrence.
Cost, schedule, and performance risks were examined during all phases of the product life cycle to the extent that they impacted project objectives. Risk with funding levels was associated with this project, which resulted in loosing one of our key members. No Performance risks were identified due to our asset library, which usually includes requirements, analysis and design, functional performance and operation and performance maintenance attributes. One more very outstanding risk was risks associated with strikes but Alhamdulillah no strikes were seen in Karachi. All identified risks were documented with context, conditions, and potential consequences of the risk using standard formats. See figure 4.16 risk management for details.
Second practice is Evaluation, Categorization and Prioritization of risks. Its typical work products include: List of risks, with a priority assigned to each risk.
Each risk was evaluated and assigned values in accordance with the defined risk parameters, which included likelihood, consequence, and thresholds. The assigned risk parameter values were integrated to produce additional measures such as risk exposure, which can be used to prioritise risks for handling. For consequences see figure 4.16 risk management for details. Risks were categorized and grouped according to the defined risk categories. A relative priority was determined for each risk, based on the assigned risk parameters. A clear criterion was used to determine the risk priority. The intent of prioritization was to determine the most effective areas to which resources for mitigation of risks could be applied with the greatest positive impact to the project. See table 4.16 Risk management for details.
4.8.2 Mitigate Risks
This is the second goal to achieve by performing its two specific practices.
First practice is Development of Risk Mitigation Plans. Its typical work products include: Documented handling options for each identified risk, Risk mitigation plans, Contingency plans and List of those responsible for tracking and addressing each risk.
Necessary risk mitigation activities were examined and documented for the benefits they provide versus the resources they will expend. No major contingency plan was made for selected critical risks in the event their impacts are realized.
Second practice is Implementation of risk mitigation plans. Its typical work products include: Updated lists of risk status, Updated assessments of risk likelihood, consequence, and thresholds, Updated lists of risk-handling options, Updated list of actions taken to handle risks and Risk mitigation plans.
Risk handling was performed for those risks judged by observing cut-off lines.
4.9 Quantitative Project Management
Quantitative Project Management was performed to predict and track successful completion of the project as it was already based on quality estimations and historical data. In spite of that, for maintenance/testing process group of this project some specific sub processes were required to be statistically managed. In this process area we have to perform two specific goals.
4.9.1 Quantitatively Manage the Project
This is the first goal to achieve by performing its four specific practices.
First practice is Establishment of the Project's Objectives. Its typical work products include: The project's quality and process-performance objectives.
Organization's (Client Org.) objectives were already reviewed for quality and process performance. Process performance attributes for which needs and priorities were identified include functionality, reliability and maintainability. The Quality Function Deployment (QFD) method was used during analysis phase to identify and translate the needs of customers into technical requirements. Earned value analysis was used for measuring process performance and measurable quality and process-performance objectives QPO's for the project were defined. See figure 4.12 for earned value analysis and table 4.2 for quality and process-performance objectives QPO's. Quality attribute was "Number and severity of defects in the released product". Process performance attributes are: Percentage of defects removed by product verification activities (perhaps by type of verification, such as peer reviews and testing), Defect escape rates, Number and density of defects (by severity) found during the first year following product delivery (or start of service), Cycle time and Percentage of rework time. Appropriate short-term objectives for each life-cycle phase were obtained to monitor progress toward achieving the project's objectives. Like process performance model was used to predict the hidden defects in the delivered product using short-term measures of defects identified during product verification activities (i.e., peer reviews and testing). Quality Function Deployment (QFD) was used to trace the project's quality and process-performance objectives from their source like requirements, organization's quality and process-performance objectives, customer's quality and process-performance objectives, business objectives, discussions with customers and potential customers and market surveys.
Second practice is Composing the Defined Process. Its typical work products include: Criteria used in identifying which subprocesses are valid candidates for inclusion in the project's defined process, Candidate subprocesses for inclusion in the project's defined process and Subprocesses to be included in the project's defined process.
Objectives were identified for quality and process-performance that were required to be statistically managed. Then a criterion was established to select sub-processes on which QPO will be applied. Customer requirements related to quality and process performance were used as the criteria to be utilized in selecting the sub-processes that are the main contributors to achieving the identified QPO and for which predictable performance is important. Here, it wasn't economically justifiable to apply statistical techniques to certain sub-processes. Product and process attributes of the selected sub-processes were identified (defect density, cycle time and test coverage) which were supposed to get measured and controlled.
Third practice is Selection of the Subprocesses that will be Statistically Managed.
Fourth practice is Management of Project Performance.
4.9.2 Statistically Manage Sub process Performance
This is the second goal to achieve by performing its four specific practices.
First practice is Selection of Measures and Analytic Techniques. Its typical work products include: Definitions of the measures and analytic techniques to be used in (or proposed for) statistically managing the subprocesses, Operational definitions of the measures, their collection points in the subprocesses, and how the integrity of the measures will be determined, Trace-ability of measures back to the project's quality and process-performance objectives and Instrumented organizational support environment to support automatic data collection.
See figure 4.17 quantitative analysis technique for measures selection, defect density a measure of product quality and analysis technique, statistical process control (SPC) (XmR charts, to drive limit and analyse data). Here defect density by build (DDB) is a primary measure and indirect indicator of product quality. Defects are inserted by building and releasing the product prior to testing and discovered by testers. Here XmR SPC charts were used to derive limits and analyze data, in which data plotted chronologically and limits were based on variability within data set; reset when process changes.
Second practice is Application of Statistical Methods to Understand Variation. Its typical work products include: Collected measures, Natural bounds of process performance for each measured attribute of each selected sub process and Process performance compared to the natural bounds of process performance for each measured attribute of each selected sub process.
See figure 4.17 quantitative analysis technique for measures selection, defect density a measure of product quality and analysis technique, SPC (XmR charts, to drive limit and analyse data).
Third practice is Monitoring Performances of the Selected Subprocesses. Its typical work products include: Natural bounds of process performance for each selected sub process compared to its established (derived) objectives, For each sub process, its process capability and For each sub process, the actions needed to address deficiencies in its process capability. See table 4.3 manage project performance for monitoring performance of selected sub process.
Fourth practice is Maintaining of Statistical Management Data Record. Its typical work products include: Statistical and quality management data recorded in the organization's measurement repository. See table 4.3 manage project performance.
4.10 Conclusion
This chapter has discussed all possible details of GI's ERP system that was taken as a case study in this thesis, so that it may help a reader to understand CMMI's Advance project management process area's implementation in a better way. Its details include generic goals and increasing capability levels and specific goals in details.

5.1 Expected Benefits
Expected Process improvement benefits fall into one of following general categories [1]: Improved schedule and budget predictability, Improved cycle time, Increased productivity, Improved quality (as measured by defects), Increased customer satisfaction, Improved employee morale, Increased return on investment and decreased cost of quality.
5.2 Actual End Results Achieved
The results that are observed after applying CMMI's Project management process area on GI's ERP system includes: Meeting delivery deadline and unexpected cost savings specially due to the past experience and use of customisable modules. All internal operations are standardized and after reasonable training client are using efficient solution for its business. But, late project payment by Pakistan Software Export Board resulted in major decline of overall business, blockage of investment budget for future projects.
Graph in figure 5.1 shows comparison of improved schedule and budget predictability between this current project that is using historical data while adopting CMMI and a prior project that was not based on historical data. This graph shows slight increase in budget predictability in between capability level one and two then as level of capability increases specially on reaching to capability level three i.e. defined and capability level four i.e. quantitatively managed Improvement in schedule also increases with high predictability in budget. Achieving capability level five i.e. optimising is not preferred in small to medium level projects. See table 5.1 for its approx percentage values.

Project using historical data (GI 's project using CMMI process model) Project with out historical data
Level 1 -30% -20%
Level 2 -10% -10%
Level 3 20% 10%
Level 4 40% 20%

Table 5.1: Improved Schedule and Budge Predictability

Figure 5.1: Improved Schedule and Budge Predictability
Graph in figure 5.2 shows changes in two entities first in Error rate per KLOC that is decreasing with increasing level of capability and second is the increase in Productivity rate SLOC as Error rate is decreasing with increase in capability levels. See table 5.2 for its approx percentage values.
Productivity rate SLOC per person day Error Rate per KLOC
Level 1 0% 80%
Level 2 10% 20%
Level 3 20% 10%
Level 4 60% 0%

Table 5.2: Increased productivity and quality

Figure 5.2: Increased productivity and quality
5.3 Commentary
5.3.1 Things to Remember
Still there are major things that are being initiated from humans that includes decisions by upper management because in most of the cases:
i. They just try to make there budget possible at any cost on given timeline without keeping in mind the realties and possibilities what there working team is facing or going through.
iii. So, it's a best practice to always initiate from realistic estimations and its only possible if our Management staff has enough working experience regarding software development and specially problems that arise during communicating with the clients and finalizing processes that are actually required by the Client organisations.
iv. Another big mistake that software companies usually made is that they give final bid to the client before collecting their complete specification. Unclear picture or scenarios cause high budget and timeline than the expected ones.
v. From client side management:
vi. We must have some term of regulations document that will be used for negations while converting client requirements in to technical requirements. So that Development Company may charge if blur pictures from Client side gives big list of unexpected process. This is necessary to minimize negative effects of easily busted processes.
It has been observed that a good motivated team leader takes his team toward successes.
5.3.2 Capability Maturity Model v/s CMM Integration
CMM does not guarantee that the software organization can actually keep up the maturity level, Software development organizations should receive periodical CMM audit in order to keep its maturity level certification. Secondly in CMM systems and software disciplines have traditionally not been well integrated.
CMMI helps to see the enterprise view of process improvement. Provides a framework for introducing new disciplines as needs arise. CMMI Integrates system and software disciplines into one process improvement framework.
5.3.3 Capability Maturity Model Integration
Comparatively CMMI's Advance project management process area involves high emphasis over risk management process area and its quantitative project management process area emphasis on statistical methods of process performance to achieve business objectives that is recommended for those projects where uncertainty in results is expected.
Project planning process area is among one of its fundamental process area.

The practices of this process area provide the basis for all of the management and engineering tasks. This process area describes the activities that will enable an effective development plan to be created, like the attention to planning the involvement of various stakeholders across the development life cycle and the inclusion of planning for data management [10].
It also focuses on reuse like it has increased attention to using commercial off-the-shelf (COTS) components. Since COTS products are obtained outside of the project, the guiding information is included in the Supplier Agreement Management and Integrated Supplier Management process areas.
CMMI focus on detecting problems and taking corrective actions. These are addressed in the Project Monitoring and Control process areas by implementing practices of these process areas, problems in achieving project and organizational objectives are identified and corrective actions are tracked to closure. Peer review is another provides opportunities to the development items, such as software code. With the higher-level attention to quantitative and statistical process control, we gain the ability to look first at special causes of variation and then at common "root" causes of variation. We can then improve processes to avoid introducing defects rather than removing them once they are observed. The CMMI represents a valuable framework to reduce disorder and rework and to make the development effort more rewarding to both developers and end users.
5.4 Conclusion
This chapter has covered discussion over expected benefits to achieve then actual end results achieved. After that it covers commentary first on preferred project management related activities and mistakes that we generally do, secondly on CMMI v/s CMM and in last it covers commentary on CMMI.

6.1 Conclusion And Future Requirements
This thesis has covered detail studies and implementation of CMMI's Advance Project Management process area, by exploring it and discussing its implementation over selected Enterprise Resource Planning system. See section 1.7 to understand its complete workflow. Its complete case study is discussed in chapter 4 by following CMMI's approach.
This thesis has shown the success rate of an ERP system by adopting best fitted framework and achieving project targets and to help project managers in software development organisations to exactly know in detail how to apply Project management practices to achieve related goals as defined in Capability Maturity Model Integration. See chapter 5 for details of actual end results achieved.
Figure 5.1 shows comparison of improved schedule and budget predictability between this current project that is using historical data and a prior project that was not based on historical data. As capability level increases improvement in schedule also increases with high predictability in budget.
Figure 5.2 shows changes in two entities first in Error rate per KLOC that is decreasing with increasing level of capability and second is the increase in Productivity rate SLOC as Error rate is decreasing with increase in capability levels.
Further studies are required, to explore CMMI's process management, engineering and support process areas because their interaction is involved in advance project management process area See figure 2.1 in which black area are actual process areas that belongs to CMMI's Project management process area and process areas in grey colour are required to be covered. For better understanding it is only possible by discussing more case studies consist of more complex and advance ERP Systems.
Developing a better understanding requires discussing it more using different case studies consist of more complex and advance ERP Systems. For its proper implementation in Pakistan we first need to take membership and participate in its official training programmes abroad that are being initiated by Software Engineering Institute (SEI) etc., then we use these trained people to further conduct-training programmes for project managers of our local software houses. It is also required to buy advance project management license software that may help the project managers to perform risk management and quantitative management related activates efficiently.

A.1 Common Terminology with special meanings
Some of the terms used in CMMI models have meanings attached to them that differ from their everyday use. These terms are not included in the glossary; we have explained their use in CMMI models in this chapter.
1. Adequate, Appropriate, As Needed: These words are used so that you can interpret goals and practices in light of your organization's business objectives. When using any CMMI model, you must interpret the practices so that they work for your organization. These terms are used in goals and practices where certain activities may not be done all of the time.

2. Establish and Maintain: When using a CMMI model, you will encounter goals and practices that include the phrase "establish and maintain." This phrase connotes a meaning beyond the component terms; it includes documentation and usage.

3. Customer: A "customer" is the party (individual, project, or organization) responsible for accepting the product or for authorizing payment. The customer is external to the project, but not necessarily external to the organization. The customer may be a higher-level project. Customers are a subset of stakeholders.

4. Stakeholder: A "stakeholder" is a group or individual that is affected by or in some way accountable for the outcome of an undertaking. Stakeholders may include project members, suppliers, customers, end users, and others.

5. Relevant Stakeholder: The term "relevant stakeholder" is used to designate a stakeholder that is identified for involvement in specified activities and is included in an appropriate plan.

6. Manager: Within the scope of CMMI models, the word "manager" refers to a person who provides technical and administrative direction and control to those performing tasks or activities within the manager's area of responsibility. The traditional functions of a manager include planning, organizing, directing, and controlling work within an area of responsibility.

7. Project Manager: In the CMMI Product Suite, a "project manager" is the person responsible for planning, directing, controlling, structuring, and motivating the project. The project manager is responsible for satisfying the customer.

8. Shared Vision: In the CMMI Product Suite, a "shared vision" is a common understanding of guiding principles including mission, objectives, expected behavior, values, and final outcomes, which are developed and used by a group, such as an organization, project, or team. Creating a shared vision requires that all people in the group have an opportunity to speak and be heard about what really matters to them.

9. Organization: An organization is typically an administrative structure in which people collectively manage one or more projects as a whole, and whose projects share a senior manager and operates under the same policies.
10. Enterprise: When CMMI models refer to an "enterprise," they illustrate the larger entity not always reached by the word "organization." Companies may consist of many organizations in many different locations with different customers. The word "enterprise" refers to the full composition of companies.

11. Development: The word "development," when used in the CMMI Product Suite, implies not only development activities, but also maintenance activities. Projects that benefit from the best practices of CMMI can focus on maintenance, development, or both

12. Discipline: The word "discipline," when used in the CMMI Product Suite, refers to the bodies of knowledge available to you when selecting a CMMI model (e.g., systems engineering). The CMMI Product Team envisions that other bodies of knowledge will be integrated into the CMMI Framework.

13. Project: In CMMI models, a "project" is a managed set of interrelated resources that delivers one or more products to a customer or end user. This set of resources has a definite beginning and end and typically operates according to a plan. Such a plan is frequently documented and specifies the product to be delivered or implemented, the resources and funds used, the work to be done, and a schedule for doing the work. A project can be composed of projects.

14. Product: The word "product" is used throughout the CMMI Product Suite to mean any tangible output or service that is a result of a process and that is intended for delivery to a customer or end user. A product is a work product that is delivered to the customer.

15. Work Product: The term "work product" is used throughout the CMMI Product Suite to mean any artefact produced by a process. These artefacts can include files, documents, and parts of the product, services, processes, specifications, and invoices.

16. Product Component: The term "product component" is used as a relative term in CMMI models. In CMMI, product components are lower level components of the product; product components are integrated to "build" the product. There may be multiple levels of product components.

17. Appraisal: In the CMMI Product Suite, an "appraisal" is an examination of one or more processes by a trained team of professionals using an appraisal reference model as the basis for determining strengths and weaknesses.

18. Assessment: In the CMMI Product Suite, an "assessment" is an appraisal that an organization does to and for itself for the purposes of process improvement. The word "assessment" is also used in the CMMI Product Suite in an everyday English sense (e.g., risk assessment).
19. Verification: Although "verification" and "validation" at first seem quite similar in CMMI models, on closer inspection you can see that each addresses different issues.

20. Validation: Validation confirms that the product, as provided, will fulfil its intended use. In other words, validation ensures that "you built the right thing."

21. Goal: A "goal" is a required CMMI component that can be either a generic goal or a specific goal. When you see the word "goal" in a CMMI model, it always refers to model components (for example, generic goal, specific goal).

22. Objective: When used as a noun in the CMMI Product Suite, the term "objective" replaces the word "goal" as used in its common everyday sense, since the word "goal" is reserved for use when referring to the CMMI model components called "specific goals" and "generic goals."

23. Quality and Process-Performance Objectives: The phrase "quality and process-performance objectives" covers objectives and requirements for product quality, service quality, and process performance.

24. Standard: When you see the word "standard" used as a noun in a CMMI model, it refers to the formal mandatory requirements developed and used to prescribe consistent approaches to development (for example, ISO standards, IEEE standards, organizational standards).

A.2 CMMI-Specific Terminology
The following terms were created for CMMI products or are critical to the understanding of CMMI products.
25. CMMI Product Suite: The "CMMI Product Suite" is the complete set of products developed around the CMMI concept. These products include the framework itself, models, appraisal methods, appraisal materials, and various types of training that are produced from the CMMI Framework.

26. CMMI Framework: The "CMMI Framework" is the basic structure that organizes CMMI components, including common elements of the current CMMI models as well as rules and methods for generating models, their appraisal methods (including associated artefacts), and their training materials.

27. CMMI Model: Since the CMMI Framework can generate different models based on the needs of the organization using it, there are multiple CMMI models. Consequently, the phrase "CMMI model" could be any one of many collections of information.

28. Peer Review: The term "peer review" is used in the CMMI Product Suite instead of the term "work product inspection." Essentially, these terms mean the same thing. A peer review is the review of work products performed by peers during development of the work products to identify defects for removal.

29. Organization's Set of Standard Processes: An "organization's set of standard processes" contains the definitions of the processes that guide all activities in an organization. These process descriptions cover the fundamental process elements (and their relationships to each other) that must be incorporated into the defined processes that are implemented in projects across the organization.

30. Process: A "process," as used in the CMMI Product Suite, consists of activities that can be recognized as implementations of practices in a CMMI model. These activities can be mapped to one or more practices in CMMI process areas to allow a model to be useful for process improvement and process appraisal.

31. Defined Process: A "defined process" is a managed process that is tailored from the organization's set of standard processes according to the organization's tailoring guidelines; has a maintained process description; and contributes work products, measures, and other process-improvement information to the organizational process assets.

32. Organizational Process Assets: "Organizational process assets" are artefacts that relate to describing, implementing, and improving processes (e.g., policies, measurements, process descriptions, and process implementation support tools). The term "process assets" is used to indicate that these artefacts are developed or acquired to meet the business objectives of the organization, and they represent investments by the organization that are expected to provide current and future business value.
33. Product Life Cycle: A "product life cycle" is the period of time, consisting of phases, that begins when a product is conceived and ends when the product is no longer available for use.

34. Organization's Measurement Repository: The "organization's measurement repository" is a repository used to collect and make available measurement data on processes and work products, particularly as they relate to the organization's set of standard processes.

35. Document: A "document" is a collection of data, regardless of the medium on which it is recorded, that generally has permanence and can be read by humans or machines. So, documents include both paper and electronic documents.

B.1 Source Publicly Available
The following documents or draft versions of them were used in the development of the CMMI Product Suite and are publicly available.
DoD 98 Department of Defense. Defense Acquisition Deskbook, Version 3.2. http://web2.deskbook.osd.mil/default.asp. (This is continually updated.)
EIA 94 Electronic Industries Alliance. EIA Interim Standard: Systems Engineering (EIA/IS-632). Washington, D.C.:1994.
EIA 95 Electronic Industries Alliance. EIA Interim Standard: National Consensus Standard for Configuration Management (EIA/IS-649). Washington, D.C.: 1995.
EIA 98 Electronic Industries Alliance. Systems Engineering Capability Model (EIA/IS-731). Washington, D.C.1998. http://geia.org/sstc/G47/731dwnld.htm.
FAA 97 Federal Aviation Administration. Integrated Capability Maturity Model, Version 1.0. http://www.faa.gov/aio/ProcessEngr/iCMM/index.htm, November 1997.
IEEE 90 Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, New York: 1990.
INCOSE 96 International Council on Systems Engineering. Systems Engineering Capability Assessment Model, Version 1.50. June 1996.
ISO 87 International Organization for Standardization. ISO 9000: International Standard. New York, New York: 1987.
ISO 95 International Organization for Standardization and International Electrotechnical Commission. Information Technology: Software Life Cycle Processes (ISO 12207). 1995.
ISO 00 International Organization for Software. ISO 9001:2000: The International Standard System for Assuring Product and Service Quality. : http://www.iso.ch/, August 9, 2001.
ISO 01a International Organization for Standardization. ISO 15939: Software Measurement Process.: http://www.iso.ch/
ISO 01b International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15504 Software Process Improvement and Capability Determination Model (SPICE).
Juran 88 Juran, J. M. Juran on Planning for Quality. New York, New York: MacMillan, 1988.
Masters 95 Masters, S. and Bothwell, C. CMM Appraisal Framework (CMU/SEI-95-TR-001). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, February 1995.: http://www.sei.cmu.edu/publications/documents/95.reports/95-tr-001/95-tr-001-abstract.html

B.2 Sources Not Publicly Available
The following documents were used in the development of the CMMI Product Suite but were never released for public use.
Integrated Product Development Capability Maturity Model, Version 0.98, Enterprise Process Improvement Collaboration and Software Engineering Institute, Carnegie Mellon University, 1997

[1] Capability Maturity Model Integration (CMMI), Version 1.1; CMMISM for Software Engineering (CMMI-SW, V1.1) Continuous Representation CMU/SEI-2002-TR-028; ESC-TR-2002-028; Improving processes for better products by CMMI Product Team August 2002.
[2] CMMI V1.1 Tutorial; E-SEPG; April 9, 2002; Mike Phillips, CMMI Program Manager; Sponsored by the U.S. Department of Defence; © 2002 by Carnegie Mellon University Pittsburgh.
[3] Portrait of CMMI Level 4 Effort: Dough Smith and Craig Hollenbach Litton/PRC.
[4] Interpreting Continuous-View Capability Models for Higher Levels of Maturity. Received February 19, 1999; Accepted March 9, 1999. Rescuing and Revitalizing the problem project, By Cinda Voegtli, President, ProjectConnections.com.
[6] Project Managers and their Responsibilities, How to actively prepare for, Engage and overcome Project Conflict, By David L. Kohrell, PMP.
[7] Technical Report CMU/SEI-93-TR-025 ESC-TR-93-178 February 1993, Key Practices of the Capability Maturity ModelSM, Version 1.1, Mark C. Paulk Charles V. Weber Suzanne M. Garcia Mary Beth Chrissis Marilyn Bush.
[8] Technical Report CMU/SEI-94-TR-12 ESC-TR-94-12, A Comparison of ISO 9001 and the Capability Maturity Model for Software, Mark C. Paulk July 1994.
[9] A Research Framework for Studying the Implementation of Enterprise Resource, Planning (ERP) systems Pernille Kræmmergaard & Charles Møller, pkj@iprod.auc.dk & charles@iprod.auc.dk http://www.cip.auc.dk Center for Industrial Production, Aalborg University Fibigerstræde 16, DK-9220 Aalborg, DENMARK.
[10] On the Formalisation of ERP Systems Procurement, Xavier Franch Joan A. Pastor.
[11] Universitat Polictècnica de Catalunya Universitat Polictècnica de Catalunya c/Jordi, Girona 1-3 c/Jordi Girona 1-3 UPC Campus Nord, C6 UPC Campus Nord, C6 Barcelona, Catalunya E-08034 Spain Barcelona, Catalunya E-08034 Spain +34 3 401 69 65 +34 3 401 70 21.
[12] Interpreting Continuous-View Capability Models for Higher Levels of Maturity, Received February 19, 1999; Accepted March 9, 1999, Rescuing & Revitalizing the problem project, By Cinda Voegtli, President, ProjectConnections.com.
[13] Project Managers & their Responsibilities, How to actively prepare for, Engage & overcome Project Conflict, By David L. Kohrell, PMP.
[14] Software engineering a practitioner's approach 5th edition, By McGraw hill international edition.
[15] Managing Software Development Projects. 2nd edition, By Neal Whitten
[16] Project Management, By The National Computing Centre.
[17] Mastering Project 2000, By Gini Annette Marquis.
[18] SEI's official web site for CMMI www.sei.cmu.edu/cmmi/
[19] Research papers on CMMI www.software.org/pub/externalpapers
[20] Research papers on CMMI www.sei.cmu.edu/publications/documents

The Glossary was developed recognizing the importance of using terminology that all model users can understand. It is also recognized that words and terms can have different meanings in different contexts and environments. The glossary in CMMI models is designed to document the meanings of words and terms that should have the widest use and understanding by users of CMMI products.
1 ability to perform A common feature of CMMI model process areas with a staged representation that groups the generic practices related to ensuring that the project and / or organization has the resources it needs.
2 acceptance test Formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a product or product component. (See "unit testing.")
3 acquisition The process of obtaining, through contract, any discrete action or proposed action by the acquisition entity that would commit to invest (appropriated funds) for obtaining products and services.
4 Adequate See Appendix for an explanation of how "adequate," "appropriate," and "as needed" are used in the CMMI Product Suite.
5 advanced practices In the continuous representation, all the specific practices with a capability level of two or higher.
6 business objectives (See "organization's business objectives.")
7 capability level Achievement of process improvement within an individual process area. A capability level is defined by the appropriate specific and generic practices for a process area.
8 capability maturity model A capability maturity model (CMM) contains the essential elements of effective processes for one or more disciplines. It also describes an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness.
9 configuration management A discipline applying technical and administrative direction and surveillance to (1) identify and document the functional and physical characteristics of a configuration item, (2) control changes to those characteristics, (3) record and report change processing and implementation status, and (4) verify compliance with specified requirements.
10 continuous representation A capability maturity model structure wherein capability levels provide a recommended order for approaching process improvement within each specified process area. (See "staged representation," "capability level," and "process area.")
11 corrective action Acts or deeds used to remedy a situation, remove an error, or adjust a condition.
12 COTS Items that can be purchased from a commercial vendor. (COTS stands for "commercial off the shelf.")
13 data management Principles, processes, and systems for the sharing and management of data.
14 defect density Number of defects per unit of product size (e.g., problem reports per 1000 lines of code).
15 equivalent staging Equivalent staging is a target staging, created using the continuous representation that is defined so that the results of using the target staging can be compared to the maturity levels of the staged representation. (See "target staging," "maturity level," "capability level profile," and "target profile.").
16 exit criteria States of being that must be present before an effort can end successfully.
17 institutionalisation The ingrained way of doing business that an organization follows routinely as part of its corporate culture.
18 integrated team A group of people with complementary skills and expertise who are committed to delivering specified work products in timely collaboration. Integrated team members provide skills and advocacy appropriate to all phases of the work products' life and are collectively responsible for delivering the work products as specified.
19 interface control In configuration management, the process of (1) identifying all functional and physical characteristics relevant to the interfacing of two or more configuration items provided by one or more organizations, and (2) ensuring that the proposed changes to these characteristics are evaluated and approved prior to implementation. [IEEE 828-1983] (See "configuration management" and "configuration item.")
20 life-cycle model A partitioning of the life of a product into phases that guide the project from identifying customer needs through product retirement.
21 maturity level Degree of process improvement across a predefined set of process areas in which all goals within the set are attained. (See "capability level" and "process area.")
24 non-developmental item An item of supply that was developed previous to its current use in an acquisition or development process. Such an item may require minor modifications to meet the requirements of its current intended use.
25 organization See Appendix for an explanation of how "organization" is used in the CMMI Product Suite.
26 process area See Appendix for an explanation of how "process area" is used in the CMMI Product Suite.
27 process asset Anything that the organization considers useful in attaining the goals of a process area. (See "organizational process assets.")
29 process asset library A collection of process asset holdings that can be used by an organization or project. (See "organization's process asset library.")
30 process attribute A measurable characteristic of process capability applicable to any process.
31 process capability The range of expected results that can be achieved by following a process. [EIA/IS 731, V1.0]
32 process description A documented expression of a set of activities performed to achieve a given purpose that provides an operational definition of the major components of a process. The documentation specifies, in a complete, precise, and verifiable manner, the requirements, design, behaviour, or other characteristics of a process.
33 process element The fundamental unit of a process. A process may be defined in terms of subprocesses or process elements. A sub process can be further decomposed; a process element cannot.
34 process group A collection of specialists that facilitate the definition, maintenance, and improvement of the process (es) used by the organization.
35 process improvement A program of activities designed to improve the performance and maturity of the organization's processes, and the results of such a program.
36 process performance A measure of actual results achieved by following a process. It is characterized by both process measures (e.g., effort, cycle time, and defect removal efficiency) and product measures (e.g., reliability, defect density, and response time).
38 process performance model A description of the relationships among attributes of a process and its work products that are developed from historical process performance data and calibrated using collected process and product measures from the project and which are used to predict results to be achieved by following a process.
39 product-component requirements Product-component requirements provide a complete specification of a product component, including fit, form, function, performance, and any other requirement.
40 program (1) A project. (2) A collection of related projects and the infrastructure that supports them, including objectives, methods, activities, plans, and success measures. (See "project.")
41 project plan In the Project Planning process area, see the definition of "project plan" in the introductory notes.
42 quality The ability of a set of inherent characteristics of a product, product component, or process to fulfil requirements of customers.
43 quality assurance A planned and systematic means for assuring management that defined standards, practices, procedures, and methods of the process are applied.
44 rating (See "appraisal rating.")
45 requirement (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).
46 return on investment The ratio of revenue from output (product) to production costs, which determines whether an organization benefits from performing an action to produce something.
47 risk identification An organized, thorough approach to seek out probable or realistic risks in achieving objectives.
48 risk management An organized, analytic process to identify what might cause harm or loss (identify risks), assess and quantify the identified risks, and to develop and, if needed, implement an appropriate approach to prevent or handle risk causes that could result in significant harm or loss.
49 risk management strategy An organized, technical approach to identify what might cause harm or loss (identify risks), assess and quantify the identified risks, and to develop and if needed implement an appropriate approach to prevent or handle risk causes that could result in significant harm or loss.
50 software engineering (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. (2) The study of approaches as in (1).
51 solicitation The process of preparing a solicitation package and selecting a supplier (contractor).
52 staged representation A model structure wherein attaining the goals of a set of process areas establishes a maturity level; each level builds a foundation for subsequent levels.
53 statement of work A description of contracted work required to complete a project.
54 statistical process control Statistically based analysis of a process and measurements of process performance, which will identify common and special causes of variation in the process performance, and maintain process performance within limits.
55 statistical techniques An analytic technique that employs statistical methods (e.g., statistical process control, confidence intervals, prediction intervals).
56 subprocess A process that is part of a larger process. (See "process description.")
57 supplier (1) An entity delivering products or performing services being acquired. (2) An individual, partnership, company, corporation, association, or other service having an agreement (contract) with an acquirer for the design, development, manufacture, maintenance, modification, or supply of items under the terms of an agreement (contract).
58 systems engineering The interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a product solution and support that solution throughout the product's life.
59 training In the Organizational Training process area, see the definition of "training" in the introductory notes.
60 work breakdown structure An arrangement of work elements and their relationship to each other and to the end product.
61 work product and task attributes Characteristics of products, services, and project tasks used to help in estimating project work. These characteristics include items such as size, complexity, weight, form, fit, or function. They are typically used as one input to deriving other project and resource estimates (e.g., effort, cost, schedule).