Process Centric Work Breakdown Structure of Business Case Analysis for Easing Software Project Management Challenges

Summer 2009 Project Process Centric Work Breakdown Structure of Business Case Analysis for Easing Software Project Management Challenges Software Project Management SEN-647 S.M. Saiful Islam ID # 0712004 Program – Master of Software Engineering August 5, 2009 1. INTRODUCTION ............................................................................................................................ 4  2. SOFTWARE PROJECTS’ SUCCESSES AND FAILURES STATISTICS ............................... 4  2.1 THE ROBBINS-GIOIA SURVEY (2001) ...................................................................................................... 4  2.2 THE CONFERENCE BOARD SURVEY (2001) ............................................................................................. 5  2.3 THE KPMG CANADA SURVEY (1997) ..................................................................................................... 5  2.4 THE CHAOS REPORT-STANDISH GROUP (1995)....................................................................................... 5  2.5 THE OASIG STUDY (1995) ...................................................................................................................... 6  2.6 TATA CONSULATNCY (2007) ................................................................................................................... 6  3. LIKELY REASONS FOR FAILURES AND SUCCESSES OF SOFTWARE PROJECTS .... 6  3.1 THE BULL SURVEY (1998) ....................................................................................................................... 7  3.2 THE KPMG CANADA SURVEY (1997) ..................................................................................................... 7  3.3 THE CHAOS REPORT (1995) ..................................................................................................................... 8  3.4 THE OASIG STUDY (1995) ...................................................................................................................... 9  4. PROCESS CENTRIC SOFTWARE PRODUCTION CONCEPT .............................................. 9  5. SW-CMMI SOFTWARE PRODUCTION PROCESS FRAMEWORK .................................. 10  6. CURRENT CONCEPT OF WORK BREAKDOWN STRUCTURE (WBS) ........................... 12  7. ROLE OF WBS IN ESTIMATION, SCHEDULING, MONITORING AND CONTROLING13  8. SIMILARITIES AND DIFFERENCES BETWEEN EXISTING WBS CONCEPT AND PROCESS CENTRIC PRODUCTION PROCESS ............................................................................................ 14  9. CONCEPT OF PROCESS CENTRIC WBS REPRESENTATION, SW-CMMI LIMITATIONS 15  10. BENEFITS OF PROCESS CENTRIC REPRESENTATION OF WBS................................. 17  11. PROCESS CENTRIC WBS OF THE SOFTWARE PRODUCTION STEP OF BUSINESS CASE ANALYSIS .......................................................................................................................................... 18  12. PROCESS CENTRIC WBS TO INCREASE VISIBILITY AND EASE COMPLEXITIES OF PROJECT MANAGEMENT ............................................................................................................ 22  13. MEASUREMENT FRAMEWORK FOR BUSINESS CASE ANALYSIS ............................. 23  14. STAKEHOLDERS OF EACH PRACTICE AND COMMUNICATION PROCESS ........... 24  15. SUMMARY AND CONCLUSION ............................................................................................. 26  SEN 645: Software Project Management Outline of the project Summer 09 Process Centric Work Breakdown Structure of Business Case Analysis for Easing Software Project Management Challenges 1. Give some statistics of software projects’ successes and failures. 2. State likely reasons for failures and successes. 3. Define the concept of process centric software production 4. Review SW-CMMI software production process framework 5. Define the current concept of work breakdown structure (WBS) 6. Role of WBS in resource estimation, scheduling, progress monitoring, detecting deviations, and taking control actions. 7. Establish similarities and differences between existing WBS concept and process centric production process. 8. Explain the concept of process centric WBS representation taking inputs from SW-CMMI. Mention areas in which SW-CMMI has limitations in representing WBS of different phases of software production in process centric manner. 9. Explain benefits of such process centric representation of WBS in improving project management capability in areas of resource estimation, scheduling, progress monitoring, detecting deviations, and taking control actions. 10. Develop the process centric WBS of the software production step assigned to you. a. Individual practices and sub-practices for hierarchical representation or step wise reduction of complexities b. Leaf level sub-practices should follow certain rules for maximum and minimum grain size of each task. c. Sequence of flow of execution of practices. d. Work products of each practice and their standards 11. Explain how can this process centric WBS can be used to increase visibility and ease complexities of resource estimation, scheduling, progress monitoring, detecting deviations, and taking control actions. 12. Measurements requirement for each practice and work product. Propose measurement framework for collecting related data. 13. Identification of stakeholders of each practice and proposed communication management process with these stakeholders. 14. Summary and conclusion making a case how does your process centric WBS representation reduces software project management complexities. Source of information:1. Existing literature, 2. Key informant interview, 3. Ethnography. Deliverables: 1. Comprehensive report, 2. Summary of the report in the form of a paper. Team members. 1. _________________________, 2._____________________________ Approval:________________________ 1. Introduction Software Project management involves coordinating various aspects of a project in order to bring forth a positive result. Over the past couple of years, there have been increasing challenges faced by Project Managers. Meeting these challenges are very difficult and in many cases they are not met which eventually leads to the project failure. Different studies reveal that an IT project is more likely to be unsuccessful than successful and 7 out of 10 IT projects fail in some respect. The process centric work breakdown structure (WBS) can play a very vital role in this regard to improve the situations significantly. 2. Software projects’ successes and failures statistics Managing a software project and making it successful is a big challenge and quiet uncertain. A number of studies were conducted by the different study groups along the globe which provide the failure statistics of software projects which is really alarming. The following surveys provide statistical data over the rate of failure of IT projects. • • • • • • The Robbins-Gioia Survey (2001) The Conference Board Survey (2001) The KPMG Canada Survey (1997) The Chaos Report –Standish Group (1995) The OASIG Survey (1995) Tata Consultancy (2007) 2.1 The Robbins-Gioia Survey (2001) Robbins-Gioia, LLC, made a study over the perception by enterprises of their implementation of an E.R.P. (Enterprise Resource Planning) package. 232 survey respondents spanning multiple industries including government, Information Technology, communications, financial, utilities, and healthcare participated in this survey. A total of 36 % of the companies surveyed had, or were in the process of, implementing an ERP system. Key Findings • 51 % viewed their ERP implementation as unsuccessful 46 % of the participants noted that while their organization had an ERP system in place, or was implementing a system, they did not feel their organization understood how to use the system to improve the way they conduct business. • • 56 % of survey respondents noted their organization has a program management office (PMO) in place, and of these respondents, only 36 % felt their ERP implementation was unsuccessful 2.2 The Conference Board Survey (2001) That survey interviewed executives at 117 companies that attempted ERP implementations Key Findings • • • • • • • 34 % were very “satisfied.” 58 % were “somewhat satisfied,” 8 % were unhappy with what they got. 40 % of the projects failed to achieve their business case within one year of going live The companies that did achieve benefits said that achievement took six months longer than expected. Implementation costs were found to average 25 % over budget, Supports costs were underestimated for the year following implementation by an average of 20 %. 2.3 The KPMG Canada Survey (1997) In April 1997, KPMG Canada sent a survey questionnaire focusing on IT project management issues to Canada's leading 1,450 public and private sector organizations. The main purpose was to outline the reasons behind the failure of Information Technology projects. Out of 1,450 questionnaires sent, 176 were analyzed. Of these, 61 % reported details on a failed IT project. Key Findings • • • Over 61 % of the projects that were analyzed were deemed to have failed by the respondents More than three quarters blew their schedules by 30% or more More than half exceeded their budgets by a substantial margin. 2.4 The Chaos Report-Standish Group (1995) The Chaos Report is the first survey made by the Standish Group. This report is the landmark study of IT project failure. The total sample size was 365 respondents representing 8,380 applications. In addition, The Standish Group conducted focus groups and personal interviews to provide qualitative context for the survey results. Key Findings • • • The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost over 189% of their original estimates. On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. • In the larger companies, the news is even worse: only 9% of their projects come in on-time and onbudget. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. • A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions. The Standing findings have been updated for different years which are shown in Table 1. Table 1 : Standish Findings by Year Category\Year Succeeded Failed Challenged 1994 16% 31% 53% 1996 27% 40% 33% 1998 26% 28% 46% 2000 28% 23% 49% 2002 34% 15% 51% 2004 29% 18% 53% 2009 32% 24% 44% 2.5 The OASIG Study (1995) This study has been undertaken under the auspices of OASIG, a Special Interest Group in the UK concerned with the Organizational Aspects of Information Technology. Information was collected in 1995 in the United Kingdom from a sample of 45 experts employed primarily by Universities or Consultancies. Key Findings • • The IT project success rate quoted revolves around 20-30% based on its most optimistic interviews. Bottom line, at best, 7 out of 10 IT projects “fail” in some respect. 2.6 Tata Consulatncy (2007) In 2007, Tata Consultancy Services (TCS), one of the largest Indian outsource consulting firms, released new IT failure research, based on survey results of 800 middle and senior IT managers from large companies. Key Findings • • • • • 62% of organizations experienced IT projects that failed to meet their schedules 49% suffered from budget overruns 47% had higher-than-expected maintenance costs 41% failed to deliver the expected business value and ROI 33% file to perform against expectations 3. Likely reasons for failures and successes of Software Projects Most of the stakeholders, consultants and project managers have made up their personal opinion about the ultimate causes of failure of IT projects. Their conclusion is, at best, partial and fragmentary and, at worse, strongly biased by their area of expertise. The following surveys - are an attempt to bring some objectivity in assessing the causes of IT project failure. This extends the number of the situations considered, but this also reduces the depth of insight or the acumen of the analysis that one gains by going through a full project lifecycle. • • • • The Bull Survey (1998) The KPMG Canada Survey (1997) The Chaos Report (1995) The OASIG Study (1995) 3.1 The Bull Survey (1998) In 1998, a total of 203 telephone interviews were conducted with IT and project managers from the finance, utilities, manufacturing, business services, telecoms and IT services sectors in UK. All the managers interviewed had previously taken the lead in integrating large systems within organizations in the Times Top 100. The main IT project failure criteria identified by the IT and project managers were: • • • • Missed deadlines (75%) Exceeded budget (55%) Poor communications (40%) Inability to meet project requirements (37%). The main success criteria identified were: • • • Meeting milestones (51%) Maintaining the required quality levels (32%) Meeting the budget (31%) The survey reveals that the major causes of project failure during the lifecycle of the project are a breakdown in communications (57%), a lack of planning (39%) and poor quality control (35%). End user acceptance of the project is seen as vital by 91% of the IT managers surveyed, with communication strategies identified as the way to manage end user and client expectations. Other important points to the project success were the professional skills of the people on the project team (59%). 3.2 The KPMG Canada Survey (1997) According to KPMG Canada Survey, the main causes of project failure that were identified were: • Poor project planning. Specifically, inadequate risk management and a weak project plan. Risk management becomes more important as the organization gets bigger, so larger organizations need to pay more attention to this area. • • Weak business case. The need for the system should be justified in ways that relate directly to the organization's business needs. Lack of top management involvement and support. This often dooms the project to failure before it starts. Securing buy-in from the top, often by a strong business case backed up with a realistic project plan, is an essential step. • • • Projects fail more often because of schedule overruns than budget overruns. Many projects fail because they use new or unproven technology. Poor estimates or weak definitions of requirements at the project planning stage also contribute to project failure. • • Projects can run into trouble due to the vendors' inability to meet commitments. 60 % of the failed projects were planned to take less than one year to complete. 3.3 The Chaos Report (1995) It has been conducted among 365 IT managers from companies of various sizes and in various economic sectors. The main IT project failure criteria considered were: • • • Cost Overruns Time Overruns Content Deficiencies Opinions about why projects are impaired and ultimately cancelled rank incomplete requirements and lack of user involvement at the top of the list. Table 2 : Project Failure Factors Project Impaired Factors 1. Incomplete Requirements 2. Lack of User Involvement 3. Lack of Resources 4. Unrealistic Expectations 5. Lack of Executive Support 6. Changing Requirements & 7. Lack of Planning 8. Didn't Need It Any Longer 9. Lack of IT Management 10. Technology Illiteracy 11. Other % of the Responses 13.1% 12.4% 10.6% 9.9% 9.3% 8.7% 8.1% 7.5% 6.2% 4.3% 9.9% 3.4 The OASIG Study (1995) It has been conducted in the UK among 45 experts issued from universities and consultancies. The participants of this study recognized the difficulty of determining clear project success or failure criteria and gaining hard evidence of the success of a project. The prominent failure elements considered were - the extent to which new systems are delivered on time and within budget, the fact that the new technology investment has been abandoned, the extent to which the new systems met expectations and gave value for money. The main reasons why systems fail to meet their objectives were identified as: • • • • • Lack of attention to the human and organizational aspects of IT. Poor project management. Poor articulation of user requirements. Inadequate attention to business needs and goals. Failure to involve users appropriately. The top causes of IT project failure are different in the different studies, probably highlighting a bias toward the key aspects that each organization having conducted those surveys wants to stress. 4. Process centric software production concept A typical software project starts with the setting up of target business value and ends with the business value assessment during the implementation and usages of the product along the years. The Fig. 1 depicts the typical process steps of software production process. The processs centric Software production enforces performing the software production activities along the way of software project management following production process flow in managed and controlled way. Total production process is broken down in a number of process units. Each process unit takes a set of inputs in complaince with right set of standards. A right set of practices has to be put in place. That will produce work products with expected standards. The achievable business value has to be determined in the very begining of the project. Otherwise there will be confusion whether business value has been met or not. The time and money play the great role in determining the success of project. The time and money must be monitored and controled to become succesful in project management. The project has two main roles which are current and future - the current role of project is to complete the project in estimated time and money; and the future role of the project is to give the customer maximu return on investment (RoI). Business Value Proposition/ Business Case Analysis System Requirement Analysis Software Requirement Analysis Software Requirement Specification Component Testing Coding Detail Design Architecture Design Component Test Plan Integration Testing Integration Test Plan Acceptance Test Plan Acceptance Testing Business Value Assessment Deployment Figure 1: Typical Software Production Process 5. SW-CMMI software production process 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 artifacts), and their training materials. The CMMI framework was developed using a consensus-based approach to identifying and describing best practices in a variety of disciplines. Successful process-improvement initiatives must be driven by the business objectives of the organization. The SW-CMMI does not recommend any single production process. The SW-CMMI has defined its process framework in different process areas. These process areas can be grouped into four categories: • • • • Process Management Project Management Engineering Support Although the process areas are grouped in this way, but they often interact and have an effect on one another regardless of their defined group. For example, the Decision Analysis and Resolution process area provides specific practices addressing formal evaluation that are used in the Technical Solution process area for selecting a technical solution from alternative solutions. Technical Solution is an Engineering process area and Decision Analysis and Resolution is a Support process area. The Process Management process areas contain the cross-project activities related to defining, planning, resourcing, deploying, implementing, monitoring, controlling, appraising, measuring, and improving processes. Project Management process areas cover the project management activities related to planning, monitoring, and controlling the project. The Engineering process areas cover the development and maintenance activities that are shared across engineering disciplines (e.g., systems engineering and software engineering). The six process areas in the Engineering process area category have inherent interrelationships. These interrelationships stem from applying a product development process rather than discipline-specific processes such as software engineering or systems engineering. The Support process areas cover the activities that support product development and maintenance. The Support process areas address processes that are used in the context of performing other processes. In general the Support process areas address processes that are targeted towards the project, and may address processes that apply more generally to the organization. For example, Process and Product Quality Assurance can be used with all the process areas to provide an objective evaluation of the processes and work products described in all of the process areas. The Software Production process is mainly related to the Project Management Process Areas and Engineering Process Areas. The major Project Management process areas of CMMI include: • • • Project Planning Project Monitoring and Control Risk Management 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, and taking corrective action. The Engineering process areas of CMMI are as follows: • • • • • • Requirements Development Requirements Management Technical Solution Product Integration Verification Validation All engineering process areas have been written to support recursion throughout the product architecture. For a product with many complex product components, this specific practice would be applied to the product components of the complete product delivered to the customer as well as to the product components assembled to form the product, and so on. Thus, this specific practice is applied to as many levels as necessary to integrate everything that the product comprises. The major Support process areas of CMMI are as follows: • • • Configuration Management Process and Product Quality Assurance Measurement and Analysis All the different process areas have different goals and for meeting those goals need to perform different practices and eventually produce different work products. But, these are not aligned to single production process. This is the big limitation of CMMI production process framework. 6. Current concept of work breakdown structure (WBS) The Work Breakdown Structure (WBS) was initially developed by the U.S. defense establishment, and it is described in Military Standard as "a product oriented family tree composed of hardware, software, services, data and facilities .... (it) displays and defines the product(s) to be developed and./or produced and relates the elements of work to be accomplished to each other and to the end product(s)". The CMMI also defines WBS as a product-oriented hierarchical structure, which by this definition, provides a scheme for identifying and organizing the logical units of work to be managed, which are called "work packages". A work breakdown structure (WBS) in project management and systems engineering, is a tool used to define and group a project's discrete work elements (or tasks) in a way that helps organize and define the total work scope of the project. A work breakdown structure element may be a product, data, a service, or any combination. A WBS also provides the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control. Additionally the WBS is a dynamic tool and can be revised and updated as needed by the project manager. The Work Breakdown Structure provides a common framework for the natural development of the overall planning and control of a contract and is the basis for dividing work into definable increments from which the statement of work can be developed and technical, schedule, cost, and labor hour reporting can be established. A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into their successively higher level “parent” tasks, materials, etc. For each element of the work breakdown structure, a description of the task to be performed is generated. This technique (sometimes called a System Breakdown Structure) is used to define and organize the total scope of a project. A well-designed WBS makes it easy to assign each project activity to one and only one terminal element of the WBS. It is often portrayed graphically as a hierarchical tree; however, it can also be a tabular list of "element" categories and tasks or the indented task list that appears in Gantt chart schedule. A WBS takes the form of a tree diagram with the "trunk" at the top and the "branches" below. The primary requirement or objective is shown at the top, with increasingly specific details shown as the observer reads down. A wellorganized, detailed WBS can assist key personnel in the effective allocation of resources, project budgeting, procurement management, scheduling, quality assurance, quality control, risk management, product delivery and service oriented management. 7. Role of WBS in estimation, scheduling, monitoring and controling As part of the project management planning process it is important to create a work breakdown structure (WBS). This structure groups and organizes deliverable project elements so that the work can be more easily managed. WBS relates to scope definition in that it helps characterize the total scope of the project leading to a successful end product. The WBS also helps to verify a common team understanding during project management. The WBS can be presented in the form of a chart but should not merely be a loose-fitting list of work activities for the project. Because projects can be similar in their development, it might be helpful to create a template to use as a point of initiation but keep in mind that the WBS is not a one size fits all document and that each project should be organized based on its own unique requirements for success. During all phases of project management the WBS should be adhered to and team members should recognize that any work that is not specified in the WBS is not within the scope of the project. A key strategy of effective planning is to partition the project into manageable chunks that can be individually planned estimated and controlled. The work breakdown structure is a graphical tool that displays the project's statement of work making it easier to understand and communicate. It is employed from the earliest stages of project planning. It represents the project in terms of the hierarchy of deliverables and services it will produce. The WBS supports the principle of management by deliverables providing a map of what is to be produced. WBS provides a simple map of what is to be produced. It does not deal with schedules and therefore has no time dimension. It is however used as entry criteria for schedule development. The main purpose of Work Breakdown Structure is that firstly, it helps to define and organize the scope of the total project more accurately and specifically. The most common way this is done is by using a hierarchical tree structure. Each level of this structure breaks the project deliverables or objectives down to more specific and measurable chunks. The second reason for using a Work Breakdown Structure in projects is to help with assigning responsibilities, resource allocation, monitoring the project, and controlling the project. The WBS makes the deliverables more precise and concrete so that the project team knows exactly what has to be accomplished within each deliverable. This also allows for better estimating of cost, risk, and time because you can work from the smaller tasks back up to the level of the entire project. Finally, it allows you double check all the deliverables' specifics with the stakeholders and make sure there is nothing missing or overlapping. 8. Similarities and differences between existing WBS concept and process centric production process The processs centric Software production enforces performing the software production activities along the way of software project management following production process flow in managed and controlled way. Total production process is broken down in a number of process units. Each process unit takes a set of inputs in complaince with right set of standards. A right set of practices has to be put in place. That will produce work products with expected standards. The achievable business value has to be determined in the very begining of the project. The Work Breakdown Structure groups and organizes deliverable project elements so that the work can be more easily managed. Conceptually, WBS relates to scope definition in that it helps characterize the total scope of the project leading to a successful end product. But, traditional tree structure WBS cannot give accurate scope of the project unless it considers the production process. The WBS also helps to verify a common team understanding during project management. The WBS can be presented in the form of a chart but should not merely be a loose-fitting list of work activities for the project. The Work Breakdown Structure helps to define and organize the scope of the total project more accurately and specifically. The most common way this is done is by using a hierarchical tree structure. Each level of this structure breaks the project deliverables or objectives down to more specific and measurable chunks. But traditional work breakdown structure will not be able to define the total scope of the project accurately and specifically if it does not take production process into consideration. In tree structure work breakdown will simply consider the total work scope in linier way. But practically this doesn’t happen. How much parallelism can be brought into production process, how many resource can be loaded and when, what could be the waiting time due to dependency should also be considered. Otherwise the main purpose of WBS will not be met. The Work Breakdown Structure in projects is to help with assigning responsibilities, resource allocation, monitoring the project, and controlling the project. The WBS makes the deliverables more precise and concrete so that the project team knows exactly what has to be accomplished within each deliverable. This also allows for better estimating of cost, risk, and time because you can work from the smaller tasks back up to the level of the entire project. Finally, it allows you double check all the deliverables' specifics with the stakeholders and make sure there is nothing missing or overlapping. But practically this is also very difficult to be met in traditional work breakdown structure. In traditional work breakdown structure, it is not specified what would be inputs for a particular work package and from where one is getting those, what would be the outputs from that work package and who will be using those. That means dependency and linkage is absent in traditional work breakdown structure which will significantly limits success of project resource allocation, monitoring and controlling the project. 9. Concept of process centric WBS representation, SW-CMMI limitations The main purpose of Work Breakdown Structure is that, it helps to define and organize the scope of the total project more accurately and specifically. The most common way this is done is by using a hierarchical tree structure. Each level of this structure breaks the project deliverables or objectives down to more specific and measurable chunks. The other reason for using a Work Breakdown Structure is to help with assigning responsibilities, resource allocation, monitoring the project, and controlling the project. The WBS makes the deliverables more precise and concrete so that the project team knows exactly what has to be accomplished within each deliverable. This also allows for better estimating of cost, risk, and time because you can work from the smaller tasks back up to the level of the entire project. The CMMI also defines WBS as a product-oriented hierarchical structure, which by this definition, provides a scheme for identifying and organizing the logical units of work to be managed, which are called "work packages". The processs centric WBS is different than the traditional WBS. In process centric WBS, the total production process is considered and then the total process is broken down in a number of linked process units. Each process unit take a set of inputs with the right set of standards. A right set of practices has to be put in place; that will produce work products with expected standards. One output work product will be the input to one or multiple process units. Before going to be input to the other process units, the complainace of workproducts in complaniance with appropriate standards is ensured so that it can’t cause any harm such as production of defects for the next outputs. All the proces units are linked together which ultimately completes the production process. The Fig. 2 depicts a typical procss unit. To complete a process, a set of practices has to be performed. Quality of the produced work products has to be ensured after producing or before using as input to the other process unit. Right Set of Practices Products Produced & their Standards Right Set of Inputs Right Set of Standards Figure 2: WBS Process Unit The SW-CMMI does not recommend any single production process which can be brokendown into the small process units and the work can be performed. Rather, it defines and recommends a number of process areas. How all these process areas work together and can be alligned to a single production is not well explained. So, doing this is very challanging and critical. The Software Production process is mainly related to the Project Management Process Areas and Engineering Process Areas. The major Project Management process areas of CMMI include Project Planning, Project Monitoring and Control and Risk Management. 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, and taking corrective action. The Engineering process areas of CMMI includes Requirements Development, Requirements Management, Technical Solution, Product Integration, Verification and Validation. All engineering process areas have been written to support recursion throughout the product architecture. For a product with many complex product components, this specific practice would be applied to the product components of the complete product delivered to the customer as well as to the product components assembled to form the product, and so on. Thus, this specific practice is applied to as many levels as necessary to integrate everything that the product comprises. The major Support process areas of CMMI include Configuration Management, Process and Product Quality Assurance and Measurement and Analysis. All the different process areas have different goals and meeting those goals need to perform different practices and eventually produce different work products. But, these are not aligned to single production process. This is the big limitation of CMMI production process framework. 10. Benefits of process centric representation of WBS As stated earlier, the process centric work breakdown structure is different from the traditional tree structure work breakdown structure. In process centric work breakdown structure, total production process is broken down into small logical process units which take a set of inputs with the right set of standards and perform the appropriate set of practices to produce required work products with expected standards. This is the main strength of process centric WBS. The process centric WBS provides a great tool to the project manager to define estimates, monitor, control and improve the project activities from process perspective. Following are the benefits which can be achieved from process centric WBS: 1. Full production process split into small logical process units following 8/80 rules or like that. This ensures full process view at a glance at the planning stages. 2. Parallel process steps are clearly shown. Therefore, resource planning and resource loading will be efficient and easier. 3. A process unit takes quality inputs in compliance with applicable standards and performs specific practices in specified manner. 4. A process unit or work package’s task is very clear; dependency and stakeholders’ engagement are clearly defined. This ensures better estimation, communication and control over the process and products. 5. All process units are dynamically reconfigurable. The project manager would be able to choose the required process units, standards, templates and products to adjust production process based on the diverse project forces. 11. Process centric WBS of the software production step of Business Case Analysis The Fig. 3 depicts the typical process centric work breakdown structure of Business case analysis. Here, only the main process units are considered. The review and verification of work products have been omitted to keep it simple. Each process unit or work package needs to perform some specific practices to produce the desired work product. Some standard and templates have to be put in place to produce the right quality of work products. Some measurement framework has also to be put in place so that effectiveness of the process and quality of the product can be assessed, controlled and improved. For business case analysis business goal would be the first input. Taking this input the business case would be defined. This business description will contain the brief about the business case which is likely to be achieved. This business case document would be used as input to document the background, objective and scope of the business along with identifying the stakeholders and their stakes. Taking these as input the market research methodology and objectives has to be defined. Based on the defined methodology the relevant templates, guidelines, checklist and questionnaires have to be produced. Taking all these as input market research plan has to be produced. Taking the market research plan and other artifacts key informant interview, questionnaire survey, and focused group survey have to be conducted. Taking the output of these studies market research analysis has to be conducted and analysis report should be produced. Taking this input current functional capability has to be documented and process model has to be developed. From that performance indicators has to be identified and role of system elements have also to be determined. Then measurement has to be taken to identify the optimum system component roles. Based on these new functional capability has to be defined, new process model has to be defined. Taking these inputs new role of system components have to be defined and from that draft system requirements has to be defined. This draft system requirement has to be validated by performing prototyping and taking stake holders feedbacks. This will eventually produce the refined system requirements which will be used as the input to the next product step. Document Background, Business Goal Define Business Case Business Case Description Objectives and Scope Background, Objectives and Scope Descriptions Define Market Research Methodology and Stakeholders and their involvement Objectives Identify the Conduct Key Informant Interview 1 Conduct Key Informant Interview 2 Key Informant Interview Result Market Research Conduct Key Informant InterviewN Plan Stakeholders and their stakes Market Research Methodology Templates Define Market Research Templates Define Market Research Guidelines Define Market Research Checklist Define Survey Questionnaire Guidelines Conduct Questionnaire Survey 1 Questionnaire Survey Result Conduct Questionnaire Survey 2 Questionnaire Conduct Questionnaire Survey N Conduct Focused Group Discussion Make Market Research Plan Checklists Discrete Process Model Focused Group Discussion Result Develop Process Model 1 Market Analysis Report Current Functional Document Current Functional Capability Capability Develop Process Model 2 Develop Process Model N Key Performance Integrated Process Identify Key Performance Indicators Integrated Process Model Model Integrate Process Models Analyze Market Research Data Take Process Performance Components Roles Relationship Measurement 1 and Performance Data Take Process Performance Indicators Take Process Performance Measurement N Integrated System Component Roles Integrate System Component Roles Component Roles Measurement 2 Discrete System Identify Role of System Component 1 Identify Role of System Component 2 Identify Role of System Component N Indentify Optimum System Components Roles Optimum System Components Roles Define New Functional Capabilities Discrete New System Component Roles Integrate Process Models Develop New Process Model 1 Develop New Process Model 2 Develop New Process Model N Discrete Process Model Integrated New Process Model Define New Key Performance Indicators New Key Performance Indicators and Target Define New Role of System Component 1 Define New Role of System Component 2 Define New Role of System Component N New Functional Capability Integrate New System Component Roles Perform Prototype 1 Validated System Requirements Perform Prototype 2 Perform Prototype N Verify Stakeholders needs and Expectations Draft System Requirements New System Component Roles Define Draft System Requirements Figure 3: Process Centric WBS of Business Case Analysis Different stakeholders will be involved in the different stages of this process. These stake holders will involve • • • • Customer side senior Management Customers business Partners System End users System Engineering Team Major work products produced during the execution of business case analyis are • • • • • • • • • Business Case Description Background, Objectives, Scope Description Stakeholders & their involvement list Market Research Methodology Market Research Plan Market Analysis Report Functional Capability Process Model System Component Roles System Requirement • For process system analysis and process modeling following Template can be used: 1. Introduction 1.1 Purpose 1.2 Description of Client 1.3 Scope 2. Current System 2.1 Functioanl Capability 2.2 Process Model 2.3 Performance Parameters 2.4 Role of System Components 2.4.1 People 2.4.2 Machine/Tools 2.5 Relationships of components roles to Perfomance Parameters 3. Optimum Roles for System components 4. Evisioned System 4.1 Functioanl Capability 4.2 New Process Model 4.3 New Performance Parameters 4.4 New Role of System Components 4.4.1 People 4.4.2 Machine/Tools 4.5 Relationships of components roles to Perfomance Parameters 5. New Policy, Procedure and Standard 6. Role of Envisioned Software 7. Conclusion For documenting the System Requirement following Standard Tempalte can be used: Section 1.Introduction 1.1 1.2 1.3 1.4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Purpose Business Context Scope User Characteristics General System Description System Context System Modes and States Major System Capabilities Major System Conditions Major System Constraints Assumptions Dependencies Operational Scenarios System Capabilities, Conditions, and Constraints Section 2. Section 3. 3.1 Business Requirements 3.2 Functional Requirements 3.3 3.4 3.5 3.6 Physical Requirements Logical Data Requirements User Requirements Information Management Requirements 3.7 3.8 3.9 Systems Requirements Policy and Regulation Requirements System Life Cycle Sustainment Requirements System Interfaces Requirements Traceability Matrix References Glossary Revision History Appendices Section 4. Section 5. Section 6. Section 7. Section 8. Section 9. 12. Process centric WBS to increase visibility and ease complexities of project management In process centric work breakdown structure, total production process is broken down into small logical process units which take a set of inputs with the right set of standards and perform the appropriate set of practices to produce required work products with expected standards. Here the stake holders are also identified. The process centric WBS provides a great tool to the project manager to define estimates, monitor, control and improve the project activities from process perspective. Full production process split into small logical process units following 8/80 rules or like that. This ensures full process view at a glance at the planning stages. As process focus is the main driver of process centric WBS, it increases the visibility significantly of whole production process to the manager. The process centric WBS also emphasizes on parallel processing steps. This clearly shows the parallel processing steps. This also increases the visibility to the project manager, which helps in efficient resource planning and resource loading at the different project phases. A process unit takes quality inputs in compliance with applicable standards and performs specific practices in specified manner. As all the standards, templates, guidelines and the pertinent work product and practices are defined; it also eases the complexity of project management. A process unit or work package’s task is very clear; dependency and stakeholders’ engagement are clearly defined. This ensures better estimation, communication and control over the process and products. All process units are dynamically reconfigurable. The project manager would be able to choose the required process units, standards, templates and products to adjust production process based on the diverse project forces. 13. Measurement framework for Business Case Analysis A metric is a quantifiable measurement of software product, process, or project that is observed, calculated, or predicted. Software measurement is the quantitative assessment of any aspect of a software engineering process, project, product, or context; it aims to enhance ones understanding and to help to control, predict, and improve what one produces and how s/he produces it. The driving force of measurement is dealing with the uncertainty, uncertainty about size, complexity, productivity, quality, ROI, readability, maintainability, reliability, etc. The metric is related with the purpose of the work products and the process unit that produced that work products. The objective of business case analysis metric is to see the effectiveness of the business case analysis processes and the quality of work products. The probable Metrics for Business Case Analysis are shown in Table 3. However, readability, clarity, complexity, effort variance and reusability can be used as a thumb rule. Table 3 : Business Case Analysis Metrics Work Product Business Case Description Background, Objectives, Scope Description Stakeholders & their involvement list Market Research Methodology Market Research Plan Market Analysis Report Functional Capability Product Metric Clarity Clarity, Completeness Process Unit Identify Stakeholders & their Involvement Make Market Research Plan Conduct Key Informant Interview Conduct Questionnaire Survey Conduct Focused Group Discussion Analyze Market Research Data Develop Process Model Process Metric Reusability, Manageability Reusability, Flexibility, Manageability Clarity, Reusability, Rework Manageability, Productivity Productivity, Quality Productivity, Flexibility, Quality Reusability, Flexibility, Complexity Quality, Productivity, Clarity Reusability Complexity, Practicability, Reusability Readability, Clarity, Completeness Clarity, Completeness, Stability Readability, Reusability, Complexity Process Model Take Process Performance Measure System Component Roles System Requirement Completeness Readability, Completeness, Consistency Define System Component Roles Perform Prototyping Complexity Manageability, Productivity Quality The major metrics for business case analysis are clarity, completeness, reusability, stability, readability, consistency, quality, productivity, etc. Table 4 : Data Requirement for Metrics Metric Name Clarity Data Requirement Number of ambiguous or unclear statement. Number of sections/pages Completeness Number of missing points Number of sections/pages/documents Reusability Measure No. of unclear statements per sections/pages No. of missing points per sections/pages/documents Number of reusable % of reusable work sections/templates/models/concept/documents products Number of reusable sections/templates/models/concept/documents Stability Number of changed work products Number of work products % of stable work products No. of comments per sections/pages No. of inconsistency per work product Defect density Readability Number of comments Number of sections/pages Consistency Number of inconsistency found Number of work products Quality Number of defects found Number of sections/pages/work products Productivity Number of pages/documents/work products produced Unit of Time Required/Spent No. of pages/documents/work products per unit of Time 14. Stakeholders of each practice and communication process Different stakeholders will be involved in the different stages of business case analysis process. These stake holders will include • • • Customer side senior Management Customers business Partners System End users • System Engineering Team Major pracatices need to perform to produce the desired work products includes the following: • • • Briefly define business for detail study Document the background, objectives and scope of the business case Identify the stakeholders & document their involvement requirement along with their expectations • Formulate Market Research Methodology to be applied for market study about the business case • • • • • • • • • • Prepare Market Research Plan to conduct the Market Study Conduct Key Informant Interview Conduct Questionnaire Survey Conduct Focused Group Discussion Analyze the Market data and prepare Analysis Report Identify and document Functional Capability of the current system Prepare Process Model both current and proposed Take process performance measurement Indentify System Component Roles current and proposed Validate system requirement through prototyping Document System Requirement • Different type of communication would be required to perform the total tasks of business case analysis: • Formal, impersonal All the documentation will come under this category of communication. This includes Business case description, Market Research Plan, Functional Capability Document, Process Model, System Requirement. • Formal, interpersonal procedures Formal meeting with defined agenda with System Engineering Team members, with senior client management, progress reviews, process formulation and change etc. will come under this communication plan. Structured questionnaire survey can come under this form of communication. • Informal, interpersonal procedures All brainstorming for identifying stakeholders, defining the research methodology, identifying the performance indicators, identifying system element roles can come under this procedure. Key Informant interview and focused group discussion can come under this category. • Electronic communication This can be done with all the team members and client stakeholders. This is very effective and prompt communication method. During business case analysis this can be used in different phases. This can be used for market research purpose as well. • Interpersonal network This can be used to identify the business goal, key performance indicator etc. Key informant interview also can come under this category. 15. Summary and conclusion Whether for a new project manager, or an experienced leader, project management will continue to reveal itself as part art, part science, and part major headache! Project leadership is a skill that takes time to develop in a person or organization. Achieving success requires analyzing setbacks and failures in order to improve. Focusing on each project's challenges and learning from them will help to build a more capable and successful project management capability. The process centric WBS is a great tool to the project manager in this respect. The practicing of process centric WBS can ease project management in a great deal. The probability of making the project successful will increase dramatically. But, the main challenge is to optimally discretize the production process. Too much discretization will increase the visibility but will complicate communication and manageability. So, there is a need to make balance. The measurement and review process cost time and money. Therefore, the measurement and review of process should also be optimum. The main focus should be on value creation from such process centric WBS representation and RoI of such value creation should be maximized by practicing optimum level of process decomposition.