ELE4402. Software Engineering Project Management. Study Book. Faculty of Engineering & Surveying. Bachelor of Software Engineering.

Transcription

1 ELE4402 Software Engineering Project Management Faculty of Engineering & Surveying Bachelor of Software Engineering Study Book Written by Dr Wei Xiang BEng, MEng, PhD Lecturer in Computer System Engineering Faculty of Engineering & Surveying The University of Southern Queensland

2 Published by University of Southern Queensland Toowoomba QLD 4350 Australia < University of Southern Queensland, (1st edn), (2nd edn). Copyrighted materials reproduced herein are used under the provisions of the Copyright Act 1968 as amended, or as a result of application to the copyright owner. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means electronic, mechanical, photocopying, recording or otherwise without prior permission. The camera-ready PDF file is produced using PDFL A T E X by the author. Style file supplied by Ted Siebuhr, DEC. The following L A T E X 2ε packages were utilized: hyperref (hyperlinking for Acrobat PDF format); tabularx (tables); xcolor (table colors). AMS font system used for some mathematics, METAPOST used for the EPS figure drawing.

3 TABLE OF CONTENTS PAGE Module 1 Software Engineering Project Management Course Overview 0 Module 2 Introduction to Project Management Introduction What is a project What is project management How project management relates to other disciplines History of project management The Project management profession Project management careers, research, certification and ethics Project management software 9 Module 3 The Project Management and Information Technology Context A system view of project management Understanding organisations Stakeholder management The importance of top management commitment Project phases and the project life cycle Product life cycles Context of information technology projects Suggested skills for a project manager 8

4 Module 4 The Project Management Process Groups: A Case Study Project management process groups Developing an information technology project management methodology Case study: JWD consulting s project management intranet site project Project initiation Project planning Project executing Project controlling Project closing 8 Module 5 Project Integration Management What is project integration management Project plan development Project plan contents Using guidelines to create project plans Stakeholder analysis and top management support Project plan execution Integrated change control The integrated change control process Change control system Using software to assist in project integration management 10 Module 6 Project Scope Management What is project scope management Project initiation: strategic planning and project selection Methods for selecting projects Project charters Scope planning and the scope statement 8

5 6.4 Scope definition and the work breakdown structure Work breakdown structure Approaches to developing work breakdown structures Advice for creating a WBS Scope verification and scope change control Suggestions for improving user input Suggestions for reducing incomplete and changing requirements Using software to assist in project integration management 13 Module 7 Project Time Management Importance of project schedules Activity definition Activity sequencing Dependencies Network diagrams Activity duration estimation Schedule development Gantt charts Critical path method Critical chain scheduling Program evaluation and review technique (PERT) Controlling changes to the project schedule Using software to assist in project time management 14

6 Module 8 Project Cost Management Importance of project cost management Basic principles of cost management Resource planning Cost estimating Types of cost estimates Cost estimation tools, techniques and typical problems Cost budgeting Cost control Earned value management Project portfolio management Using software to assist in project cost management 12 Module 9 Project Quality Management What is project quality management Quality planning Quality assurance Quality control Tools and techniques for quality control Pareto analysis Statistical sampling Six sigma Quality control charts and the seven run rule Testing Modern quality management Improving information technology project quality Leadership The cost of quality Organisational influences, workspace factors, and quality Maturity models Using software to assist in project quality management 18

7 Module 10 Project Human Resource Management The importance of human resource management What is project human resource management Keys to managing people Motivation theories Influence and power Improving effectiveness Organisational planning Project organisational charts Responsibility assignment matrices Staff management plans and resource histograms Project staff acquisition Resource assignments Resource loading Resource levelling Team development Training Team-building activities Reward and recognition systems and general advice on teams Using software to assist in human resource management 14 Module 11 Project Communications Management The importance of project communications management Communications planning Information distribution Using technology to enhance information distribution Formal and informal methods for distributing information Understanding human and individual communications needs 6

8 Determining the number of communication channels Performance reporting Administrative closure Suggestions for improving project communications Using communication skills to manage conflict Developing better communication skills Running effective meetings Using effectively Using templates for project communications Developing a communications infrastructure Using software to assist in project communications 13 Module 12 Project Risk Management Importance of project risk management Risk management planning Common sources of risk on information technology projects Risk identification Qualitative risk analysis Using probability/impact matrixes to calculate risk factors Top ten risk item tracking Expert judgement Quantitative risk analysis Decision trees and expected monetary value Simulation Risk response planning Risk monitoring and control Results of good project risk management Using software to assist in project time management 13

9 Module 13 Project Procurement Management Importance of project procurement management Procurement planning Procurement planning tools and techniques Types of contracts Statement of work (SOW) Solicitation planning Solicitation Source selection Contract administration Contract close-out Using software to assist in project communications 11

10

11 Module 1 SOFTWARE ENGINEERING PROJECT MANAGEMENT COURSE OVERVIEW

12

13 Module 1 Software Engineering Project Management Course Overview 1.1 This course ELE4402 Software Engineering Project Management teaches you essential concepts, principles, and techniques relating to the project management aspects of software engineering. Software project management is of paramount importance to the success of software development projects. As revealed by the 2004 CHAOS Report from US analysts the Standish Group < com>, there was US$55 billion in waste, US$38 billion in lost value and US$17 billion in cost over-runs for information technology projects in the U.S. in In Australia, as described in an article titled Software Calamities Come at a High Price in The Australian on 30 Nov. 2004, the potential of software project failure due to improper project managment is formidable. For example, the National Australia Bank announced in Nov that it would write off $409 million in value from its key information technology systems. Earlier in 2004, Melbourne s RMIT University announced that they would spend $11 million re-implementing a failed student enrolment system. If that is not enough, Sydney Water wrote off $61 million on its now-abandoned customer records system last year due to its failure to understand the complexity of its customer implementation and billing service. All these data reveal one fact, that is, project management is tremendously important to the success of software development projects. That is the theme of this study book. This study book introduces a well established framework for project management, i.e., the Project Management Body of Knowledge (PMBOK Guide 2004) by the Project Management Institute (PMI). The study book focuses on the project management aspects of software development projects of various sizes. It covers all nine project management knowledge areas (project integration, scope, time, cost, quality, human resource, communications, risk and procurement management), and five process groups (initiating, planning, executing, controlling, and closing). The purpose of this study book is to serve as a study guide for students enrolled in ELE4402 Software Engineering Project Management. It consists of the following thirteen modules. Each module except Module 1 (Course Overview) has the following components: ➊ Objectives: this section describes the concepts and techniques you will learn in this section. It indicates what you should be able to do upon successful completion of the module. ➋ Learning resources: this section provides required and recommended learning resources relating to the module. ➌ Module overview: this section provides an overview introduction to the module. ➍ Activity: this section is the feature of the study book. Several activities are usually scattered in each module. The intention of the activities is to provide you with indepth activities relevant to important topics in the modules to consolidate their understanding of principles. You should attempt all activities. ➎ Reading: this section specifies which chapters/sections of the prescribed text or recommended texts you are required or recommended to read for each module. In order to fulfil the module s objectives, you have to read the reading materials marked as required. In order to gain additional and better understanding on

14 1.2 ELE4402 Software Engineering Project Management the topics, you are encouraged to read the reading materials marked as recommended. However, you are not disadvantaged in the examination of the course if you do not read the recommended materials. ➏ Review questions: this section provides some review questions for you to self test whether you fulfill the module s objectives. ➐ Exercises: this section provides some exercises relating to the topics covered in the module. It requires comprehensive understanding of the topics to complete the exercises. ➑ Minicase: at the end of modules 3 13, a minicase is provided as the case study of the module. You are encouraged to attempt all minicases. The overview structure of the modules covered in the study book is depicted in Figure 1.1. It is noted that the boxes numbered from one to nine in the figure correspond to Modules 5 to 13 in the study book. You should refer to the study timetable in the introductory book for the schedule to complete each module. You should attempt all activities as they are encountered, then complete all review questions and exercises at the end of each module. This study book has several distinctive features. First, it features many activities throughout the study book to foster your problem-solving abilities in the real world of project management. Second, it emphasises the application of project management theories and principles to software development projects. Third, case studies are a large element of this study book. At the end of Modules 3 13, there are minicase assignments for you to practise. Last, it encourages you to use various software tools to solve project management problems by having a dedicated section on this topic at the end of each module. The prescribed text of this course is Schwalbe, K. 2006, Information technology project management, 4th edn, Thomson Course Technology. It is bundled with a 120-day free trial version of Microsoft Project at no extra charge. The lecturer of this course maintains a course homepage at < ELE4402.html>. The course homepage provides various additional resources relating to the course including the lecture notes, journal articles, etc. There are some other recommended texts, such as Hughes, B. & Cotterell, M. 2002, Software Project Management, 3rd ed, McGraw-Hill, and Royce, W. 1998, Software Project Management: A Unified Framework, Addison-Wesley. The study book is largely based on materials in the prescribed text. As a result, you should use it in conjunction with Schwalbe s text. The study book presents essential principles, techniques, and tools in relation to software project management in Schwalbe s text in a concise and easy-to-understand way. Moreover, it provides many useful activities throughout the study book that expose you to practical software project management problems. Some extra materials not found in the prescribed text are also provided in the activities and selected readings. The structure of the study book is organised as follows:

15 Module 1 Software Engineering Project Management Course Overview 1.3 Figure 1.1: Overview of project management knowledge areas (source: PMBOK Guide 2004, p. 11)

16 1.4 ELE4402 Software Engineering Project Management Module 1 Course Overview: provides the course overview of this course. Module 2 Introduction to Project Management: provides an overview of the field project management, and an introduction to the project management profession. Module 3 The Project Management and Information Technology Context: provides a context for project management in general and software development projects in particular. Module 4 The Project Management Process Groups: describes the project management process groups, i.e., initiating, planning, executing, controlling, and closing. It also provides a matrix that relates the process groups to each knowledge area. Module 5 Project Integration Management: covers the details of the project integration management knowledge area. Module 6 Project Scope Management: covers the details of the project scope management knowledge area. Module 7 Project Time Management: covers the details of the project time management knowledge area. Module 8 Project Cost Management: covers the details of the project cost management knowledge area. Module 9 Project Quality Management: covers the details of the project quality management knowledge area. Module 10 Project Human Resource Management: covers the details of the project human resource management knowledge area. Module 11 Project Communications Management: covers the details of the project communications management knowledge area. Module 12 Project Risk Management: covers the details of the project risk management knowledge area. Module 13 Project Procurement Management: covers the details of the project procurement management knowledge area.

17 Module 2 INTRODUCTION TO PROJECT MANAGEMENT

18

19 Module 2 Introduction to Project Management 2.1 Objectives On successful completion of this module, you should be able to: ➀ understand the growing need for better project management, especially for information technology projects ➁ explain what a project is and provide examples of information technology projects ➂ describe what project management is and discuss key elements of the project management framework ➃ discuss how project management relates to other disciplines ➄ understand the history of project management ➅ describe the project management profession, including recent trends in project management research, certification, and software products. Learning resources Text Chapter 1, Schwalbe (4th edition) Selected reading Selected reading 2.1: Appendix A, Hughes and Cotterell (3rd edition) Module overview This module is the introduction to project management. It starts with the definitions of projects and project management, and then explains how project management relates to other disciplines. This module also reviews the brief history of project management. The current development of the project management discipline and profession are discussed, including careers, research, certification, ethics, and the software of project management. In the following sections, we briefly summarise the key concepts and principles contained in this module.

20 2.2 ELE4402 Software Engineering Project Management 2.1 Introduction Project management originated from, and primarily focused on providing services to the military and construction industries until the 1980s. Now, project management has widely spread into almost every industry including the software and information technology (IT) industries. The following statistics demonstrates the significance of project management in today s society: the U.S. spends $2.3 trillion on projects every year that is equal to 1/4 of the nation s GDP the world spends $10 trillion on projects out of its $40.7 trillion GDP more than 6 million people regard project management as their profession disappointingly, the overall success rate of IT projects was only 16.2%. Many organisations claim that using project management provides the following advantages: better control of financial, physical, and human resources improved customer relations shorter development times lower costs higher quality and increased reliability higher profit margins improved productivity better internal coordination higher worker morale. 2.2 What is a project A guide to the project development body of knowledge (PMBOK Guide) 2004 edition, published by the Project Management Institute (PMI), is an American national standard for project management. As defined in the PMBOK Guide 2004, a project is a temporary endeavor undertaken to create a unique product or service. A project normally exhibits the following attributes: A project has a unique purpose

21 Module 2 Introduction to Project Management 2.3 A project is temporary A project requires resources, often from various areas A project should have a primary customer or sponsor A project involves uncertainty. The triple constraint of projects refers to scope, time and cost: ➊ Scope: What is the project trying to accomplish? ➋ Time: How long should it take to complete the project? ➌ Cost: What should it cost to complete the project? Managing the triple constraint involves making trade-offs between scope, time, and cost goals for a project. Moreover, quality as well as customer or sponsor satisfaction also play significant roles. Quality, scope, time, and cost are sometimes referred to as the quadruple constraint of project management. Activity 2.1 Australian institute of project management (AIPM) The Australian Institute of Project Management (AIPM) has developed sets of competency standards, recognised as the Australian national standards, to support the certification of project managers. Visit the AIPM s website at < and find out what the nice functions covered in the competency standards are and their similarities and differences with the 9 knowledge areas in the PMBOK Guide 2004.

22 2.4 ELE4402 Software Engineering Project Management Activity 2.2 PRINCE 2 an overview Read through Appendix A, Hughes and Cotterell s text (3rd edition). Understand that PRINCE 2 is the UK standard for project management initiated by the Central Computer and Telecommunications Agency (CCTA). List all the components that PRINCE 2 includes on the left side of blank paper, and list all the components that PMBOK Guide 2004 on the right side of the same paper. Try to connect the components included in the PRINCE 2 to the 9 knowledge areas in the PMBOK Guide What is project management Project management is defined as the application of knowledge, skills, tools, and techniques to project activities in order to meet project requirements. Figure 2.1 illustrates the Project Management Framework as in the figure 1-2 of the textbook. As depicted in the framework, stakeholders are the people involved or affected by project activities and include the project sponsor, project team, support staff, customers, users, supplies, and even opponents to the project. As outlined in the PMBOK Guide 2004 and depicted in the project management framework in Figure 2.1, there are 9 project management knowledge areas, which describe project management knowledge and practice in terms of their component processes. Figure 2.2 illustrates the overview of project management knowledge areas and project management processes. The four core knowledge areas are briefly described below: ➊ Project scope management: involves defining and managing all the work required to complete the project successfully. ➋ Project time management: includes estimating how long it will take to complete the work, developing an acceptable project schedule, and ensuring timely completion of the project. ➌ Project cost management: consists of preparing and managing the budget for the project. ➍ Project quality management: ensure that the project will satisfy the stated or implied needs for which it was undertaken.

23 Module 2 Introduction to Project Management 2.5 Figure 2.1: Project Management Framework (source: Schwable 2006, Fig. 1-2.) These are called core knowledge areas because they lead to specific project objectives. There are also four facilitating knowledge areas of project management: ➊ Project human resource management: is concerned with making effective use of people involved with the project. ➋ Project communications management: involves generating, collecting, disseminating, and storing project information. ➌ Project risk management: includes identifying, analysing, and responding to risks related to the project. ➍ Project procurement management: involves acquiring, procuring goods services for a project from outside the performing organisation. These are called facilitating knowledge areas because they are the processes through which the project objectives are achieved. The ninth knowledge area, called project integration management, is an overarching function that affects and is affected by all of the other knowledge areas. Project portfolio management is an emerging business strategy, in which organisations group and manage projects as a portfolio of investments that contribute to the entire enterprise s success. Project portfolio management will be discussed in detail in Module 8 (Project Cost Management). Throughout each knowledge area, there are many commonly used tools and techniques to assist project managers and their teams in achieving project objectives. Table 2.1 lists some commonly used tools and techniques in the nine project management knowledge areas.

24 2.6 ELE4402 Software Engineering Project Management Figure 2.2: Overview of project management knowledge areas and project management processes (source: PMBOK Guide 2004, p. 11)

25 Module 2 Introduction to Project Management 2.7 Table 2.1: Project management tools and techniques in 9 knowledge areas Knowledge Area Integration management Scope management Time management Cost management Quality management Human resource management Communications management Risk management Procurement management Commonly Used Tools and Techniques Stakeholder analysis, Project plans, Project management software, Change control boards, Configuration management, Project review meetings, Work authorisation systems, Project leadership, Executive sponsorship Net present value, Return on investment, Payback, Weighted scoring models, Business cases, Project charters, Scope statements, Work breakdown structures, Statement of work, Requirements analysis, Scope change control Gantt charts, Network diagrams, Critical path analysis, Program evaluation review technique, Critical chain scheduling, Crashing, Fast tracking, Milestone reviews Earned value management, Project portfolio management, Cost estimates, Cost management plan, Financial software Six Sigma, Quality control charts, Pareto diagrams, Fishbone or Ishikawa diagrams, Quality audits, Maturity models, Statistical methods Motivation techniques, Empathic listening, Team contracts, Responsibility assignment matrices, Resource histograms, Resource loading, Resource leveling, Team-building exercises Communications management plan, Conflict management, Communications media selection, Communications infrastructure, Status reports, Meetings, Virtual communications, Templates, Project web sites Risk management plan, Probability/impact matrix, Risk ranking, Monte Carlo simulation, Top-ten risk item tracking Make-or-buy analysis, Contracts, Requests for proposals or quotes, Source selection, Negotiating, E- procurement

26 2.8 ELE4402 Software Engineering Project Management 2.4 How project management relates to other disciplines The nature of projects lies in that projects are unique, temporary, and involve various resources. This nature distinguishes project management from general or operation management. A project manager must focus on integrating all the various activities required to complete the project, whereas most of the tasks performed by a general or operation managers are repetitive, ongoing, and done as day-to-day activities. This subject and thus this study book are focused on software and information projects, which include computer software, computer hardware, and telecommunications technology. There are some differences between managing software and IT projects, but there are even more similarities. 2.5 History of project management It has been commonly recognised that the modern concept of project management began with the Manhattan Project, which was a U.S. military project for developing the atomic bomb. The project lasted three years and cost almost $2 billion in In the early days of modern project management development, the military was the key industry behind the development of several project management techniques. Henry Gantt invented the famous Gantt chart in 1917, which is a standard format for displaying project schedule information by listing project activities and their corresponding start and finish dates in a calendar format. Network diagrams were first used by members of the Navy Polaris missile/submarine project in Details about Gantt charts and network diagrams will be discussed in Module 7 Project Time Management. The military also pioneered using software to help manage large projects. Early software products for project management were expensive and hard to use. The sophistication and effectiveness of project management software have been significantly improved. Web-based and enterprise project management software has emerged, which integrates information from multiple projects to show the status of active, approved, and future projects across an entire organisation and provides links to more detailed information. Today, project management is used in some form in virtually all organisations and disciplines. The project managers challenge is to understand the concepts of project management and determine what tools and techniques should be applied on specific projects and in specific organisations.

27 Module 2 Introduction to Project Management The Project management profession Project management has spread into almost every discipline including information technology. Researchers and practitioners are continuing to develop the project management profession to respond to social and economic changes and to remain competitive Project management careers, research, certification and ethics The Project Management Institute (PMI, < is an international professional society for project managers. By early 2003, it has more than 100,000 members worldwide. Within PMI, there are Specific Interest Groups (SIGs) that enable members to share ideas about project management in their specific application areas. The PMI has SIGs for information systems, aerospace/defense, financial services, healthcare, hospitality management, manufacturing, new product development, retail, urban development, and so on. The Information Systems SIG has about 15,000 members. To deal with increased challenges of projects in the 1990s, many organisations began creating the Project Management Office (PMO). A PMO is an organisational group responsible for coordinating the project management function throughout an organisation. Groups like the PMI and Standish Group are actively participating in the research of project management. The PMI holds its international research conference on project management, whereas the Standish Group holds its CHAOS University to update and analyse information related to IT projects. The International Journal of Project Management and other publications also publish research papers on project management. The Project Management Professional (PMP) is a certification program provided by the PMI. Certified PMPs are supposed to have documented sufficient project experience and education, agreed to follow the PMI code of professional conduct, and demonstrated knowledge of the field of project management by passing a comprehensive examination. CompTIA s IT Project+ certification is another improtant project management certification program. The PMI developed a PMP Code of Professional Conduct that all certified PMPs must agree to. PMP code of professional conduct lists responsibilities to both the profession and customers and the public Project management software In 1999, the PMI published a Project Management Software Survey that described and compared more than 200 project management software tools. The Project Management Center < is a Web site that provides

28 2.10 ELE4402 Software Engineering Project Management an alphabetical listing of and links to hundreds of products that help manage projects. Based on functionality and price, project management software tools can be dived into the following three general categories: ➊ Low-end tools: these tools provide basic project management features and generally cost less than US$200 per user. Most of these tools allow users to create Gantt charts. Examples include Milestones Simplicity by KIDASA Software, How s it going? by LogicAbility. ➋ Midrange tools: these tools are designed to handle larger projects, multiple users, and multiple projects. Prices range from about US$200 to US$500 per user. All of these tools can produce Gantt charts and network diagram, assist in critical path analysis, resource allocation, project tracking, status reporting, and so on. The most popular tool in this category is Microsoft Project Other examples include Artemis, PlanView, Primavera, Welcom, and so on. ➌ High-end tools: also referred to as enterprise project management software. These tools provide enterprise functions that summarise and combine individual project information to provide an enterprise view of all projects, intergrate with enterprise database management software, and are accessible via the Internet. Examples include Niku s Workbench, Primavera s TeamPlay, and Microsoft enterprise version of Project Server 2003.

29 Module 2 Introduction to Project Management 2.11 Reading Read Schwalbe s text Chapter 1. Review questions Complete Discussion Questions 1 6 in Schwalbe s text chapter 1 to fulfil the objectives of Module 2. Exercises Complete Exercises 1 5 in Schwalbe s text Chapter 1.

30 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution.

31 Module 3 THE PROJECT MANAGEMENT AND INFORMATION TECHNOLOGY CONTEXT

32

33 Module 3 The Project Management and Information Technology Context 3.1 Objectives On successful completion of this module, you should be able to: ➀ understand the systems view of project management and how it applies to information technology projects ➁ analyze a formal organization using the structural, human resources, political, and symbolic organizational frames ➂ describe the differences among functional, matrix, and project organizational structures ➃ explain why stakeholder management and top management commitment are critical for a project s success ➄ understand the concept, development, implementation, and close-out phases of the project life cycle ➅ distinguish between project development and product development ➆ discuss the unique attributes and diverse nature of information technology projects ➇ list the skills and attributes of a good project manager in general and in the information technology field. Learning resources Text Chapter 2, Schwalbe (4th edition) Selected reading Selected reading 3.1: Chapter 5, Royce

34 3.2 ELE4402 Software Engineering Project Management Module overview This module discusses the context for project management in general and information technology projects in particular. It describes the importance of taking a systems view when selecting and working on projects, understanding organizations and stakeholders, the project and product life cycles, the unique nature of information technology projects, and important skills and attributes for good project managers. In the following sections, we briefly summarise the key concepts and principles presented in this module. 3.1 A system view of project management Systems are sets of of interacting components working within an environment. There are a few terms related to systems explained as follows: ➊ System thinking: describes the holistic view of carrying out projects within the context of the organisation. ➋ System approach: emerged in the 1950s and describes a holistic and analytic approach to solving complex problems that includes using a systems philosophy, systems analysis, and systems management. ➌ Systems philosophy: is an overall model for thinking about things as systems. ➍ Systems analysis: is a problem-solving approach that requires defining the scope of the system, dividing it into its components, and then identifying and evaluating its problems, opportunities, constraints, and needs. ➎ Systems management: addresses the business, technological, and organisational issues associated with making a change to a system. There are three spheres in the systems management model, namely, business, organisation, and technology. Refer to Figure 2-1 (Three-sphere model for systems management) in the textbook for a graphical presentation. Using a systems approach is critical to successful project management. Moreover, using a holistic approach helps project managers integrate business and organisational issues into their planning.

35 Module 3 The Project Management and Information Technology Context Understanding organisations Organisations have four different frames explained as follows: ➊ Structural frame: deals with how the organisation is structured and focuses on the different groups roles and responsibilities in order to meet the goals and policies set by top management. ➋ Human resources frame: focuses on producing harmony between the needs of the organisation and the needs of the people. ➌ Political frame: addresses organisational and personal politics. ➍ Symbolic frame: focuses on symbols and meanings. The organisational structures can be classified into three classes: ➊ Functional organisational structure: the most common organisational structure in which functional managers or vice presidents report to the chief executive officer (CEO). ➋ Project organisational structure: also has a hierarchical structure in which project managers report to the CEO. ➌ Matrix organisational structure: represents the middle ground between functional and project structures. Personnel report to both a functional manager and one or more project managers. Figure 3.1 depicts the functional, project, and matrix organisational structures. It can be concluded that project managers have the most authority in a pure project organisation and the least amount of authority in a pure functional organisation. 3.3 Stakeholder management As stated in the Module 2, project stakeholders are the people involved in or affected by project activities. Stakeholders can be internal or external to the organisation: Internal project stakeholders: include the project sponsor, project team, support staff, and internal customers for the project, top management, other functional managers, and other project managers. External project stakeholders: include the project s customers, competitors, suppliers, and other external groups potentially involved in or affected by the project, such as government officials or concerned citizens.

36 3.4 ELE4402 Software Engineering Project Management Figure 3.1: Three organisational structures (source: Schwalbe 2006, Fig. 2-2.)

37 Module 3 The Project Management and Information Technology Context 3.5 Because the purpose of project management is to meet project requirements and satisfy stakeholders, it is critical for project managers to identify, understand, and manage relationships with all project stakeholders The importance of top management commitment The 2001 Standish Group study results revealed the ten factors, in order of importance, that contributed most to success of information technology projects: ➊ executive (top management) support ➋ user involvement ➌ experienced project manager ➍ clear business objectives ➎ minimised scope ➏ standard software infrastructure ➐ firm basic requirement ➑ formal methodology ➒ reliable estimates. It was clear that executive support or top management commitment was the important factor to the project success. There are several reasons why top management commitment is crucial to project managers: project managers need adequate resources project managers often require approval for unique project needs in a timely manner project managers must have cooperation from people in other parts of the organisation project managers often need to someone to mentor and coach them on leadership issues. Organisation s commitment to information technology in general is another factor affecting the success of IT projects.

38 3.6 ELE4402 Software Engineering Project Management 3.4 Project phases and the project life cycle A project life cycle is a collection of the following four project life phases : ➊ Concept: Sample deliverables in this phase include the management plan, preliminary cost estimate, and 3-level WBS. ➋ Development: Sample deliverables in this phase include the project plan, budgetary cost estimate, and 6+-level WBS. ➌ Implementation: Sample deliverables in this phase include the last work package, definitive cost estimate, performance reports. ➍ Close-out: Sample deliverables in this phase include the completed work, lessons learned, customer acceptance. The first two phases are often referred to as project feasibility as they focus on planning, while the last two phases are often referred to as project acquisition as they focus on delivering the actual work. Figure 3.2 depicts the framework for the four phases of a project life cycle. Figure 3.2: Phases of the Project Life Cycle (source: Schwalbe 2006, Fig. 2-3.) Activity 3.1 Life-cycle phases Read through Chapter 5, Royce s text. Compare the four life-cycle phases in Royce s text to the phases of the project life cycle depicted in Figure 3.2. Try to answer the following question: What are the similarities and differences between the four life-cycle phases in Royce s text and the phases of the project life cycle in Schwalbe s text?

39 Module 3 The Project Management and Information Technology Context Product life cycles Like projects, products also have a life cycle. Different types of products have different life cycles. Software development projects are one subset of information technology projects. A systems development life cycle (SDLC) is a framework for describing the phases involved in developing information systems. A SDLC includes the following popular life cycle model: Waterfall life cycle model: assumes that requirements will remain stable after they are defined. Spiral life cycle model: recognises the fact that most software is developed using an iterative or spiral approach rather than a linear approach. Incremental build life cycle model: provides for progressive development of operational software, with each release providing added capabilities. Prototyping life cycle model: is used for developing software prototypes to clarify user requirements for operational software. Rapid Application Development (RAD) life cycle model: uses an approach in which developers work with an evolving prototype. Developers use RAD tools such as computer-aided software engineering (CASE), joint requirements planning (JRP), and joint application design (JAD) to facilitate rapid prototyping and code generation. The above life cycle models are referred to as predictive life cycle, meaning that the scope of the project can be clearly articulated and the schedule and cost can be accurately predicated. On the contrary, the adaptive software development (ASD) life cycle model assumes software development follows an adaptive approach that projects are mission driven and component-based using time-based cycles to meet target dates. Extreme Programming (XP) and Scrum are two popular ASD life cycle models: Extreme Programming (XP): meets the needs of people developing software in rapidly changing environments. One unique feature of the XP life cycle model is that developers program in pair to promote synergy and increase productivity. Another unique feature of XP is that software developers must write the test code for their own code. Scrum: uses iterative development to address changing requirements, but the repetitions are referred to as sprints that normally last 30 days. Each day the entire team meets for a short meeting, called a scrum, where they decide to what to accomplish that day.

40 3.8 ELE4402 Software Engineering Project Management It is important to appreciate the difference between the project life cycle and product life cycle. The project life cycle applies to all projects independent of products being produced, while product life cycle models vary considerately based on the nature of the product. 3.5 Context of information technology projects This section highlights some issues unique to software development and information technology projects, which include the nature of projects, the characteristics of project team members, and the diverse nature of technologies involved. Information technology projects are very diverse. Some involve software development. Some are hardware-oriented projects. Others involve both software and hardware. Moreover, technologies used in IT projects change rapidly. As a result, people involved in IT projects come from very diverse backgrounds and possess different skill sets. 3.6 Suggested skills for a project manager For project managers, soft skills or people skills such as strong management, communication, leadership, and political skills are important in achieving high performance on projects. The following skills are desirable for all project managers: strong orgnisational skills teamwork skills strong coping skills be flexible, creative, and patient make effective use of technology. For IT project managers, both technical and soft skills are important. Unfortunately, many people in information technology focus more on technical skills.

41 Module 3 The Project Management and Information Technology Context 3.9 Reading Read Schwalbe s text Chapter 2. Review questions Complete Discussion Questions 1 7 in Chapter 2, Schwalbe s text to fulfil the objectives of Module 3. Exercises Complete Exercises 1 5 in Chapter 2, Schwalbe s text. Minicase Complete the Minicase in Chapter 2, Schwalbe s text.

42 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Royce. W 1998, Software project management: a unified framework, Addison-Wesley.

43 Module 4 THE PROJECT MANAGEMENT PROCESS GROUPS: A CASE STUDY

44

45 Module 4 The Project Management Process Groups: A Case Study 4.1 Objectives On successful completion of this module, you should be able to: ➀ describe the five project management process groups, the typical level of activity for each, and the interactions among them ➁ understand how the project management process groups relate to the project management knowledge areas ➂ discuss how organizations develop information technology project management methodologies to meet their needs ➃ review a case study of an organization applying the project management process groups to manage an information technology project ➄ understand the contribution that effective project initiation, project planning, project execution, project control, and project closing make to project success. Learning resources Text Chapter 3, Schwalbe (4th edition) Selected reading Selected reading 4.1: Section 1.1, Royce Module overview This module describes the five project management process groups and how they relate to the nine knowledge areas. It also describes how organizations can develop their own information technology project management methodologies to help manage their own projects in their unique environments. A large part of this chapter describes a detailed case study to show how to apply the project management process groups (initiating, planning, executing, controlling, and closing) to an information technology

46 4.2 ELE4402 Software Engineering Project Management project. The case study uses many of the templates provided in Appendix D of the text. In the following sections, we briefly summarise the key concepts and principles presented in this module. 4.1 Project management process groups A process is a series of actions directed towards a particular result. Project management process groups include the following five processes: ➊ Initiating processes: include actions to begin or end projects and project phases. ➋ Planning processes: include devising and maintaining a workable scheme to ensure the project addresses the company s needs. ➌ Executing processes: include coordinating people and resources to carry out the project plans and produce the deliverables of the project or phase. ➍ Controlling processes: ensure that the project team meets the project objectives. ➎ Closing processes: include formalising acceptance of the phase or project and ending it efficiently. The project management process groups and how they relate to each other for each major phase of a project is shown in Figure 4.1. As noted from this figure, the executing processes require the most resources and time, followed by the planning process. The initiating and closing processes require the least amount of resources and time. Note that Figure 4.1 can be applied either to each major phase of a project, namely, concept, development, implementation, and close-out as mentioned in Module 3, or an entire project. The certain tasks accomplished by each of the five project management process groups are summarised as follows: ➊ Initiating processes: complete a business case and project charter, select the project manager and key team members. ➋ Planning processes: complete the work breakdown structure, scope statement, the project schedule, and the project budget. ➌ Executing processes: delivery the actual work of the project. ➍ Controlling processes: complete the project successfully by delivering the agreeupon project scope within time, cost, and quality constraints. ➎ Closing processes: formal acceptance of the work and creation of closing documents, such as a final project report and lessons-learned report.

47 Module 4 The Project Management Process Groups: A Case Study 4.3 Figure 4.1: Overlap of Process Groups in a Phase (source: Schwalbe 2006, Fig. 3-1.) The main activities of each project management processes group can mapped into the nine project management knowledge ares. Table 4.1 (Table 3-1 in Schwalbe s text) shows how 39 project management activities are fitted into the 5 process groups, and the 9 knowledge areas. 4.2 Developing an information technology project management methodology Many organisations use the PMBOK Guide 2004 as a basis of their internal information project management methodologies. However, the project team of a organisation may realise that they would need to drop or deemphasize some processes in the PMBOK Guide 2004 to cater for the organisation s special needs. For example, in contrast to other industries where the overriding financial investment is in materials, the software development industry has salaries as its main financial investment. As a result, most of the procurement functions are absorbed into other processes, such as scope planning and definition, and resource planning. On the other hand, the project team may also add additional processes. For instance, some project teams develop new processes such as project book records, issue control, work plan development and project change control. These new processes combine several activities in the PMBOK Guide 2004 into one process, and are tailored

48 4.4 ELE4402 Software Engineering Project Management Table 4.1: Relationships among PM process groups and knowledge Knowledge Area Initiating Planning Executing Controlling Closing Integration Project plan development Scope Initiating Scope planning Scope definition Time Cost Activity definition Activity sequencing Activity duration estimating Schedule development Resource planning Cost estimating Cost budgeting Project plan execution Quality Quality planning Quality assurance Human Resource Communications Risk Procurement Organisational planning Staff acquisition Communications planning Risk management planning Risk identification Qualitative risk analysis Risk response planning Procurement planning Solicitation planning Team development Information distribution Solicitation Source Selection Contract administration Integrated change control Scope verification Scope change control Schedule control Cost control Quality control Performance reporting Risk monitoring and control Administrative closure Contract closeout

49 Module 4 The Project Management Process Groups: A Case Study 4.5 to the particular needs of organisations. Activity 4.1 The waterfall model The waterfall model is regarded as the classic conventional software management process. Read through Section 1.1 in Chapter 1, Royce s text to understand what the waterfall theory is and how the waterfall model works in practice. 4.3 Case study: JWD consulting s project management intranet site project This section illustrates the elements involved in managing an intranet project at JWD Consulating from start to finish by applying the project management process groups. The JWD Consulating case comes originally from the Opening Case of chapter 3 in Schwalbe s text Project initiation Initiating is the process of recognising and starting a new project or project phase. The selection of right, meaningful, and important projects for initiating is crucial. As indicated in Table 4.1, the PMBOK Guide 2004 lists project scope management as the only knowledge area associated with project initiation. The guide identifies the following four outputs: ➊ project charter ➋ assignment of the project manager ➌ classification of constraints ➍ a list of assumptions. As a comparison, to better suit the company s own needs, the project manager at JWD Consulting decides to adopt five process groups and has the following slightly different outputs for project initiation:

50 4.6 ELE4402 Software Engineering Project Management ➊ project charter completed and signed ➋ project manager assigned ➌ key stakeholders identified ➍ business case completed. A business case should include the following information: ➊ introduction/background ➋ business objective ➌ current situation and problem/opportunity statement ➍ critical assumptions and constraints ➎ analysis of options and recommendation ➏ preliminary project requirements ➐ budget estimate and financial analysis. The business case for JWD Consulting s intranet project is listed in Table 3-3 of Schwalbe s text. A project chart is preferably one or two pages in length, and should refer to other documents such as the business case, as needed. Table 3-4 in the text shows an example of JWD Consulting s project charter. Note the items included in the project and this short length. For this particular project, the most important parts of a project charter were the signatures of key stakeholders and their individual comments Project planning The main purpose of a project plan is to guide project execution. According to the PMBOK Guide 2004, Table 3-5 in Schwalbe s text lists the outputs of project planning in different project management knowledge areas. As the PMBOK Guide 2004 is a guide, so many organisations have different planning outputs based on their particular needs. For example, JWD Consulting s intranet site project has the following planning documents as the outputs: ➊ a team contract (native to this project) ➋ a scope statement ➌ a work breakdown structure (WBS)

51 Module 4 The Project Management Process Groups: A Case Study 4.7 ➍ a project schedule, in the form of a Gantt chart with all dependencies and resources entered ➎ a list of prioritised risks. A kick-off meeting is a good way to formally start the project. Its important function is to help the project team get to know each other. A team contract is part of the PMBOK Guide 2004, but native to the intranet site project. The project manager in this project uses the team contract to help promote teamwork and clarify team communications. Table 3-6 in Schwalbe s text gives an example on what a team contract looks like. The next task would be to develop a scope statement and WBS. As shown in Table 3-7 in the textbook, the scope statement of the intranet site project includes the project justification, the product characteristics and requirements, the summary of project deliverables, and the project success criteria. The work breakdown structure (WBS) is an important tool. It provides the basis for deciding how to do the work, and for creating the project schedule and performing earned value management for measuring and forecasting project performance. JWD Consulting s intranet project uses the project management process groups as the main categories for the WBS, as shown in Figure 3-3 in the prescribed text. The project team at JWD Consulting continues to develop a baseline schedule for the project. The project schedule can take the form of a Gantt chart or a network diagram. The two forms essentially represent the same information regarding the project schedule. A cost baseline was then developed as part of the project cost management. The major cost was internal labor, which is common for many information technology projects. Finally, the last deliverable of the planning process group is a list of prioritised risks. Table 3-8 in the text gives such an example Project executing The execution process usually takes the most resources to accomplish. Table 4.2 (Table 3-9 in Schwalbe s text) lists the major outputs of the project executing processes and their corresponding knowledge areas. It involves 5 out of 9 knowledge areas. As noted from the table, handling change requests is an important output. The top management at JWD Consulting likes to see progress on the project through milestone reports. A sample of a milestone report is provided in Table 3-10 of Schwalbe s text. During project execution, the project manager of the firm had to deal with human resources issues especially conflicts. Moreover, having effective communication skills and strong management support are essential to good project execution as we learned from the intranet project.

52 4.8 ELE4402 Software Engineering Project Management Table 4.2: Executing processes and outputs Knowledge Area Process Outputs Integration Project Plan Execution Work results Change requests Quality Quality Assurance Quality improvement Human Resources Team Development Performance improvements Inputs to performance Appraisals Communications Information Distribution Project records Project reports Project presentations Procurement Solicitation Source Selection Contract Administration Proposals Contracts Correspondence Contract changes Payment requests Project controlling Controlling is the process of measuring progress toward project objectives, monitoring deviation from the plan, and taking corrective action to match progress with the plan. It involves 7 out of 9 knowledge areas as shown in Table 4.3 (Table 3-11 of Schwalbe s text). An important tool for controlling processes is status reports. The project team at JWD Consulting had a practice of submitting weekly status reports. In addition to status reports, project management software is another important tool for controlling the project. The project team of the intranet site project used the enterprise version of Microsoft Project 2003 to distribute, update and analyse project information via the Web Project closing The major tasks in the closing process are to gain stakeholder and customer acceptance of the final product and bring the project, or project phase, to an orderly end. It is not unusual that many information technology projects are concealed before completion. Nevertheless, it is still important to formally close any uncompleted project and reflect on what can be learned to improve future projects. It is also important to plan for and execute a smooth transition of the project into the normal operations of the company.

53 Module 4 The Project Management Process Groups: A Case Study 4.9 Table 4.3: Controlling processes and outputs Knowledge Area Process Outputs Integration Integrated Change Control Project plan corrective actions Lessons learned Scope Scope Verification Scope Change Control Formal acceptance Scope changes Corrective actions Lessons learned Adjusted baseline Time Schedule Control Schedule updates Corrective actions Lessons learned Cost Cost Control Revised cost estimates Budget updates Corrective actions Estimate at completion Project closeout lessons learned Quality Quality Control Quality improvement Acceptance decisions Rework Completed checklists Process adjustments Communications Performance Reporting Performance reports Change requests Risk Risk Monitoring and Control Workaround plans Corrective actions Project change requests Updates to the risk response plan Risk database Updates to risk identification checklists

54 4.10 ELE4402 Software Engineering Project Management Table 4.4 (Table 3-13 of Schwalbe s text) lists the outputs of project closing and their corresponding knowledge areas. As noted from the table, the project closing process only involves 2 knowledge areas. Table 4.4: Closing processes and outputs Knowledge Area Process Outputs Communications Administrative Closure Project archives Project closure Lessons learned Procurement Contract Close-out Contract file Formal acceptance and closure In the example project, the project team prepared a final report, final presentation, contract files, and lessons-learned report to close the project. In the lessons-learned report, the project team summarised lessons learned from the project such as the importance of having a good kick-off meeting, working together to develop a team contract, using project management software, and communicating well with the project team and sponsor. The final project report prepared by the team at JWD Consulting included attachments for all the project management and product-related documents. The project manager also had the customer signed a client acceptance form before closing the project formally. The templates for the final project report and client acceptance form are available in Appendix D of the prescribed text. To summarise, the project management process groups, including initiating, planning, executing, controlling, and closing, provides a useful framework along with the project management knowledge areas for understanding project management.

55 Module 4 The Project Management Process Groups: A Case Study 4.11 Reading Read Schwalbe s text Chapter 3. Review questions Complete Review Questions 1 5 in Chapter 3, Schwalbe s text to fulfil the objectives of Module 4. Exercises Complete Exercises 1, 3, 4, 6 in Chapter 3, Schwalbe s text. Minicase Complete the Minicase in Chapter 3, Schwalbe s text.

56 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Royce. W 1998, Software project management: a unified framework, Addison-Wesley.

57 Module 5 PROJECT INTEGRATION MANAGEMENT

58

59 Module 5 Project Integration Management 5.1 Objectives On successful completion of this module, you should be able to: ➀ describe an overall framework for project integration management as it relates to the other project management knowledge areas and the project life cycle ➁ describe project plan development, including project plan content, using guidelines and templates for developing plans, and performing a stakeholder analysis to help manage relationships ➂ explain project plan execution, its relationship to project planning, the factors related to successful results, and tools and techniques to assist in project plan execution ➃ understand the integrated change control process, planning for and managing changes on information technology projects, and developing and using a change control system ➄ describe how software can assist in project integration management. Learning resources Text Chapter 4, Schwalbe (4th edition) Module overview This module provides detailed information on the first of the nine knowledge areas, project integration management. It describes project plan development, project plan execution, and integrated change control. This chapter again emphasizes the importance of making sure projects fit into the big picture of an organization. It also highlights the need for new project managers to let go of doing detailed technical work and focus on project management. Figure 5.1 provides an overview as to what processes, inputs, tools and techniques, and outputs project integration management involve, based on the PMBOK Guide In the following sections, we briefly summarise the key concepts and principles presented in this module.

60 5.2 ELE4402 Software Engineering Project Management Figure 5.1: Overview of Project Integration Management (source: PMBOK Guide 2004, p.79)

61 Module 5 Project Integration Management What is project integration management Project integration management involves coordinating all of the other project management knowledge areas throughout a project s life cycle. Three main processes involved in project integration management are as follows: ➊ Project plan development: involves putting the results of other planning processes into a consistent, coherent document, namely, the project plan. ➋ Project plan execution: involves carrying out the project plan by performing the activities included in it. ➌ Integrated change control: involves coordinating changes across the entire project. Project integration management ties together all the other eight project management knowledge areas. As a result, it depends on the inputs from the rest of the knowledge areas. Figure 5.2 presents a framework as to how project integration management serves as the guiding force in project management. The x-axis of the figure represents the project life cycle phases, where as the y-axis represents the other eight project management knowledge areas. As can be seen from Figure 5.2, the project integration management knowledge area is represented as an arrow that becomes more focused as the project processes through its life cycle. This indicates that project integration management pulls everything together to guide the project toward successful completion. Figure 5.2: Framework of Project Integration Management (source: Schwalbe 2006)

62 5.4 ELE4402 Software Engineering Project Management Project integration management is regarded by many project management professions as the key to overall project success. What project integration management is really about is to integrate the work of all of the people involved in the project by focusing on good communication and relationship management. Project integration management includes interface management, which involves identifying and managing the points of interaction between various elements of the project. It is important to understand that project integration management must occur within the context of the entire performing organisation, not just within a particular project. In other words, the objectives of one particular project must be subject to the overall interests of the entire organisation. 5.2 Project plan development Good project integration management starts from a good project plan. A project plan is document used to coordinate all project planning documents and help guide a project s execution and control Project plan contents Project plans vary greatly depending on the size and nature of the projects. However, there are common elements that most project plans include: ➊ an introduction or overview of the project ➋ a description of how the project is organised ➌ the management and technical processes used on the project ➍ sections describing the work to be performed ➎ schedule ➏ budget. The introduction or overview of the project plan should include, as a minimum, the following information: ➊ the project name ➋ a brief description of the project and the need it addresses ➌ the sponsor s name ➍ the names of the project manager and key team members

63 Module 5 Project Integration Management 5.5 ➎ deliverables of the project ➏ a list of important reference materials ➐ a list of definitions and acronyms. The description of how the project is organized should include the following information: ➊ organisational charts ➋ project responsibilities ➌ other organisational or process related information. The section of the project plan describing management and technical approaches should include the following information: ➊ management objectives ➋ project controls ➌ risk management ➍ project staffing ➎ technical processes. The section of the overall project plan describing the work to be done should reference the scope management plan and summarise the following information: ➊ major work packages ➋ key deliverables ➌ other work-related information. The project schedule information section should include the following information: ➊ summary schedule ➋ detailed schedule ➌ other schedule-related information. The budget section of the overall project plan should include the following information: ➊ summary budget ➋ detailed budget ➌ other budget-related information.

64 5.6 ELE4402 Software Engineering Project Management Using guidelines to create project plans It is a common practice that many organisations use guidelines to create project plans. Most project management software such as Microsoft Project 2002 provides several project plan template files to be used as guidelines. Some government agencies have their own guidelines for creating project plans. For instance, the U.S. Department of Defense (DoD) has its own standard for software development plan (DoD Standard 2167). The Institute of Electrical and Electronics (IEEE) also has its own standard (IEEE Standard ) for Software Project Management Plan (SPMP). It is imperative for companies working on software development projects for the U.S. Department of Defense to follow this standard. Activity 5.1 IEEE Standard for Software Project Management Plans Read through the IEEE Standard for Software Project Management Plans (available from < Fall-2005/seng5851/plans/IEEE_SPMP_Std_1058_1998.pdf> or search an alternative link if this one becomes invalid at the time of reading). Try and answer the following question: What are the five main sections specified in the standard? For most private organisations, it is not imperative to follow specific documentation standards rigorously. It is, however, a good practice to follow similar standards or guidelines for developing project plans in an organisation. It can improve work efficiency if all project plans follow a similar format Stakeholder analysis and top management support It is important to consider a stakeholder analysis in project planning as the ultimate goal of project management is to meet or exceed stakeholders expectations. A stakeholder analysis normally cover the following information: ➊ key stakeholders names and organisations ➋ key stakeholders roles on the project ➌ unique facts about each stakeholder

65 Module 5 Project Integration Management 5.7 ➍ each stakeholder s level of interest in the project ➎ key stakeholders influence on the project ➏ suggestions for managing relationships with each stakeholder. The main purpose of a stakeholder analysis is to help project managers understand and meet stakeholder needs and expectations. It will also help the project manager lead the execution of the project plan. It should be noted that a stakeholder analysis often includes sensitive information. Therefore, it should not be part of the project plan. In most cases, only the project manager and other key project team member should have the access to the stakeholder analysis. 5.3 Project plan execution Project plan execution involves managing and performing the work described in the project plans. The majority of the project s time as well as the budget is spent on execution, as the products of the project are produced during project execution. Project planning and execution are viewed as interwined and inseparable activities in project integration management. A rule of thumb to improve the coordination between project plan development and execution is: those who will do the work should plan the work. Strong leadership and a supportive organisational culture are two important factors for the success of project execution. Project managers often need to possess product, business, and application area knowledge to execute projects successfully. For many small software development projects, project managers may be required to perform some technical work. However, for larger projects, it is even more important for project managers to understand the business and application area of the technology, rather than the technology itself. There are some tools and techniques that facilitate project plan execution: ➊ Work Authorisation System: a method for ensuring proper communications so that qualified people do the work at the right time and in the proper sequence. ➋ Status Review Meetings: regularly scheduled meetings used to exchange project information. ➌ Project Management Software: can greatly assist in creating and executing the project plan.

66 5.8 ELE4402 Software Engineering Project Management 5.4 Integrated change control Integrated change control involves identifying, evaluating, and managing changes throughout the project life cycle. There are three main objectives of integrated change control which are summarised as follows: ➊ influencing the factors that create changes to ensure that changes are beneficial ➋ determining that a change has occurred ➌ managing actual changes as they occur The integrated change control process Table 5.1 lists the important inputs and outputs of the integrated change control process. Table 5.1: Inputs and outputs for the integrated change control process Inputs Ouputs Comments Project plans Project plan updates The project plan provides the baseline for identifying and controlling project changes Performance reports Take corrective actions Performance reports provide status information on how project execution is going Change requests Share lessons learned Determine if changes have occurred or should occur One should realise that change is unavoidable and often expected on almost all projects. This is especially true for projects in the field of information technology, where technologies in both software and hardware aspects advance so fast. Therefore, managing changes is a key issue in project management.

67 Module 5 Project Integration Management Change control system A change control system is a formal, documented process that describes when and how official project documents may be changed. The system mainly includes a change control board, configuration management, and a process for communications changes. A change control board (CCB) is a formal group of people responsible for approving or rejecting changes to a project. Its primary functions include: ➊ provide guidelines for preparing change requests ➋ evaluate change requests ➌ manage the implementation of approved changes. The primary drawback of CCBs is that it takes time for decisions to be made on proposed changes. Configuration management ensures that the descriptions of the project s products are correct and complete, and concentrate on the management of technology by identifying and controlling the functional and physical design characteristics of products and their support documentation. Some good suggestions for managing integrated change control are provided below: ➊ view project management as a process of constant communication and negotiation ➋ plan for change ➌ establish a formal change control system, including a CCB ➍ use good configuration management ➎ define procedures for making timely decisions on smaller changes ➏ use written and oral performance reports to help identify and manage change ➐ use project management and other software to help manage and communication changes. It should be stressed that the role of project managers is to provide strong leadership to steer the project to successful completion, rather than focus on detailed work which should be delegated to project team members.

68 5.10 ELE4402 Software Engineering Project Management 5.5 Using software to assist in project integration management Project management software can assist in many aspects of developing and integrating project planning documents, executing the project plans, and performing integrated change control. Activity 5.2 ResNet Project Case Study: management efficiency How PM software helps improve Read through Northwest Airlines ResNet Project available online at < ResNetCaseStudy.pdf>. Try to answer the following question: What project management software tools did the ResNet project team use? What aspects did the PM software tools help the project team improve management efficiency in?

69 Module 5 Project Integration Management 5.11 Reading Read Schwalbe s text Chapter 4. Review questions Complete Review Questions 1 5 in Chapter 4, Schwalbe s text to fulfil the objectives of module 1. Exercises Complete Exercises 1, 2, 3, 5 in Chapter 4, Schwalbe s text. Minicase Complete the Minicase in Chapter 4, Schwalbe s text.

70 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution.

71 Module 6 PROJECT SCOPE MANAGEMENT

72

73 Module 6 Project Scope Management 6.1 Objectives On successful completion of this module, you should be able to: ➀ understand the elements that make good project scope management important ➁ describe the strategic planning process, apply different project selection methods, such as a net present value analysis, a weighted scoring model, and a balanced scorecard, and understand the importance of creating a project charter ➂ explain the scope planning process and contents of a scope statement ➃ discuss the scope definition process and construct a work breakdown structure using the analogy, top-down, bottom-up, and mind mapping approaches ➄ understand the importance of scope verification and scope change control to avoid scope creep on information technology projects ➅ describe how software can assist in project scope management. Learning resources Text Chapter 5, Schwalbe (4th edition) Module overview This module discusses a very important knowledge area and part of the triple constraintproject scope management. It also describes various methods for selecting projects, including using various financial analysis techniques, weighted scoring models, and a balanced scorecard. Once projects are selected, it is crucial to do a good job defining the work to be done and how it will be done. Important tools include developing a project charter, scope statement, and work breakdown structure. Figure 6.1 provides an overview as to what processes, inputs, tools and techniques, and outputs project scope management involve, based on the PMBOK Guide In the following sections, we briefly summarise the key concepts and principles presented in this module.

74 6.2 ELE4402 Software Engineering Project Management Figure 6.1: Overview of Project Scope Management (source: 2004, p. 105) PMBOK Guide

75 Module 6 Project Scope Management What is project scope management Defining the scope of a project is one of the most important and difficult aspects of project management. Scope refers to all the work involved in creating the deliverables of the project. Deliverables can be product-related such as a software module, or process-related such as a planning document. Project scope management includes the processes involved in defining and controlling what is or is not included in a project. The five main processes involved in project scope management are as follows: ➊ Initiation: involves committing the organisation to begin a project or continue to the next phase of a project. A project charter, a key document for formally recognising the existence and providing a broad overview of a project, is the output of this process. ➋ Scope planning: involves developing documents to provide the basis for future project decisions. A scope statement and project scope management plan are the outputs of this process. ➌ Scope definition: involves subdividing the major deliverables into smaller, more manageable components. A work breakdown structure (WBS) is the output of this process. ➍ Scope verification: involves formalising acceptance of the project scope. ➎ Scope change control: involves controlling changes to project scope. Scope changes, corrective action, and lessons learned are outputs of this process. 6.2 Project initiation: strategic planning and project selection Project selection is the first step in project scope management. As illustrated in Figure 5-1 in Schwalbe s text, the four-stage planning process for selecting information technology projects is as follows: ➊ Strategic planning: Tie information technology strategy to mission and vision of organisation. Identify key business areas. The SWOT (Strengths, Weakness, Opportunities, and Threats) analysis is often used in strategic planning. ➋ Business area analysis: Document key business processes that could benefit from information technology. ➌ Project planning: Define potential projects. Define project scope, benefits, and constraints.

76 6.4 ELE4402 Software Engineering Project Management ➍ Resource allocation: Select information technology projects. Assign resources. Organisations should align their information technology departments more closely with the core business. Most organisations face many problems and opportunities for improvement at one time. However, the organisation s strategic plan should guide the project selection process. Organisation should invest in IT projects that are central to business strategy. Wal-Mart s inventory control system and FedExp s online package tracking systems were successful stories in this regard. Table 5-1 in Schwalbe s text summarises the main reasons why organisations invest in information technology projects Methods for selecting projects Five common techniques for selecting projects from possible candidates are: ➊ focus on broad organisational needs. ➋ categorise information technology projects. ➌ perform net present value or other financial analyses. ➍ use a weighted scoring model ➎ implement a balanced scoreboard. For the first method, projects that address broad organisational needs are much more likely to be successful because they will be important to the organisation. Three criteria for selecting projects based on broad organisational needs are need, funding, and will. For the second method, there exist three categorisations of information technology projects: ➊ The first categorisation assesses whether projects provide a response to a problem, an opportunity, or a directive. Projects that address problems or directives are more likely to get funding approval because the organisation must response to these categories of projects to avoid hurting their business. ➋ The second categorisation is based on time it will take to complete a project or the date by which it must be done. ➌ The third categorisation is the overall priority of the project. High priority projects should always be completed first, even if a lower priority project takes less time. For the third method of selecting IT projects, there are three primary methods for determining the projected financial value of projects include net present value analysis, return on investment, and payback analysis.

77 Module 6 Project Scope Management 6.5 Net present value analysis Net present value (NPV) analysis is a method of calculating the expected net monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time. A positive NPV means the return from a project exceeds the cost of capital, which is the return available by investing the capital elsewhere. Activity 6.1 Cash Flow vs. Net Present Value Cash flow is the benefits minus costs or income minus expenses. Study the example in Figure 5-2 of Schwalbe s text. Try and answer the following question: What is the fundamental difference between cast flow and net present value? The steps below should be followed to determine NPV: ➊ Determine the estimated costs and benefits for the life of the project and the products it produces. ➋ Determine the discount rate, that is the minimum acceptable rate of return on an investment. ➌ Calculate the net present value using the following equation: NPV = n t=1 A t (1 + r) t, (6.1) where t is the year of the cash flow, A t equals the amount of cash flow in year t, and r is the discount rate. 1/(1 + r) t is referred to as the discount factor. Alternatively, NPV can be calculated as follows: NPV = T B T C, (6.2) where T B is the total discounted benefits, whereas T C is the total discounted costs. Return on investment Return on investment (ROI) is the result of subtracting the project costs from the benefits and then dividing by the costs. The calculation is represented by the following equation:

78 6.6 ELE4402 Software Engineering Project Management ROI = T B T C T C. (6.3) The required rate of return is the minimum acceptable rate of return on an investment. That is what an organisation could expect to receive elsewhere for an investment of comparable risk. A project s internal rate of return (IRR) is the discount rate that results in a zero NPV for the project. The Goal Seek function in Excel can be used to determine the IRR conveniently. Many organisations have a required rate of return for projects to be invested. The majority of organisations use ROI in the project selection process as reviewed by a survey conducted by Information Week in Payback analysis Payback period is the amount of time it will take to recoup, in the form of net cash inflows, the net dollars invested in a project. Payback occurs when the following condition is satisfied: C B C C > 0, (6.4) where C B is the cumulative discounted benefits, whereas C C is the cumulative discounted costs. It is often easier to illustrate the payback period using a graphical chart as shown in Figure 5-4 in Schwalbe s text. For project selection, it is important for project managers to select projects of which payback periods are in line with the organisation s financial expectations. As the fourth method of selecting IT projects, weighted scoring model is a tool that provides a systematic process for selecting projects based on many criteria. The first step in creating a weighted scoring model is to identify criteria important to the project selection process. Some possible criteria for selecting information technology projects include: ➊ supports key business objective ➋ has strong internal sponsor ➌ has strong customer support ➍ uses realistic level of technology ➎ can be implemented in one year or less ➏ provides positive NPV ➐ has low risk in meeting scope, time, and cost goals.

79 Module 6 Project Scope Management 6.7 The second step is to assign a weight to each criterion, indicating how important each criterion is. The third step is to assign a numerical score to each criterion for each project, indicating how much each project meets each criterion. The weighted score for each project can be calculated as follows: W = w 1 s 1 + w 2 s 2 + w 3 s w n s n, (6.5) where W is the overall weighted score for the target project, n is the number of total criteria, w i and s i are the weight and numerical score for the criterion i, respectively. It is evident that the project with the greatest weighted score should be selected over the other candidates. The fifth method of selecting IT projects is the balanced scorecard. A balanced scorecard is a methodology that converts an organisation s value drivers, such as customer service, innovation, operational efficiency, and financial performance, to a series of defined metrics. These metrics can be analysed by organisations to determine how well projects help them achieve strategic goals Project charters A project charter is a document that formally recognises the existence of a project and provides direction on the project s objectives and management. Activity 6.2 Project charter Read through the sample project charter in Table 5-2 and the project charter template in Appendix D in Schwalbe s text. Try to answer the following question: What key parts a project charter should include? Depending on the nature of the project, a project charter can be as simple as a onepage form or much longer. It should be noted that some organisations use a simple letter of agreement or a formal contract to serve as a project charter. Many projects fail due to unclear requirements and expectations. As a result, starting with a simple but clear project charter is very meaningful. When project stakeholders have disagreement with certain aspects of the project, they can refer to what every agreed to in the project charter.

80 6.8 ELE4402 Software Engineering Project Management 6.3 Scope planning and the scope statement Scope planning is the next step in project scope management after finalising the project charter. Project scope planning involves developing documents to provide the basis for future project decisions, including the criteria for determining if a projector phase has been completed successfully. The main inputs and outputs of the scope planning process are listed in Figure 6.1. A scope statement is a document used to develop and confirm a common understanding of the project scope. It describes in detail that the work to be accomplished on the project and is an important tool for preventing scope creep. The scope statement should include the following items: ➊ A project justification: describes the business need that sparked creation of the project. ➋ A brief description of the project s products: summarises the characteristics of the products or services that the project will produce. ➌ A summary of all project deliverables: lists the deliverables of the project. ➍ A statement of what determines project success: lists the quantifiable criteria to meet for project success, such as cost, schedule, and quality measures. ➎ References to supporting documents: provide the names of related documents. 6.4 Scope definition and the work breakdown structure Scope definition is the process of breaking work into manageable pieces. The work breakdown structure is the output of the process Work breakdown structure A work breakdown structure (WBS) is a deliverable-oriented grouping of the work involved in a project that defines the total scope of the project. It serves the purpose of breaking down the whole project work into manageable pieces. The WBS is a foundation document in project management, as it provides the basis for planning and managing project schedules, costs, resources, and changes. The WBSs can be organised by project products, project phases, or project management process group. The presentation of a WBS can be visualised by a organisational chart form, a tabular form, and a Gantt chart.

81 Module 6 Project Scope Management 6.9 Activity 6.3 Organisation of the Work Breakdown Structure Read through the example WBS structures in Figures 5-6, 5-7, 5-8, 5-9 and Table 5-3 in Schwalbe s text. Try to answer the following questions: How is each example WBS organised? What is the visualisation form used by each example WBS? What are the advantages and disadvantages of organising WBSs by project products, project phases, and project management process group? What are the advantages and disadvantages of visualising WBSs by the organisational chart form, tabular form, and Gantt chart form? The WBSs present project information in a hierarchical form. The lowest level of the WBS represents work packages, which are tasks at the lowest level of the WBS. As a rule of thumb, average work package should represent roughly 80 hours of effort. For smaller projects with relatively short time frame, a work package might represent 40 hours of work. For larger projects, this number might be 100 hours. It should be pointed out that there are two main advantages for creating WBSs by using the project management process groups of initiating, planning, executing, controlling, and closing as level 1 in the WBS: ➊ Allow the project team to follow good project management practice ➋ The WBS tasks can be mapped more easily against time. Finally, it is important to involve the entire project team and customer in creating and reviewing the WBS Approaches to developing work breakdown structures Developing the WBS is an important task itself. The following approaches exist for developing WBSs: ➊ using guidelines

82 6.10 ELE4402 Software Engineering Project Management ➋ the analogy approach ➌ the top-down approach ➍ the bottom-up approach ➎ the mind-mapping approach. Using guidelines Some organisations require prescribed form and content for WBSs for particular projects, e.g., the U.S. Department of Defense. Many organisations provide guidelines and templates for developing WBSs as well as examples of WBSs from past projects. The Project Management Institute (PMI) developed a WBS Practice Standard to provide guidance for developing and applying the WBS to project management. The analogy approach The analogy approach of developing WBSs is to use a similar project s WBS as a starting point. Some organisations keep a repository of WBSs of past projects, so that a project manager can easily select a past WBS as the starting point of creating the project s WBS. The top-down and bottom-up approach The top-down approach starts with the largest items of the project and breaks them into their subordinate items. It then refines the work into greater and greater levels of detail. The top-down approach is suitable for project managers who have vast technical insight and a big-picture perspective. As a comparison, the bottom-up approach first identifies as many specific tasks related to the project as possible. It then aggregates the specific tasks and organises them into summary activities. The bottom-up approach can be very time-consuming but a very effective way to create a WBS. Mind mapping Mind mapping is a technique that uses branches radiating out from a core idea to structure thoughts and ideas. It is a more visual and less structured approach, allowing people to write and even draw pictures of ideas in a non-linear format. Mind mapping can be combined with the top-down and bottom-up approach to develop WBSs.

83 Module 6 Project Scope Management Advice for creating a WBS The previous section discussed several approaches for developing WBSs. In fact, these approaches are often combined together. There are some general principles for creating good WBSs: ➊ a unit of work should appear at only one place in the WBS ➋ the work content of a WBS item is the sum of the WBS items below it ➌ a WBS item is the responsibility of only one individual, even though many people may be working on it ➍ the WBS must be consistent with the way in which work is actually going to be performed ➎ project team members should be involved in developing the WBS to ensure consistency and buy-in ➏ each WBS item must be documented to ensure accurate understanding of the scope of work included and not included in that item ➐ the WBS must be a flexible tool to accommodate inevitable changes while properly maintaining control of the work content in the project according to the scope statement. 6.5 Scope verification and scope change control Many projects especially information technology projects suffer from the same tendency that project scope keeps getting bigger and bigger. This is called scope creep. As a result, it is very important to verify the project scope and develop a process for controlling scope changes. Scope verification involves formal acceptance of the project scope by the stakeholders, whereas scope change control involves controlling changes to the project scope. Table 5-5 in Schwalbe s text lists 10 factors causing information technology project problems in order of importance. It is noted that the top three factors, i.e., lack of user input, incomplete requirements and specifications, and changing requirements and specifications, directly relate to scope verification and change control. It is evident that in order to verify project scope and control scope change more efficiently, the project manager needs to improve the top three factors aforementioned.

84 6.12 ELE4402 Software Engineering Project Management Suggestions for improving user input Lack of user input accounts for the no. 1 factor contributing to IT project failure. Some suggestions to improve user input are given as follows: ➊ develop a good project selection process for IT project. Insist that all projects have a sponsor from the user organisation ➋ have users on the project team ➌ have regular meetings ➍ deliver something to project users and sponsors on a regular basis ➎ co-locate users with the developers Suggestions for reducing incomplete and changing requirements It should be stressed that some requirement changes are inevitable and expected during the project life cycle. However, many failed projected had too many changes to their requirements, especially during the later stages of the project life cycle when it is too difficult to implement changes. Some suggestions to improve the requirements process are given as follows: ➊ develop and follow a requirement management process that includes procedures for initial requirements determination ➋ employ techniques such as prototyping, use case modeling, and joint application design to understand user requirements thoroughly ➌ put all requirements in writing and keep them current and readily available ➍ create a requirements management database for documenting and controlling requirements ➎ provide adequate testing to verify that the project s products perform as expected ➏ use a process for reviewing requested requirements change from a systems perspective ➐ emphasise completion dates ➑ allocate resources specifically for handling change requests.

85 Module 6 Project Scope Management Using software to assist in project integration management Project scope management is an important area in project management. Therefore, there exist many general and specialised computer programs to assist in project management. Most people use spreadsheet software to perform financial calculations, create weighting scoring models, and develop various charts and graphs related to project scope management. Many project management software packages such as Microsoft Project provide templates for creating a good WBS, which serves as a basis for creating Gantt charts, assigning resources, allocating costs, etc. Refer to Appendix D in Schwable s text for templates related to project scope management. There are also some specialised software to help project scope management. The examples include software for applying the balanced scorecard method for project selection, software for applying the mind mapping approach for WBS creation, software for requirements management, prototyping, modeling, and other scope-related work.

86 6.14 ELE4402 Software Engineering Project Management Reading Read Schwalbe s text Chapter 5. Review questions Complete Review Questions 1 6 in Chapter 5, Schwalbe s text to fulfil the objectives of module 6. Exercises Complete Exercises 1, 2, 3, 5 in Chapter 5, Schwalbe s text. Minicase Complete the Minicase in Chapter 5, Schwalbe s text.

87

88 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution.

89 Module 7 PROJECT TIME MANAGEMENT

90

91 Module 7 Project Time Management 7.1 Objectives On successful completion of this module, you should be able to: ➀ understand the importance of project schedules and good project time management ➁ define activities as the basis for developing project schedules ➂ describe how project managers use network diagrams and dependencies to assist in activity sequencing ➃ explain how various tools and techniques help project managers perform activity duration estimating and schedule development ➄ use a Gantt chart for schedule planning and tracking schedule information ➅ understand and use critical path analysis ➆ describe how to use several techniques for shortening project schedules ➇ explain the basic concepts behind critical chain scheduling and Program and Review Technique (PERT) ➈ discuss how reality checks and people issues are involved in controlling and managing changes to the project schedule ➉ describe how software can assist in project time management. Learning resources Text Chapter 6, Schwalbe (4th edition) Selected reading Selected reading 7.1: Chapter 5, Mantel, Jr et. al. (2nd edition)

92 7.2 ELE4402 Software Engineering Project Management Module overview This module discusses another very important knowledge area and part of the triple constraint project time management. Important concepts in this chapter include developing project schedules, creating network diagrams and Gantt charts, critical chain scheduling, and PERT. Figure 7.1 provides an overview as to what processes, inputs, tools and techniques, and outputs project time management involve, based on the PMBOK Guide In the following sections, we briefly summarise the key concepts and principles presented in this module. 7.1 Importance of project schedules Project managers often cite delivering projects on time and schedule issues as the main reasons for conflicts on projects throughout the project life cycle. As depicted in Figure 6-1 in Schwalbe s text, priorities and procedures cause more conflict than schedules during the project concept phase. During the early or development phase only, priorities cause more conflict than schedules. During the middle or implementation phase and close-out phase, schedule issues are the predominant source of conflict. The main reason why schedule problems are so common in project management is that time is easily and simply measured, and has the least amount of flexibility. Time passes no matter what happens on a project. Project time management involves the processes required to ensure timely completion of a project. Project time management includes five main processes as follows: ➊ Activity definition: involves identifying the specific activities that the project team members and stakeholders must perform to produce the project deliverables. ➋ Activity sequencing: involves identifying and documenting the relationships between project activities. ➌ Activity duration estimating: involves estimating the number of work periods that are needed to complete individual activities. ➍ Schedule development: involves analysing activity sequences, activity duration estimates, and resource requirements to create the project schedule. ➎ Schedule control: involves controlling and managing changes to the project schedule.

93 Module 7 Project Time Management 7.3 Figure 7.1: Overview of project time management (source: PMBOK Guide 2004, p. 125)

94 7.4 ELE4402 Software Engineering Project Management 7.2 Activity definition Preliminarily planned project start and end dates are often included in the project chart. These dates serve as the starting point for a more detailed project schedule. Based on the scope statement, work breakdown structure (WBS), and budget information, the project manager and project team begin developing a detailed project schedule and estimated completion date. The project manger may have to negotiate changes in scope or cost to meet schedule expectations, if the estimated completion dates are significantly different from top management s or the customer s original plans. The order of the triple constraint of project management, i.e., scope, time, and cost, reflects the basic order of the first three processes in project time management, namely, activity definition, activity sequencing, activity duration estimating. Activity definition usually results in a more detailed WBS and supporting explanations. The WBS is often dissected further during the activity definition process as the project team members further define the activities required for performing the work. Activity definition also results in supporting detail to document important product information as well as assumptions and constraints related to specific activities. 7.3 Activity sequencing Activity sequencing involves reviewing the activities in the detailed WBS, detailed product descriptions, assumptions, and constraints to determine the relationships between activities. Also included in activity sequencing is to evaluate the reasons for dependencies and the different types of dependencies Dependencies A dependency or relationship is the sequencing of project activities or tasks. There are three basic dependencies among project activities: ➊ Mandatory dependencies: are inherent in the nature of the work being done on a project. They are sometimes referred to as hard logic. ➋ Discretionary dependencies: are defined by the project team. ➌ External dependencies: involve relationships between project and non-project activities. It is important that project stakeholders work together to define the activity dependencies existed on their project. Otherwise, the project team can not use two of the most powerful schedule tools, namely, network diagram and critical path analysis.

95 Module 7 Project Time Management Network diagrams A project network diagram is a schematic display of the logical relationships among, or sequencing of, project activities. The activity-on-arrow (AOA) or the arrow diagramming method (ADM) is one of the network diagramming techniques in which activities are represented by arrows and connected at points called nodes to illustrate the sequence of activities. A node is simply the starting and ending point of an activity. The network diagram represents activities that must be done to complete the project. As a result, every activity on the project network diagram must be completed in order for the project to finish. On the other hand, not every single item on the WBS needs to be on the network diagram. Sometimes it is enough to put summary tasks on a network diagram. Some items that must be done regardless of other activities do not need to be included on the network diagram either. One should follow the following steps to create an AOA network diagram: ➊ Find all of the activities that start at Node 1. Draw their finish nodes, and draw arrows between Node 1 and each of those finish nodes. Put the activity letter or name, and a duration estimate (if available) on the associated arrow. ➋ Continuing drawing the network diagram, working from the left to right. Look for bursts and merges. ➌ Continuing drawing the network diagram until all activities are included on the diagram. ➍ As a rule of thumb, all arrowheads should face toward the right, and no arrows should cross on an AOA network diagram. Redraw the diagram to make it look presentable if necessary. The precedence diagramming method (PDM) is another network diagramming technique in which boxes represent activities. The PDM is more commonly used than AOA. There are four types of dependencies between activities defined in the PDM: ➊ finish-to-start (FS) ➋ start-to-start (SS) ➌ finish-to-finish (FF) ➍ start-to-finish (SF). The four types of dependencies are visulalised in Figure 7.2, which is taken from a snapshot of Microsoft Project Help screen. Note that dependency and relationship are used interchangeably, so are activity and task.

96 7.6 ELE4402 Software Engineering Project Management Figure 7.2: Four types of task dependencies (source: Microsoft Project Help screen) As illustrated in Figure 6-4 in Schwalbe s text, the activities are placed inside boxes, which represent the nodes on the PDM diagram. Arrows and arrowheads show the relationships between activities. If Microsoft Project is used to create network diagrams, the border of the boxes for tasks on the critical path will appear in red. The PDM technique is preferred over the AOA techniques for three advantages: ➊ most project management software packages use the PDM ➋ the PDM avoids the use of dummy activities, which have no duration no resources but are occasionally needed on AOA network diagrams to show logical relationships between activities ➌ the PDM shows different dependencies among tasks, whereas AOA network diagrams use only finish-to-start dependencies. 7.4 Activity duration estimation Activity duration estimation is the next step in project time management after activity definition and sequencing. Duration sometimes can be confused with effort. The former refers to the actual amount of time worked on an activity plus elapsed time, whereas the latter means

97 Module 7 Project Time Management 7.7 the number of work days or work hours required to complete a task. Duration relates to the time estimate, not the effort estimate. The inputs to activity duration estimating include the detailed activity list and sequencing and historical information. The outputs of activity duration estimating include duration estimates for each activity, a document describing the basis of the estimates, and updates to the WBS. 7.5 Schedule development Gantt charts Henry Gantt developed the first Gantt chart during World War I for scheduling work in factories. Early versions of Gantt charts normally do not show relationships among projects, which is a major disadvantage. However, project management software such as Microsoft Project can assist in creating more sophisticated Gantt charts that can also show dependencies in some format, but not as clearly as they would be displayed on a network diagram. Figure 7.3 is a typical Gantt chart for a software development project as shown in Microsoft Project. As noted in Figure 7.3, there are different symbols used on the Gantt chart: Milestone: black diamond symbol that represents a significant event with zero duration Summary tasks: thick black bars Individual tasks: light gray horizontal bar Relationships or dependencies between tasks: arrows connecting the task symbols. Milestone tasks are those with zero duration. The SMART criteria are used as guidelines to identify milestones, meaning that milestones should be: specific measurable assignable realistic time-framed.

98 7.8 ELE4402 Software Engineering Project Management Figure 7.3: Gantt chart for a software development project

99 Module 7 Project Time Management 7.9 A tracking Gantt chart is a special Gantt chart that compares planned and actual project schedule information. The planned schedule dates for activities are called the baseline dates. Figure 7.4 depicts a tracking Gantt chart. As a progress evaluation tool, tracking Gantt charts have a few additional symbols: ➊ Each task often has two horizontal bars. The top one represents the planned or baseline duration for each task, whereas the bar below it represents the actual information. ➋ A striped horizontal bar represents the planned duration for summary tasks. The black bar adjoining it shows progress for summary tasks. ➌ A white diamond on the tracking Gantt chart represents a slipped milestone that is completed later than originally planned. ➍ Percentages to the right of the horizontal bars display the percentage of work completed for each task. Compared to the network diagram, the main disadvantage of Gannt charts lies in the fact that Gantt charts do not usually show dependencies between tasks. However, project management software packages such as Microsoft Project can create Gantt charts with the dependencies displayed, provided tasks are linked. Nevertheless, the dependencies are not shown as clearly as they would be displayed on a network diagram. Detailed interpretations on how Gantt charts and tracking Gantt charts work can be found on Appendix A in Schwalbe s text, or by consulting Microsoft Project help documents Critical path method Critical path method (CPM), also known as critical path analysis, is a project network analysis technique used to predict total project duration. It is an important tool that helps project managers combat project schedule overrun. A critical path for a project is the series of activities (tasks) that determine the earliest time by which the project can be completed. It is the longest path through the project network diagram. Slack or float is the amount of time an activity may be delayed without delaying a succeeding activity or the project finish date. Given a network diagram, how to calculate the critical path involves adding the durations for all activities on each path through the network diagram. The longest path is the critical path. However, the critical path represents the shortest time it takes to complete a project. There are some common misconceptions about the critical path:

100 7.10 ELE4402 Software Engineering Project Management Figure 7.4: Tracking Gantt chart

101 Module 7 Project Time Management 7.11 ➊ The word critical does not indicate that the critical path includes all critical activities. Rather, it is only concerned with the time dimension of a project. ➋ Although the critical path is the longest path, it represents the shortest time it takes to complete the project, because each activity must be done to complete the project. ➌ There can be two or more critical paths on a project instead of just one. ➍ The critical path on a project can change as the project progresses. It does not have to be static. Some important concepts related to the critical path method are summarised as follows: Early start date: the earliest possible time an activity can start based on the project network logic. Early finish date: the earliest possible time an activity can finish based on the project network logic. Late start date: the latest possible time an activity might begin without delaying the project finish date. Late finish date: the latest possible time an activity can be completed without delaying the project finish date. Free slack or float is the amount of time that an activity can be delayed without delaying the early start date of any immediately following activities. Total slack or float is the amount of time that an activity can be delayed from its early start without delaying the planned project finish date. The early start and finish dates for a project can be determined by a forward pass of the project network diagram. Likewise, the late start and finish dates for a project can be determined by a backward pass of the project network diagram. One need to following the following rules for the forward and backward passes. Note this information is not available in Schwalbe s text, but taken from chapter 6 in Hughes and Cotterell s text. ➊ Forward pass rule: the earliest start date for an activity is the earliest finish date for the preceding activity. Where there is more than one immediately preceding activity, one should take the latest of the earliest finish dates for those activities. ➋ Backward pass rule: the latest finish date for an activity is the latest start date for all the activities that may commence immediately that activity is complete. Where more than one activity can commence, one should take the earliest of latest start dates for those activities. The significance of identifying critical paths of a project is that project managers can reduce the duration of the project by shortening the duration of critical path activities using duration compression techniques such as crashing and fast tracking. Table 7.1 compares these two techniques, i.e., crashing and fast tracking.

102 7.12 ELE4402 Software Engineering Project Management Table 7.1: Crashing and fast tracking Technique What It Is Main Disadvange Crashing Fast tracking A technique for making cost and schedule trade-offs to obtain the greatest amount of schedule compression for the least incremental cost Involves doing activities in parallel that one would normally do in sequence. Often increases total project costs It can end up lengthening the project schedule since starting some tasks too soon often increases project risk and results in rework Critical chain scheduling Critical chain scheduling is another technique, which is based on the theory of constraints to meet project complete schedule. The theory of constraints (TOC), a management philosophy developed by Eliyahu M. Goldratt, is based on the fact that any complex system at any point in time often has only one aspect or constrain that limits its ability to achieve more of its goal, like a chain with its weakest link. Critical chain scheduling is a method of scheduling that considers limited resources when creating a project schedule and includes buffers to protect the project completion date. As a comparison to critical path method that does not consider resource allocation, critical chain scheduling takes the availability of resources into consideration when scheduling projects. Multitasking occurs when a resource works on more than one task at a time. Multitasking often wastes setup time, increases total project duration and is thus avoided by critical chain scheduling. The examples in Figures 6-10a and 6-10b in Schwalbe s text illustrate how multitasking can delay task completion. Multitasking also often cause wasted setup time, which increases total project durations. Critical chain scheduling is based on the assumption that resources do not multitask. This avoids resource conflicts and wasted setup time, which is caused by shifting between multiple tasks over time. Project buffer is additional time added before the project s due date. Feeding buffer is additional time added before tasks on the critical chain that are preceded by by noncritical-path tasks. Critical chain scheduling normally results in shorter task estimates than traditional estimates because it removes each individual task s buffer. To summarise, critical chain scheduling is a complicated yet powerful tool that involves critical path analysis, resource constraints, and changes in how task estimates are made in terms of buffers.

103 Module 7 Project Time Management Program evaluation and review technique (PERT) Program Evaluation and Review Technique (PERT), yet another project time management technique, is a network analysis technique used to estimate project duration when there is high degree of uncertainty about the individual activity duration estimates. PERT uses probabilistic time estimates that are based on using optimistic, most likely, and pessimistic estimates of activity durations. PERT is also based on a network diagram and calculates the weighted average duration estimate of each project activity using the following formula: T w = T o + 4 T m + T p, (7.1) 6 where T w is the PERT weighted value, T o is the optimistic time, T m is the most likely time, and T p is the pessimistic time. Do not confuse PERT with network diagrams, which are often referred to as PERT charts. 7.6 Controlling changes to the project schedule As a matter of fact, most projects fail because of people issues rather than technique failure. As a result, project managers can perform a number of reality checks that will help them manage project schedule change. Two techniques exist to perform reality checks on scheduling: ➊ review the draft schedule usually included in the project charter ➋ have progress meetings with stakeholders. Leadership skills that project mangers need to control project schedule changes include: ➊ empowerment ➋ incentives ➌ discipline ➍ negotiation.

104 7.14 ELE4402 Software Engineering Project Management Setting firm dates for key project milestones helps minimise project schedule changes. It is also very important for the project managers and team members to defend their estimates and learn to negotiate with demanding stakeholders. Some concepts in project time management such as the PERT and CPM are very important. It is imperative to understand the underlying principles of the concepts before one can perform time management. It is felt by the instructor that the treatment of the PERT and CPM concepts in Schwalbe s text is not comprehensive. For more systematic treatment of these concepts, students are encouraged to read Chapter 6 in Hughes and Cotterell s text. For numerical examples of the PERT and CPM, students are encouraged to read chapter 5 in Mantel, Jr et. al. s text. 7.7 Using software to assist in project time management Project management software such as Microsoft Project is very powerful in assisting in project time management. It can be used to draw network diagrams, determine the critical path for a project, create Gantt charts, and report, view, and filter specific project time management information. Microsoft Project can easily create Gantt charts and tracking Gantt charts. It also includes many build-in reports, views, and filters to assist in project time management. Although it is very convenient to use project management software to help project time management, it is critical for project managers and their team members to understand the underlying concepts related to project time management.

105 Module 7 Project Time Management 7.15 Activity 7.1 Microsoft Project Applied to JWD Consulting s Project Case Study Read through the JWD Consulting s intranet project case study in Module 4. Make sure you understand the overall project information and context. Try to complete the following activities: ➊ Based on the WBS given in Figure 3-3, and the milestone report deadlines in Table 3-10 in Schwalbe s text, use Microsoft Project to draw the project s baseline Gantt chart. You may need to make reasonable assumptions about some tasks starting and ending dates in the WBS to accomplish this task. ➋ Use Microsoft Project to draw the network diagram of this project. Point out the critical path on the diagram, and work out the duration of the critical path.

106 7.16 ELE4402 Software Engineering Project Management Reading Read Schwalbe s text Chapter 6. Read Hughes and Cotterell s text Chapter 6. Read Mantel, Jr et. al. s text Chapter 5. Review questions Complete Review Questions 1 8 in Chapter 6, Schwalbe s text to fulfil the objectives of Module 7. Exercises Complete Exercises 1 4 in Chapter 6, Schwalbe s text. Minicase Complete the Minicase in Chapter 6, Schwalbe s text.

107

108 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution. Mantel Jr, S et al. 2005, Project management in practice, 2nd edn, John Wiley & Sons.

109 Module 8 PROJECT COST MANAGEMENT

110

111 Module 8 Project Cost Management 8.1 Objectives On successful completion of this module, you should be able to: ➀ understand the importance of good project cost management ➁ explain basic project cost management principles, concepts, and terms ➂ describe how resource planning relates directly to project cost management ➃ explain cost estimating using definitive, budgetary, and rough order of magnitude (ROM) estimates ➄ understand the processes involved in cost budgeting and preparing a cost estimate for an information technology project ➅ understand the benefits of earned value management and project portfolio management to assist in cost control ➆ describe how software can assist in project cost management. Learning resources Text Chapter 7, Schwalbe (4th edition) Selected reading Selected reading 8.1: Chapter 6, Marchewka Module overview This module provides an introduction on the third knowledge area that comprises triple constraint-project cost management. Important topics include basic project cost management principles, concepts, and terms, resource planning, types of cost estimates, cost budgeting, earned value management, and project portfolio management.

112 8.2 ELE4402 Software Engineering Project Management Figure 8.1: Overview of project cost management (source: PMBOK Guide 2004, p. 159)

113 Module 8 Project Cost Management 8.3 Figure 8.1 provides an overview as to what processes, inputs, tools and techniques, and outputs project cost management involve, based on the PMBOK Guide In the following sections, we briefly summarise the key concepts and principles presented in this module. 8.1 Importance of project cost management Project cost can easily get out of control if no appropriate project cost management is in place. As revealed by 1995 CHAOS report (see the reference in Schwalbe s text), the average cost overrun that is the additional percentage or dollar amount by which actual cost exceed estimates for information technology was 189% of their original estimates. Project cost management includes the processes required to ensure that a project team completes a project within an approved budget. Project cost management includes four main processes as follows: ➊ Resource planning: involves determining what resources, e.g., people, equipment, and materials, a project team should use to perform project activities and quantities of each resource. ➋ Cost estimating: involves developing an approximation or estimate of the costs of the resources needed to complete a project. ➌ Cost budgeting: involves allocating the overall cost estimate to individual work items to establish a baseline for measuring performance. ➍ Cost control: involves controlling changes to the project budget. 8.2 Basic principles of cost management In order to perform effective project cost management, there are a few financial terms related to project cost management one needs to understand. Table 8.1 lists the financial terms that are of interest in this module. 8.3 Resource planning Resource planning is a crucial part of project cost management. Physical resources for software projects include people, equipment, and materials. Labor costs constitute a large percentage of total project costs, so most projects involve many human resources. It is important and effective to solicit ideas from people involved in the project on cost-related issues at an early stage of the project.

114 8.4 ELE4402 Software Engineering Project Management Table 8.1: Financial terms related to project cost management Financial Terms Cost Profits Profit margin Life cycle costing Cash flow analysis Internal rate of return (IRR) Tangible costs or benefits Intangible costs or benefits Direct costs Indirect costs Sunk cost Reserve Contingency reserves Management reserves What It Is A resource sacrificed or foregone to achieve a specific objective Revenues minus expenses The ratio between revenues and profits Considers the total cost of ownership, or development plus support costs for a project. Thus it enables a big-picture view of the cost of a project throughout its life cycle A method for determining the estimated annual costs and benefits for a project and the resulting annual cash flow. It can be used to determine net present value The discount rate that makes net present value equal to zero. It is also called the time-adjusted rate of return Those costs or benefits that an organisation can easily measure in dollars Those costs or benefits that are difficult to measure in monetary terms Costs related to a project that an organisation can trace back in a cost-effective way Costs related to a project that an organisation cannot trace back in a cost-effective way Money that has been spent in the past. Sunk costs should not be considered in deciding what projects to invest Dollars included in a cost estimate to mitigate cost risk by allowing for future situations that are difficult to predict. Allow for future situations that may be partially planned for (also called know unknowns) Allow for future situations that are unpredictable (also called unknown unknowns)

115 Module 8 Project Cost Management 8.5 The major inputs to resource planning include a project s work breakdown structure, scope statement, historical information, resource information, and policies. The main output of the resource planning processing is a list of resource requirements, including people, equipment, and materials. 8.4 Cost estimating Accurate cost estimating is very important as it provides the basis for cost budgeting and cost control Types of cost estimates The main outputs of project cost management are a cost estimate, supporting details and a cost management plan. There are three types of cost estimates, namely, rough order of magnitude (ROM) estimate, budgetary estimate, and definitive estimate. Table 8.2 summarises the three types of cost estimates (Table 7-3 of the text): Table 8.2: Types of cost estimates Type of Estimate When Done Why Done How Accurate Rough Order of Magnitude (ROM) Very earlier in the project life cycle, often 3 5 years before project completion Provides estimate of cost for selection decisions Budgetary Early, 1 2 years out Puts dollars in the budget plan Definitive Later in the project, less than 1 year out Provides details for purchases, estimates actual costs 25%, +75% 10%, +25% 5%, +10% The supporting details include the ground rules and assumptions used in creating the cost estimate, a description of the project used as a basis for the estimate, and details on the cost estimation tools and techniques used to create the estimate. A cost management plan is a document that describes how the organisation will manage cost variance on the project.

116 8.6 ELE4402 Software Engineering Project Management Cost estimation tools, techniques and typical problems There are three basic cost estimating techniques, i.e., analogous estimates, bottom-up estimating, and parametric modeling. Table 8.3 lists the three techniques and their respective advantages and disadvantages. Table 8.3: Three techniques for cost estimation Technique Description Advantages Disadvantages Analogous estimates Bottom-up estimating Parametric modeling Also called top-down estimates, use the actual cost of a previous, similar project as the basis for estimating the cost of the current project. Involves estimating individual work items and summing them to get a project total. Uses project characteristics (parameters) in a mathematical model to estimate project costs. Less costly Less accurate. Depends on how close the current project resembles the previous similar projects. Reasonably reliable Most reliable Time-intensive and therefore expensive to develop More complicated For estimating software development costs, Constructive Cost Model (COCOMO), developed by Barry Boehm, is one popular parametric model that is based on parameters such as the source lines of code or function points. Function points are technologyindependent assessments of the functions involved in developing a system, e.g., the number of inputs and outputs, the number of files maintained, and the number of up-

117 Module 8 Project Cost Management 8.7 dates. COCOMO II is a newer version of COCOMO. Activity 8.1 Software Engineering Metrics & Approaches Estimate the Time and Effort of Software Application Systems Estimating the time and effort of the software application system is the greatest challenge for estimating a software development project. Read through the section Software Engineering Metrics and Approaches in chapter 6 of Marchewka s text. Try to complete the following activities: ➊ For the three different types of software estimation metrics, namely, Lines of Code (LOC), Function Points and COCOMO, what are their respective definitions and inherent meanings? ➋ Draw a three-column table on a piece of paper. List three techniques on the left-most column, advantages on the middle column, and disadvantages on the right column. Try to complete the contents for each column. The cost estimates for software projects, due to their complexity, are especially difficult to predict. Four typical reasons, as suggested by Tom DeMarco who is a well-known author on software development, account for the inaccuracy in estimating software project: ➊ Developing an estimate for a large software project is a complex task requiring a significant amount of effort. ➋ The people who develop software cost estimates often do not have much experience with cost estimation, especially for large projects. ➌ Human beings are biased toward underestimation. ➍ Management desires a more accurate number to help them to create a bid to win a major contract or get internal funding. The cost estimate overview and cost flow analysis are two important documents. The overview highlights information important to top management. It includes four main components, i.e., objective, scope, assumptions, and cost/benefit analysis and internal

118 8.8 ELE4402 Software Engineering Project Management rate of return (IRR). The cash flow analysis provides the basis for determining the IRR for the life of the project. Activity 8.2 Case Study Cost Estimates One of the best ways to learn cost estimates is through a case study. Read through the Business Systems Replacement (BSR) project cost estimate in Chapter 7 and JWD Consulting s project cost estimate in Chapter 3 of Schwalbe s text. Also read through the ResNet project cost estimate at the textbook s companion website < Answer the following question: What are the main categories that need to be included in the cost estimate overview document? 8.5 Cost budgeting The main goal of the cost budgeting process is to prepare budgetary estimates and to produce a cost baseline for measuring project performance. Project cost budgeting involves allocating the project cost estimate to individual work items based on the work breakdown structure (WBS) of the project. It is typical for IT projects to have compensation costs as the largest part of cost estimates, because human resources are major costs for software projects. Human resources are usually measured by the number of full-time equivalent (FTE) staff (also referred to as headcount). A cost baseline, as the other important output of cost budgeting, is a time-phased budget that project managers use to measure and monitor cost performance. The cost baseline provides the foundation to project managers and top management - a foundation for project cost control. 8.6 Cost control The main components, inputs and outputs of the project cost control are summarised as follows:

119 Module 8 Project Cost Management 8.9 Includes: Monitoring cost performance, ensuring that only appropriate project changes are included in a revised cost baseline, and informing projects stakeholders of authorised changes to the project that will affect costs. Inputs: Cost baseline, performance reports, and cost management plan. Outputs: Revised cost estimates, budget updates, corrective action, revised estimates for project completion and lessons learned. The cost change control is part of the integrated change control system of the Project Integration Management described in Module 5. Performance measurement is another important tool for cost control. Earned value management (EVM) is the main cost control method used for measuring project performance Earned value management Earned value management (EVM) is a project performance measurement technique that integrates scope, time, and cost data. By comparing the actual project information to its baseline, project managers and their teams can determine how well the project is meeting scope, time and cost goals. A baseline is the original project plan plus approved changes. Actual project information includes whether or not a WBS item was completed or approximately how much of the work was completed, when the work actually started and ended, and how much it actually costs to do the completed work. Refer to Figure 7-1 in the textbook for an example cost control input form. There are some quantities related to the EVM calculation: ➊ Planned value (PV): formally called the budgeted cost of work scheduled (BCWS), also called the budget, is that portion of the approved total cost estimate planned to be spent on an activity during a given period. ➋ Actual cost (AC): formally called the actual cost of work performed (ACWP), is the total direct and indirect costs incurred in accomplishing work on an activity during a given period. ➌ Earned value (EV): formally called the budgeted cost of work performed (BCWP), is an estimate of the value of the physical work actually completed. The formula to calculate the earned value is: where a% is the percentage of work completed. EV = P V a%, (8.1) ➍ Cost variance (CV): reflects the difference between the estimated cost of an activity and the actual cost of that activity. The formula to calculate the cost variance is: CV = EV AC. (8.2)

120 8.10 ELE4402 Software Engineering Project Management ➎ Schedule variance (SV): reflects the difference between the scheduled completion of an activity and the actual completion of that activity. The formula to calculate the schedule variance is: SV = EV P V. (8.3) ➏ Cost performance index (CPI): is the ratio of earned value to actual cost and can be used to estimate the projected cost of completing the project. The formula to calculate the cost performance index is: CP I = EV AC. (8.4) ➐ Schedule performance index (SPI): is the ratio of earned value to planned value and can be used to estimate the projected time of completing the project. The formula to calculate the schedule performance index is: SP I = EV P V. (8.5) ➑ Budget at completion (BAC): is the original total budget for the project. ➒ Estimate at completion (EAC): is an estimate of what it will cost to complete the project based on performance to date. The formula to calculate the estimate at completion is: EAC = BAC CP I. (8.6) ➓ Estimated time to complete (ETC): is an estimate of how long it will take to complete the project based on performance to date. The formula to calculate the estimated time to complete is: ET C = OT E SP I, (8.7) where OT E is the original time estimate (OTE). The two quantities EAC and ETC predict how the project is meeting its planned budget and schedule. Earned value information can be easily graphed by an earned value chart, which helps project managers and top management visualise how the project is performing. Figure 8.2 illustrate an example of an earned value chart. Note that there are two important points in the chart, i.e., budget at completion (BAC) and estimate at completion (EAC).

121 Module 8 Project Cost Management 8.11 Figure 8.2: Earned Value Chart (Schwalbe, 2006, Fig. 7-5) Activity 8.3 Earned Value Chart Earned value charts can help project managers visualise how the project is performing. Experienced project managers can tell important project performance information from the earned value chart. Top management especially like to see performance information presented in a graphical form such as the earned value chart. Read the earned value chart in Figure 8.2. Answer the following questions: What project performance information can you tell from the earned value chart shown in the figure? What is the overall project performance? Although earned value management is a powerful tool for project cost control, many organisations do not use earned value management on many projects. Two reasons account for this fact: ➊ particulary for IT projects, tracking performance against a plan might produce misleading information ➋ estimating percentage completion of tasks might produce misleading information.

122 8.12 ELE4402 Software Engineering Project Management Project portfolio management Project portfolio management is an approach to evaluate the performance of multiple projects. A project portfolio includes an entire suite of projects or investments as one set of interrelated activities. Project portfolio management has five levels from simplest to most complex: ➊ put all your projects in one database ➋ prioritise the projects in your database ➌ divide your projects ➍ automate the repository ➎ apply modern portfolio theory, including risk-return tools that map project risk on a curve. 8.7 Using software to assist in project cost management Many people use spreadsheet software to perform resource planning, cost estimating, cost budgeting, and cost control. Many organisations also use more sophisticated and centralised financial applications software to provide important cost-related information to accounting and finance personnel. Project management software can be used to assign costs to resources and tasks, prepare cost estimates, develop cost budgets, and monitor cost performance. Microsoft Project provides several standard cost reports, i.e., cash flow, budget, over budget tasks, over budget resources, and earned value reports. There is also some enterprise project management software to help project cost management. These software packages include Microsoft Solution for Enterprise Project Management, Pacific Edge s The Edge and The Edge for IT, and PlanView s Web software.

123 Module 8 Project Cost Management 8.13 Reading Read Schwalbe s text Chapter 7. Read Marchewka s text Chapter 6, Review questions Complete Review Questions 1 7 in Chapter 7, Schwalbe s text to fulfil the objectives of module 8. Exercises Complete Exercises 1 3, 6 in Chapter 7, Schwalbe s text. Minicase Complete the Minicase in Chapter 7, Schwalbe s text.

124 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution. Marchewka, J 2003, Information technology software project management, 3rd edn, John Wiley & Sons.

125 Module 9 PROJECT QUALITY MANAGEMENT

126

127 Module 9 Project Quality Management 9.1 Objectives On successful completion of this module, you should be able to: ➀ understand the importance of project quality management for information technology products and services ➁ define project quality management and understand how quality relates to various aspects of information technology projects ➂ describe quality planning and its relationship to project scope management ➃ discuss the importance of quality assurance ➄ list the three outputs of the quality control process ➅ understand the tools and techniques for quality control, such as Pareto analysis, statistical sampling, Six Sigma, quality control charts, and testing ➆ describe important concepts related to Six Sigma and how it helps organizations improve quality and reduce costs ➇ summarize the contributions of noteworthy quality experts to modern quality management ➈ understand how the Malcolm Baldrige Award and ISO 9000 standard promote quality in project management ➉ describe how leadership, cost, organizational influences, and maturity models relate to improving quality in information technology projects. Learning resources Text Chapter 8, Schwalbe (4th edition) Selected reading Selected reading 9.1: Section 1.2, Jalote

128 9.2 ELE4402 Software Engineering Project Management Module overview This module highlights the importance of quality on information technology projects, defines quality and quality management, and explains the processes of quality planning, quality assurance, and quality control. It provides several examples of various tools and techniques such as Pareto diagrams, quality control charts, and using Six Sigma to improve quality. In the following sections, we briefly summary the key concepts and principals related to project quality management. Figure 9.1 provides an overview as to what processes, inputs, tools and techniques, and outputs project quality management involve, based on the PMBOK Guide In the following sections, we briefly summary the key concepts and principals presented in this module.

129 Module 9 Project Quality Management 9.3 Figure 9.1: Overview of project quality management (source: PMBOK Guide 2004, p. 182)

130 9.4 ELE4402 Software Engineering Project Management 9.1 What is project quality management Quality is defined by the International Organisation for Standardisation (ISO) as the totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs. Another well known definition of quality is based on conformance to requirements and fitness for use. Conformance to requirements means the project s process and products meet written specifications. Fitness to use means a product can be used as it was intended. The purpose of project quality management is to ensure that the project will satisfy the needs for which it was undertaken. Note that the customer ultimately decides if quality is acceptable. Project quality management includes the following three main process: ➊ Quality planning: includes identifying which quality standards are relevant to the project and how to satisfy those standards. ➋ Quality assurance: involves periodically evaluating overall project performance to ensure the project will satisfy the relevant quality standards. ➌ Quality control: involves monitoring specific project results to ensure that they comply with the relevant quality standards while identifying ways to improve overall quality. 9.2 Quality planning The first step to ensure project quality management is planning. The essence of modern quality management is the prevention of defects through a program of selecting the proper materials, training and indoctrinating people in quality, and planning a process that ensures the appropriate outcome. Project quality planning aims at identifying relevant quality standards for each unique project and to design quality into the products of the project and the processes involved in managing the project. The main outputs of quality planning are a quality management plan and checklists for ensuring quality throughout the project life cycle. Design of experiments is a quality planning technique that helps identify which variables have the most influence on the overall outcome of a process. It is an important part of quality planning to understand which variables affect outcome. Some important project scope aspects related to quality planning specifically for software projects are as follows:

131 Module 9 Project Quality Management 9.5 ➊ Functionality and Features: Functionality is the degree to which a system performs its intended function. Features are the system s special characteristics that appeal to users. It is important to distinguish mandatory and optional functionality and features. ➋ System outputs: are the screens and reports the system generates. ➌ Performance: addresses how well a product or service performs the customer s intended use. ➍ Reliability and Maintainability: reliability is the ability of a product or service to perform as expected under normal conditions without unacceptable failures. Maintainability addresses the ease of performing maintenance on a product. Besides the important scope aspects mentioned, project managers and their teams need to consider all of the project scope issues in determining quality goals for the project. Project managers are ultimately responsible for the quality management on their projects. 9.3 Quality assurance It is one thing to develop a quality plan for a project; it is another thing to ensure the delivery of quality products and services. Quality assurance includes all of the activities related to satisfying the relevant quality standards for a project, and aims at continual quality improvement. There are some tools and techniques that can facilitate quality assurance: ➊ Benchmarking: generates ideas for quality improvements by comparing specific project practices or product characteristics to those of other projects or products within or outside the performing organisation. ➋ Quality assurance plan template: some organisations use templates for developing various quality assurance plans. Refer to Table 8-1 in the text for such an example. ➌ Quality audit: is a structured review of specific quality management activities that help identify lessons learned that could improve performance on current or future projects.

132 9.6 ELE4402 Software Engineering Project Management Activity 9.1 Quality Assurance Plan A quality assurance plan is an important document in project quality assurance. Creating a quality assurance plan is an essential task in this module. The website of the U.S. Department of Energy (DoE) provides some quality assurance plan templates at <http: //cio.doe.gov/itreform/sqse/publications.htm#templates>. It provides two quality assurance plan templates. One is a all-purpose quality assurance plan template, whereas the other one is particularly suited for the Desktop, Telecommunications, and LAN Environments. Read through the above two templates at the given URL. Try and answer the following questions: What are the outlines of the all-purpose quality assurance plan? What are the outlines of the quality assurance plan specifically suited for IT projects? Draw a table to compare the similarities and differences of the two templates. 9.4 Quality control It is important to distinguish quality control from quality planning and quality assurance. We summarise the main outputs of quality control process as follows: ➊ Acceptance decisions: determine if the products or service produced as part of the project will be accepted or rejected. ➋ Rework: is the action taken to bring rejected items into compliance with product requirements or specifications or other stakeholder expectations. ➌ Process adjustments: correct or prevent future quality problems based on quality control measurement.

133 Module 9 Project Quality Management Tools and techniques for quality control Quality control includes many general tools and techniques. We will discuss some of the important ones, i.e., Pareto analysis, statistical sampling, Six Sigma, and quality control charts, and how these techniques can be applied to software projects Pareto analysis Pareto analysis is used to identify the vital few contributors that account for most quality problems in a system. It is also referred to as the rule, meaning that 80% of problems are often due to 20% of the causes. Pareto diagrams are histograms, or column charts representing a frequency distribution that help identify and prioritize problem areas. The variables described by the histogram are ordered by frequency of occurrence. Therefore, Pareto diagrams help visualise which factors contribute most to quality problems Statistical sampling Statistics play an important role in project quality management. Important concepts in statistics that are useful in quality management include statistical sampling, certainty factor, standard deviation, and variability. Statistical sampling involves choosing part of a population of interest for inspection. The sample size is an important factor in determining how representative the sample is. A simple formula for determining sample size is: ( ) F 2 S = 0.25, (9.1) E where S is the sample size, F is the certainty factor, and E is the acceptable error. The certainty factor denotes how certain one wants to be that the data sampled will not include variations that do not naturally exist in the population. There is a one-to-one mapping between the certainty factor and desired certainty, e.g., 95% desired certainty corresponds to the certainty factor of The students should refer to Table 8-2 in the textbook for some commonly used certainty factors. Note that the acceptable error equals 100% minus the desired certainty.

134 9.8 ELE4402 Software Engineering Project Management Six sigma Six Sigma is defined as a comprehensive and flexible system for achieving, sustaining and maximizing business success by Pande et al. in their book The six sigma way. Software projects that use Six Sigma principles for quality control normally follow a five-phase improvement process called DMAIC, which stands for Define, Measure, Analysse, Improve, and Control: ➊ Define: Define the problem/opportunity, process, and customer requirements. ➋ Measure: Define measures, collect, compile, and display data. ➌ Analyse: Scrutinize process details to find improvement opportunities. ➍ Improve: Generate solutions and ideas for improving the problem. ➎ Control: Track and verify the stability of the improvements and the predictability of the solution. Six Sigma principles differ from previous quality control initiatives such as total quality management (TQM) and business process reengineering (BPR) in having several new ideas: ➊ using Six Sigma principles is an organisation-wide commitment ➋ organisations that successfully implement Six Sigma principles have the ability and willingness to adopt two seemingly contrary objective at the same time ➌ Six Sigma is not just a program or a discipline to organisations, but an operating philosophy that is customer-focused and strives to drive out waste, raise levels of quality, and improve financial performance at breakthrough levels. Organisations that adopt Six Sigma principles set high goals and use the DMAIC improvement process to achieve extraordinary quality improvements. Project selection is especially important for Six Sigma projects. Not all organisations can benefit from Six Sigma because minimising is not meaningful if an organisation is making a product that has no market. Three criteria exist for potential Six Sigma projects: ➊ There must be a quality problem or gap between the current and desired performance. ➋ Six Sigma projects are also best suited for projects that do not have a clearly understood problem. ➌ The solution is not predetermined, and an optimal solution is not apparent.

135 Module 9 Project Quality Management 9.9 Six Sigma projects can be understood as simple types of projects that focus on supporting the Six Sigma philosophy by being customer-focused and striving to drive out waste, raise levels of quality, and improve financial performance at breakthrough levels. The term Sigma means standard deviation, which measures how much variation exists in a distribution of data, and is represented by the Greek symbol σ. Standard deviation is a key factor in determining the acceptable number of defective units found in a population. In pure statistical terms, being ±6σ means % of population within range, or only two defective units per billion. However, there is a 1.5σ shift due to disagreement among statistical experts regarding how Six Sigma measures are defined. The result is that the target for Six Sigma programs is 3.4 defects per million opportunities, or % of population within range. Six 9s of quality is another term used in the telecommunications industry. It is a measure of quality control equal to 1 fault in 1 million opportunities. It means % service availability or 30 seconds of downtime a year Quality control charts and the seven run rule Quality control charts are graphical display of data that illustrates the results of a process over time. Such a chart allows project managers to determine whether a process is in control or out of control. For a process in control, any variations in the results of the process are caused by random events. On the other hand, for a process out of control, variations are caused by nonrandom events. The causes resulting nonrandom events need to be identified and eliminated through adjusting the process. The seven run rule states that if seven data points in a row are all below the mean, above the mean, or are all increasing or decreasing, then the process needs to be examined for nonrandom events. The rule can be utilised to identify abnormal data patterns in quality control charts Testing Software projects use testing extensively to ensure quality. In a software system development life cycle, testing needs to be done during almost every phase of the cycle. Unit testing is to test each individual component (often a program) to ensure it is as defect-free as possible. Integration testing is to test functionally grouped components. It ensures a subset(s) of the entire system works together. System testing tests the entire system as one entity. User acceptance testing is an independent test performed by end-users prior to accepting the delivered system. Figure 9.2 depicts the testing tasks in the software systems development life cycle.

136 9.10 ELE4402 Software Engineering Project Management Figure 9.2: Testing Tasks in the Software Systems Development Life Cycle (source: Schwalbe 2006, Figure 8-4)

137 Module 9 Project Quality Management Modern quality management Modern quality management requires customer satisfaction, prefers prevention to inspection, and recognises management responsibility for quality. Several elite people have made significant contribution to the development of modern quality management such as Deming, Juran, Crosby, Ishikawa, Taguchi, and Feigenbaum. Deming is best known for his Cycle for Improvement (plan, do, check, and act), and Deming s Fourteen Points for Management that is stated on page 284 of the text. Juran, who first stressed the importance of top management commitment to continuous product quality improvement, developed the so-called Juran Trilogy: quality improvement, quality planning, and quality control. Juran also developed his ten steps to quality improvement, which is stated on page 285 of the text. Crosby is best known for suggesting that organisations strive for zero defects. fourteen steps to quality improvement is stated on page 285 of the text. His Ishikawa first proposed the concept of quality circles and pioneered the use of Fishbone diagrams. Quality circles are groups of nonsupervisors and work leaders in a single company department who volunteer to conduct group studies on how to improve the effectiveness of work in their department. Fishbone diagrams, also called Ishikawa diagrams, trace complaints about quality problems back to the responsible production operations. They help find the root cause of quality problems. Taguchi is best known for developing the Taguchi methods for optimising the process of engineering experimentation. Key concepts are that quality should be designed into the product and not inspected into it and that quality is best achieved by minimising deviation from the target value. Feigenbaum first developed the concept of total quality control (TQC) in The core thesis of TQC is that the responsibility for quality control should rest with the people who do the work. In TQC, product quality is more important than production rates. Works are allowed to stop production whenever a quality problem occur. ISO 9000 is a well-established quality system standard developed by the ISO. It has three parts, namely, continuous cycle of planning, controlling, and documenting quality in an organisation. ISO 9000 provides minimum requirements that an organisation needs to meet its quality certification standards. The ISO 9000 family of international quality management standards has earned a global reputation as the basis for establishing quality management systems. The ISO 9000 family consists of a number of standards as follows: ➊ ISO 9001: is the core part of the ISO 9000 family. It sets out the requirements for an organisation whose business processes range all the way from design and development, to production, installation and servicing.

138 9.12 ELE4402 Software Engineering Project Management ➋ ISO 9002: is a sub-set of ISO It is the appropriate standard for organisations that do not design and develop products, since it does not include the design control requirements of ISO Its requirements are identical aside from that distinction. ➌ ISO 9003: is an even more limited sub-set of ISO It is the appropriate standard for an organisation whose business processes do not include design control, process control, purchasing or servicing. It focuses on inspection and testing to ensure that final products and services meet specified requirements. ISO 9000 standards cover all technical fields and are not limited to any particular discipline. These standards do not, however, cover electrical or electronic engineering which is the responsibility of the International Electrotechnical Commission (IEC). Joint ISO/IEC standards relevant to software quality are as follows: ➊ ISO/IEC TR : Software engineering Product quality Part 1: Quality model ➋ ISO/IEC TR : Software engineering Product quality Part 2: External metrics ➌ ISO/IEC TR : Software engineering Product quality Part 3: Internal metrics ➍ ISO/IEC TR : Software engineering Product quality Part 4: Quality in use metrics ➎ ISO/IEC 12119: Information technology Software packages Quality requirements and testing It is important for organisations to identify the appropriate standard before pursuing

139 Module 9 Project Quality Management 9.13 ISO 9000 certification. Activity 9.2 ISO 9000 Family of Quality Management Standards - A Case Study Close to Us ISO 9000 family of quality management standards are the most famous and widely used international standards in quality management. Its global success has been testified by countless organisations throughout the world. For example, the Project Management Institute was proud to announce in 1999 that their certification department had become the first certification department in the world to earn ISO 9000 certification, and that the PMBOK Guide 1996 had been recognised as a U.S. national standard. Maybe the closest case of quality management to students who take this subject is the Quality Management System of the Faculty of Engineering & Surveying (FoES) at the University of Southern Queensland (USQ). It is based on the ISO 9001 international standard. There are a variety of Flowcharts, Forms, and Protocols related to the quality management practices at FoES, which are located at < (need USQConnect login). Read through the Quality Management System Manual at the given web URL. Try to answer the following question: Thinking of applying theory to practice, what are your comments on how the ISO 9000 family of international standards can help regulate the quality management activities in a organisation such as FoES at USQ? 9.7 Improving information technology project quality In addition to the issues discussed above for quality management that are common to all kinds of project, there is much more room to improve the quality of software and IT projects. Techniques such as strong leadership, understanding the cost of quality, providing a good workspace, and developing and following maturity models can all assist in improving quality for IT projects.

140 9.14 ELE4402 Software Engineering Project Management Leadership Many quality experts including Juran argue that the main cause of quality problems is a lack of leadership. As a result, top management must take responsibility for creating, supporting, and promoting quality programs. Strong leadership helps emphasising the importance of quality, and provides an environment conducive to producing quality The cost of quality The cost of quality consists of the cost of conformance plus the cost of nonconformance. The cost of conformance includes all the costs related to delivering products that meet requirements and fitness for use such as developing a quality plan, costs for testing, etc. The cost of nonconformance means taking responsibility for failures or not meeting quality expectations.

141 Module 9 Project Quality Management 9.15 Activity 9.3 U.S. Electronic Voting and the Cost of Software Quality For the first time in history, more than 25% of U.S. ballots were cast electronically in November After 25 years in the making, electronic voting is finally being widely adopted in the U.S. Whilst the American people are ready for electronic voting, the technology is not ready for them. The electronic voting systems deployed are potentially perilous. One of the main reasons is that some equipment makers and election officials are rushing to deploy systems that have known flaws or that have been poorly tested or not tested at all. These electronic voting systems knowingly give up the ability to perform an independent recount. Consequently, these systems will fail if an election is contested. The costs of the flaws in the software are formidable. The above story is revealed in an article titled The Perils of Polling, which is published in the October issue of IEEE Spectrum in This article is available at IEEE Xplore Online Database via USQ Library. Research through this article, and write down some dot points to discuss how poor software quality could cost your company and customers.

142 9.16 ELE4402 Software Engineering Project Management Table 9.1 summarises the five major cost categories related to quality. Table 9.1: Five categories related to quality Category Description Activities Prevention cost Appraisal cost Internal failure cost External failure cost Measurement and test equipment costs The cost of planning and executing a project so that it is error-free or within an acceptable error range. The cost of evaluating processes and their outputs to ensure that a project is error-free or within an acceptable error range. A cost incurred to correct an identified defect before the customer receives the product. A cost that relates to all errors not detected and not corrected before delivery to the customer. The capital cost of equipment used to perform prevention and appraisal activities. Training, detailed studies related to quality, and quality surveys of suppliers and subcontractors Inspection and testing of products, maintenance of inspection and test equipment, and processing and reporting inspection data Scrap and rework, charges related to late payment of bills, inventory costs that are a direct result of defects, costs of engineering changes related to correcting a design error, premature failure of products, and correcting documentation Warranty cost, field service personnel training cost, product liability suits, complaint handling, and future business losses Organisational influences, workspace factors, and quality A study conducted by DeMarco and Lister revealed that organisational issues had a much greater influence on productivity than the technical environment or programming languages. Their study showed that providing a dedicated workspace and a quiet work environment were key factors in improving productivity. Furthermore, Peopleware, a well-known book in project management authored by DeMarco and Lister, demonstrates that major problems with work performance and project failures are not technological but sociological in nature.

143 Module 9 Project Quality Management Maturity models Maturity models are frameworks for helping organisations improve their processes and systems. There are three popular maturity models, i.e., Software Quality Function Development (SQFD) model, the Capability Maturity Model (CMM), and the Project Management Maturity model. The Software Quality Function Development (SQFD) model is an adaptation of the quality development model suggested in 1986 as an implementation vehicle for total quality management. It focuses on the user requirements and planning software projects. The output of SQFD is a set of measurable technical product specifications and their priorities. The Capability Maturity Model (CMM), developed by the Software Engineering Institute (SEI) at Carnegie Mellon University, is a five-level generic path to process improvement for software development in organisations. The five levels of the CMM consist of Initial, Repeatable, Defined, Managed, and Optimizing. The Organisational Project Management Maturity Model (OPM3) was initiated by the PMI Standards Development Program, is still under development < It aims at assisting organisations in implementing organisational strategy through the successful, consistent, and predictable delivery of projects. The OPM3 will include a method for assessing organisations project management levels as well as a step-bystep method for increasing and maintaining an organisation s ability to deliver projects as promised.

144 9.18 ELE4402 Software Engineering Project Management Activity 9.4 CMM and CMMI The Capability Maturity Model (CMM ) and Capability Maturity Model Integrated (CMMI ), developed by the Software Engineering Institute (SEI) at Carnegie Mellon University, are the most prominent examples of a model-based approach to process improvement. The CMM is limited to management and software engineering practices, where the CMMI expands the CMM to address systems engineering and integrated product development as well. The CMM is organised around Key Practice Areas (KPAs), which specify the areas on which the organisation should focus to elevate its processes to that maturity level. Each KPA is associated with one or more goals and a list of key practices. Similarly, the CMMI is organised around a set of Process Areas (PAs). The KPAs are divided into groups associated with what are called maturity levels. In the CMM, most basic management practices are considered part of maturity level 2. Most software engineering practices are associated with maturity level 3. Maturity level 4 is about process and product quality management, whereas maturity level 5 includes processes for process optimisation and technology change management. The higher an organisation moves up the maturity ladder, they are more likely to produce higher quality products with more predictable costs and cycle times. Read through Section 1.2 Project Management and the CMM in Jalote s text. Try to accomplish the following activity: Summarise the KPAs at each maturity level in the CMM. Draw a table to list these KPAs according to each individual maturity level. 9.8 Using software to assist in project quality management Some diagraming techniques related to project risk management are introduced in this module, such as Pareto diagrams, Quality Control Charts, Fishbone diagrams. These diagrams can be created using spreadsheet and charting software. Moreover, one can use statistical software packages to help determine standard deviations and

145 Module 9 Project Quality Management 9.19 perform many types of statistical analyses. There are also several specialised software products to assist people with managing Six Sigma projects or creating quality control charts.

146 9.20 ELE4402 Software Engineering Project Management Reading Read Schwalbe s text Chapter 8. Read Jalote s text Section 1.2. Review questions Complete Review Questions 1 9 in Chapter 8, Schwalbe s text to fulfil the objectives of Module 9. Exercises Complete Exercises 2 3 in Chapter 8, Schwalbe s text. Minicase Complete the Minicase in Chapter 8, Schwalbe s text.

147

148 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution. Jalote, P 2002, Software project management in pratice, 3rd edn, Addison-Wesley.

149 Module 10 PROJECT HUMAN RESOURCE MANAGEMENT

150

151 Module 10 Project Human Resource Management 10.1 Objectives On successful completion of this module, you should be able to: ➀ explain the importance of good human resource management on projects, especially on information technology projects ➁ define project human resource management and understand its processes ➂ summarize key concepts for managing people by understanding the theories of Abraham Maslow, Frederick Herzberg, David McClelland, and Douglas McGregor on motivation, H. J. Thamhain and D. L. Wilemon on influencing workers, and Stephen Covey on how people and teams can become more effective ➃ discuss organizational planning and be able to create a project organizational chart, responsibility assignment matrix, and resource histogram ➄ understand important issues involved in project staff acquisition and explain the concepts of resource assignments, resource loading, and resource levelling ➅ assist in team development with training, team-building activities, and reward systems ➆ describe how project management software can assist in project human resource management. Learning resources Text Chapter 9, Schwalbe (4th edition) Module overview This module introduces the first facilitating knowledge area, project human resource management. There are many important topics in this chapter, and whole courses are devoted to improving human resource management. Review basic topics like motivation and emphasize what project managers and teams need to know to make effective use of human resources.

152 10.2 ELE4402 Software Engineering Project Management Figure 10.1: Overview of Project Human Resource Management (source: PMBOK Guide 2004, p. 201)

153 Module 10 Project Human Resource Management 10.3 Figure 10.1 provides an overview as to what processes, inputs, tools and techniques, and outputs project human resource management involve. In the following sections, we briefly summarise the key concepts and principles presented in this module The importance of human resource management People are the most important assets for organisations. Therefore, project human resource management is a vital component of project management. This is especially true for the software industry, where qualified people are often hard to find and keep What is project human resource management Project human resource management includes three processes required to make the most effective use of the people involved with a project: ➊ Organisational planning: involves identifying, assigning, and documenting project roles, responsibilities assignments, and reporting relationships. Role and responsibility assignment in a matrix form, and an organisational chart are the key outputs of this process. ➋ Staff acquisition: involves getting needed personnel assigned to and working on the project. ➌ Team development: involves building individual and group skills to enhance project performance Keys to managing people Some psychologists and management theorists have put significant efforts into the field of managing people at work. Psychosocial issues that affect how people work and how well they work include motivation, influence and power, and effectiveness. This section briefly reviews some of the past work that has been done to address these issues.

154 10.4 ELE4402 Software Engineering Project Management Motivation theories A basic understanding of motivational theory will help project managers understand themselves and their team members. Intrinsic motivation causes people to participate in an activity for their own enjoyment. Extrinsic motivation causes people to do something for a reward or to avoid a penalty. Maslow s Hierarchy of Needs As opposed to Freud s psychoanalytic theory that human beings actions were governed by unconscious processes dominated by primitive sexual urges, Maslow developed a hierarchy of needs. The pyramid structure of Maslow s hierarchy of needs show that the people s behaviors are motivated by a sequence of needs as follows: ➊ physiological ➋ safety ➌ social ➍ esteem ➎ self-actualisation. The first four needs, i.e., physiological, safety, social, and esteem needs, are referred to as deficiency needs, whereas the last one is considered as a growth need. Each level of the hierarchy is a prerequisite for the levels above. However, a particular need no longer serves as a potent motivator of behavior once it is satisfied. The issues in each level are of greater value than the ones in the preceding level. Issues higher in the hierarchy are more important but less urgent than issues lower in the hierarchy. To motivate project team members, project managers need to understand each person s motivation, especially in relation to social, esteem, and self-actualisation or growth needs. Herzberg s motivation-hygiene theory Herzberg distinguished between motivational factors and hygiene factors. Motivational factors are factors that cause job satisfaction, whereas hygiene factors are factors that cause dissatisfaction. The term hygiene means that these factors are necessary to avoid dissatisfaction, but do not provide satisfaction by themselves. It was Herzberg s discovery that hygiene factors such as large salaries, more supervision, or a more attractive work environment would cause dissatisfaction if not present, but would not motivate work if present. Achievement, recognition, the work itself, responsibility, advancement and growth are the real factors that motivate people.

155 Module 10 Project Human Resource Management 10.5 McClelland s acquired-needs theory McClelland first proposed the acquired-needs theory, suggesting that an individual s specific needs are acquired over time and shaped by life experience. There are three main categories of acquired needs as follows: ➊ Achievement: Project managers should try to give high achievers challenging tasks with achievable goals. ➋ Affiliation: Some people desire harmonious relationships with other people and need to feel accepted by others. Project managers should try to create a cooperative work environment to meet the needs of those people. ➌ Power: Project managers should try to provide power seekers with the opportunity to manage others, emphasising the importance of meeting organisational goals. McGregor developed Theory X and Theory Y out of his research. Theory X assumes that workers dislike and avoid work if possible, so managers must use coercion, threats, and various control schemes to get workers to make adequate efforts to meet objectives. On the other hand, Theory Y is based on the assumption that individuals do not inherently dislike work, but consider it as natural as play or rest. It indicates that the most significant rewards are the satisfaction of esteem and self-actualisation needs that work can provide. Research results demonstrate clearly that the assumptions of Theory X are not valid, and support the use of Theory Y. Theory Z was introduced by Ouchi that was based on the Japanese approach to motivate workers. It emphasizes trust, quality, collective decision-making, and culture values. Theory Z assumes that workers can be trusted to do their jobs to their utmost ability, provided that management can be trusted to support them and look out for their well-being Influence and power Thamhain and Wilemon identified nine influence bases available to project managers as follows: ➊ Authority: the legitimate hierarchical right to issue orders ➋ Assignment: the project manager s perceived ability to influence a worker s later work assignments ➌ Budget: the project manager s perceived ability to authorise others use of discretionary funds ➍ Promotion: the ability to improve a worker s position

156 10.6 ELE4402 Software Engineering Project Management ➎ Money: the ability to increase a worker s pay and benefits ➏ Penalty: the project manager s perceived ability to dispense or cause punishment ➐ Work challenge: the ability to assign work that capitalises on a worker s enjoyment of doing a particular task, which taps an intrinsic motivational factor ➑ Expertise: the project manager s perceived special knowledge that others deem important ➒ Friendship: the ability to establish friendly personal relationships between the project manager and others Except the authority base that is granted to project mangers by top management as part of their position, other influence bases may or may not be inherent in a project manager s position. Project managers who rely too heavily on authority, money, or penalty tend to fail in their projects. On the contrary, project mangers who use work challenge, expertise and even friendship to influence team members are more likely to succeed in their projects. Power is the potential ability to influence behavior to get people things they would not otherwise do. French and Raven summarised five main types of power as in table New project managers often tend to overemphasise their legitimate power or authority influence. They also often neglect the importance of reward power or work challenge influence. As a result, it is very important for project managers to understand the basic concepts of influence and power, and to practice using them to the whole project s advantages Improving effectiveness The well-known book The 7 habits of highly effective people by (Covey 1980) lists seven habits which project managers can apply to help themselves and project team become more effective: ➊ Be proactive: Project managers must be proactive and plan for problems and inevitable changes on projects, and also encourage their team members to do so. ➋ Begin with the end in mind: Having a mission statement helps project managers focus on their main purpose. ➌ Put first things first: Project managers should prioritise their time, but avoid focusing only on important yet urgent activities. They need to spend a lot of time on important and not urgent activities, such as developing the project plan, building relationships with major project stakeholders, and monitoring project team members.

157 Module 10 Project Human Resource Management 10.7 Table 10.1: Five main types of powers for influence Type Description Advantages Disadvantages Coercive Power Legitimate Power Expert Power Reward Power Referent Power Involves using punishment, threats, or other negative approaches to get people to do things they do not want to do. Involves using personal knowledge and expertise to get people to change their behavior. Involves using incentives to induce people to do things. Based on an individual s personal charisma. Very effective in stopping negative behavior Getting people to do things based on a position of authority. Project managers can make key decisions without involving the project team Very effective Some types of rewards such as work challenge, achievement, and recognition truly induce people to work hard Very effective Influencing using penalties is correlated with unsuccessful projects. Overemphasis of legitimate power or authority correlates with project failure. Not every project manager has the needed technical expertise Only certain types of rewards are effective. Very few people posses the natural charisma that underlies referent power ➍ Think win/win: Project managers should strive to use a win/win approach in making decisions. ➎ Seek first to understand, then to be understood: The practice of empathic listening, which is listening with the intent to understand, is critical for project managers so that they can really understand their stakeholders needs and expectations. ➏ Synergise: Synergy is the concept that the whole is equal to more than the sum of its parts. A project team can synergise by creating collaborative products that are much better than a collection of individual efforts. ➐ Sharpen the saw: Project managers need to ensure they and their team members have time to retrain and reenergise. Ross, the author of Applying Covey s seven habits to a project management career, points out that the fifth habit (seek first to understand, then to be understood) differentiates good project managers from average to poor ones.

158 10.8 ELE4402 Software Engineering Project Management Empathic listening is a key skill that helps project mangers find out what motivates different people. Before one can practice empathic listening, he or she needs to establish rapport with other person that he or she wants to communicate with. Rapport is a relation of harmony, conformity, accord, or affinity. Mirroring, the matching of certain behaviors of the other person, is one of the techniques for establishing rapport Organisational planning Organisational planning involves identifying, documenting, and assigning project roles, responsibilities, and reporting relationships. The main outputs of the processing of organisational planning are an organisational chart for the project, responsibility assignment matrix (RAM), and a staffing management plan Project organisational charts The project manager should work with top management and project team members to create an organisational chart for the project. Such an example is given in Figure 9-2 in Schwalbe s text. It is typical for a large software project to include a deputy project manger, subproject mangers and team members in the project personnel. On smaller projects, the project managers might have just team leaders responding directly to them. As shown in Figure 9-3 in Schwalbe s text, the processing for defining and assigning work consists of the following four steps: ➊ finalising the project requirements ➋ defining how the work will be accomplished ➌ breaking down the work into manageable elements ➍ assigning work responsibilities. The above process is carried out during the proposal and startup phases of a project, and an iterative process. A Request for Proposal (RFP) or draft contract serves as the basis for defining and finalising work requirements, which are then documented in a final contract and technical baseline. If an RFP is not available, the internal project charter and scope statement would serve the purpose. In the last step of the process, an organisational breakdown structure (OBS), a specific type of organisational chart that shows which organisational units are responsible for which work items, is used to assign work to organisational units.

159 Module 10 Project Human Resource Management Responsibility assignment matrices A responsibility assignment matrix (RAM) is a matrix that maps the work of the project as described in the work breakdown structure (WBS) to the people responsible for performing the work as described in the OBS. For small projects, it is usual to assign WBS activities to individual people, whereas it is more effective to assign the work to organisational units or teams for large projects. A RAM can also be used to define general roles and responsibility as shown in the Figure 9-5 in the text. RACI charts are a similar technique that show Responsibility, Accountability, Consultation, and Informed roles for project stakeholders. A RACI chart lists tasks vertically, individuals or groups horizontally. Each cell in the RACI chart has an R, A, C, or I entry. Each task may have multiple A, C, or I entry, but only one R entry can be assigned to each task. An example of a simple RACI chart is illustrated in Figure 9-1 in Schwalbe s text Staff management plans and resource histograms A staff management plan describes when and how people will be added to and taken off the project team. It usually includes a resource histogram, which is a column chart that shows the number of resources assigned to a project over time, as depicted in Figure 9-6 in Schwalbe s text. After the project staffing needs have been determined, the next steps are to acquire the necessary staff and then develop the project team Project staff acquisition The job market for the IT industry can vary from time to time, and is full of ups and downs. Regardless of the current job market, acquiring qualified professionals is critical. The important topics relevant to project staff acquisition are resource assignment, resource loading, and resource levelling Resource assignments After developing a staff management plan, project managers need to assign particular personnel to the projects, and/or acquire additional human resources to staff the project. The main outputs of the project staff acquisition process are project staff assignments and a project team directory. Staffing plans maintain a complete and accurate inventory of employees skills in an organisation. They also describe the the number and type of people anticipated to be

160 10.10 ELE4402 Software Engineering Project Management needed based on the current and upcoming activities of the organisation. If there is a mismatch between the current employees skills and needs of the organisation, it is necessary to recruit new employees, hire subcontractors, and train existing staff. Hiring and retaining IT staff are critical for an organisation. People today have higher expectations of their jobs than just making a living. Research conducted by William C. Taylor s company revealed that people leave their jobs because of the following reasons: ➊ they feel they do not make a difference ➋ they do not get proper recognition ➌ they are not learning anything new or growing as a person ➍ they do not like their co-workers ➎ they want to earn more money. As a result, it is very important to address the staff retention issue, especially for the information technology industry Resource loading Resource loading refers to the amount of individual resources an existing schedule requires during specific time periods. Project managers can use histograms that show period-by-period variations in resource loading, to help visualise resource loading. A resource loading histogram can also show when work is overallocated to a specific resource. Overallocation means more resources than are available are assigned to perform work at a given time Resource levelling Resource levelling is a technique for resolving resource conflicts such as overallocation by delaying tasks. Network diagrams can be examined for areas of slack or float, and allow project mangers identify resource conflicts. In the case that resource conflicts are identified, project mangers can reduce or remove overallocation by either delaying noncritical tasks, which does not result in overall schedule delay, or delay the project completion date. The aim of resource levelling is to minimise period-by-period variations in resource loading by shifting tasks within their slack allowances. As reflected in resource usage histograms in Figure 9-8 of the text, resource levelling tries to arrange work activities to take up the least space in the diagram. Resources are used best when they are leveled. Resource levelling has the following benefits:

161 Module 10 Project Human Resource Management ➊ When resources are used on a more constant basis, they require less management. ➋ It enables project mangers to use a just-in-time inventory type of policy for using subcontractors or other expensive resources. ➌ It results in fewer problems for project personnel and accounting departments. ➍ It often improves morale Team development After a project manager has successfully acquired enough skilled people to work on a project, he or she needs to develop a project team. The main goal of team development is to help people to work together more effectively to improve project performance. Several team development tools and techniques such as training, team-building activities, reward and recognition systems, and general advice on the effective use of teams are discussed in this section Training Project mangers should recommend that their team members take specific training courses to improve individual and team performance. It is important to provide training in a just-in-time fashion. E-learning is often more cost-effective than traditional instructor-led training. It is also more economical to train current employees in particular areas than to hire new skilled staff. It should be noted that some organisations adopting Six Sigma principles have a unique and effective approach to training, as explained on page 335 of Schwalbe s text Team-building activities Some organisations use the approach of physical challenges such as military basic training or boot camps for team building. Even more organisations use the approach of mental team-building, such as the Myers-Briggs Type Indicator and the Wilson Learning Social Styles Profile. The Myers-Briggs Type Indicator (MBTI), based on Jung s theory of psychological types, and developed by Briggs, is a popular tool for determining personality preferences. The MBTI includes four dimensions of personal types: ➊ Extrovert/Introvert (E/I): Extroverts draw their energy from other people, whereas introverts draw energy from themselves.

162 10.12 ELE4402 Software Engineering Project Management ➋ Sensation/Intuition (S/N): Sensation type people take in facts, details, and reality and describe themselves as practical, whereas intuitive people are imaginative, ingenious, and attentive to hunches or intuition. They describe themselves as innovative and conceptual. ➌ Thinking/Feeling (T/F): Thinking judgement is objective and logical, whereas feeling judgement is subjective and personal. ➍ Judgement/Perception (J/P): Judgement type people tend to establish deadlines and take them seriously, whereas perceiving type people prefer to keep things open and flexible. Table 10.2 reveals some significant MBTI types contrasts between the general population and information systems (IS) developers in the United States. Table 10.2: MBTI types contrast B/W general population and IS developers Personality Type General Population IS Developers Extrovert/Introvert 25% are Introverts. 75% are Introverts. Sensation/Intuition 55% are Intuitive. 25% are Intuitive. Thinking/Feeling 50% are Thinking Type. 80% are Thinking Type. Judgment/Perception Slightly more than 50% preferring Judgement Type. Slightly more than 50% preferring Judgement Type. The benefit of knowing the team members MBTI profiles is that project managers can take appropriate actions to adjust their management styles for each team member.

163 Module 10 Project Human Resource Management Activity 10.1 What is Your MBTI Types The Myers-Briggs Type Indicator (MBTI) divides personal types into four dimensions, i.e., Extrovert/Introvert (E/I), Sensation/Intiition (S/N), Thinking/Feeling (T/F), and Judgement/Perception (J/P). Table 10.2 reveals that software engineers have significantly different MBTI types than those of the general population. Read through the descriptions on MBTI types both in this study book and in Schwalbe s text. For the four dimensions of personal types included in the MBTI, try to find out which type you belong to for each dimension in the MBTI. The Wilson Learning Social Styles Profile was proposed by the psychologist Merril. People are perceived as behaving primarily in one of four zones, based on their assertiveness and responsiveness: ➊ drivers are proactive and task-oriented ➋ expressive are proactive and people-oriented ➌ analyticals are reactive and task-oriented ➍ amiables are reactive and people-oriented. The main determinants of the Wilson learning social style are the individual s levels of assertiveness (if he or she is more likely to tell people what to do or ask what should be done), and how an individual responds to tasks (focus on the task itself or on the people involved in performing the task) Reward and recognition systems and general advice on teams It is a very effective strategy to promote team development via the use of team-based reward and recognition systems. Refer to page 340 of the textbook for some general advice on how to improve team productiveness.

164 10.14 ELE4402 Software Engineering Project Management 10.7 Using software to assist in human resource management Several spreadsheet programs or project management software such as Microsoft Project can be used to create responsibility assignment matrices and histograms. Project managers can use Microsoft Project to assign resources (equipment, materials, facilities, or people) to tasks. Microsoft Project enables one to allocate individual resources to individual projects or to pool resources and share them across multiple projects. The main resource assigning and tracking functions provided by Microsoft Project are: ➊ to keep track of the whereabouts of resources ➋ to identify potential resource shortages ➌ to identify underutilised resources and reassign them ➍ to automated resource levelling. Microsoft Project also provides two useful features, i.e., the resource usage view and the resource usage report. Although project management software provides powerful automated tools to manager project human resources, it is important for project mangers to keep in mind that human resources are very different from other resources. One can not simply replace people the same way that he or she replaces a piece of equipment.

165 Module 10 Project Human Resource Management Reading Read Schwalbe s text Chapter 9. Review questions Complete Review Questions 1 7 in chapter 9, Schwalbe s text to fulfil the objectives of Module 10. Exercises Complete Exercises 1, and 2 in Chapter 9, Schwalbe s text. Minicase Complete the Minicase in Chapter 9, Schwalbe s text.

166 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution.

167 Module 11 PROJECT COMMUNICATIONS MANAGEMENT

168

169 Module 11 Project Communications Management 11.1 Objectives On successful completion of this module, you should be able to: ➀ understand the importance of good communication in projects and describe the major components of a communications management plan ➁ discuss the elements of project communications planning, including information distribution, performance reporting, and administrative closure ➂ discuss various methods for project information distribution and the advantages and disadvantages of each ➃ understand individual communication needs and how to determine the number of communications channels needed for a project ➄ understand how the main outputs of performance reporting help stakeholders stay informed about project resources ➅ recognize how the main outputs of administrative closure are used to formally end a project ➆ list various methods for improving project communications, such as managing conflicts, running effective meetings, using effectively, and using templates ➇ describe how software can enhance project communications. Learning resources Text Chapter 10, Schwalbe (4th edition) Selected reading Selected reading 11.1: Chapter 2, Brooks, Jr

170 11.2 ELE4402 Software Engineering Project Management Module overview This module describes another important knowledge area, project communications management. It explains the processes involved in project communications management, methods for improving project communications, and how various types of software can enhance communications. Figure 11.1 provides an overview as to what processes, inputs, tools and techniques, and outputs project communications management involve. In the following sections, we briefly summarise the key concepts and principles presented in this module The importance of project communications management Many experts consider failure to communication as the greatest threat to project success. As revealed by the 1995 Standish Group study (see reference in Schwalbe s text), the three major factors related to software development project success, i.e., user involvement, executive management support, and a clear statement of requirement, are all dependent on having good communications skills. Many software development engineers possess strong technical skills but poor communications skills. People tend to think that it is easier to pick up the soft skills than to develop solid technical background. However, communications skills are as important as technical ones, and thus professionals must learn and develop them. The goal of project communications management is to ensure timely and appropriate generation, collection, dissemination, storage, and disposition of project information. There are four main processes in project communications management, as follows: ➊ Communications planning: involves determining the information and communications needs of project stakeholders. ➋ Information distribution: involves making needed information available to project stakeholders in a timely manner. ➌ Performance reporting: involves collecting and disseminating performance information, including status reports, progress measurement, and forecasting. ➍ Administrative closure: involves generating, gathering, and disseminating information to formalise phase or project completion.

171 Module 11 Project Communications Management 11.3 Figure 11.1: Overview of project communications management (source: PMBOK Guide 2004, p. 222)

172 11.4 ELE4402 Software Engineering Project Management 11.2 Communications planning A communications management plan is a document that guides project communications, as part of the overall project plan (see Module 5 Project Integration Management). The main parts included in a communications plans are as follows: ➊ a description of a collection and filing structure for gathering and storing various types of information ➋ a distribution structure describing what information goes to whom, when, and how ➌ a format for communicating key project information ➍ a production schedule for producing the information ➎ access methods for obtaining the information ➏ a method for updating the communications management plans as the project progresses and develops ➐ a stakeholder communications analysis. The stakeholder communications analysis is an important document that shows which stakeholder should get which written communications. The analysis should include information such as the contact person for the information, when the information is due, and the preferred format for the information. An example stakeholder communications analysis is shown in Table 10-1 in Schwalbe s text. The main advantage of creating a communications plan and reviewing it with the project stakeholders early in the project helps prevent or reduce later communications problems. Consistent communications are imperative to improve project communications efficiency, especially for programs composed of multiple projects. Quite often, many work breakdown structures (WBSs) include a section for project communications to specify reporting key project information as a project deliverable Information distribution Information distribution is about getting project information to the right people at the right time, and in a useful format. The stakeholder communications analysis can serve as a good starting point for information distribution. There are some major considerations for information considerations such as the use of technology, formal and informal communications, and the complexity of communications.

173 Module 11 Project Communications Management Using technology to enhance information distribution The effective use of technology can facilitate the distribution of information. Using an internal project management information system is a good way to organise project documents. Making project documents available in an electronic format makes it easier to share with team members of the project. The project documents in electronic format can be made available on an intranet, extranet, or even the Interent if the information is not sensitive. Storing templates and samples of project documents electronically can make accessing standard project forms easier Formal and informal methods for distributing information Technical professionals tend to like formal communications such as written communications, whereas non-technical professionals prefer informal verbal communications. Verbal communications can be equally effective ways to distribute project information. Both formal and informal communications have their pros and cons. For example, written communications are slow but trackable, whereas verbal communications are quick but not trackable. Project managers need to balance the use of formal and informal communications. Informational discussions are effective ways for project managers to develop a trusting relationship with their team members. Many experts believe that the ability to nurture relationships and use empathic listening skills distinguishes good project managers from bad ones. Communications include many different dimensions such as writing, speaking, and listening. Different people response positively to different types of communications. As a result, project managers need to be aware of this fact, and take advantage of the individual s special communication need. Verbal communication via meetings and informal talks has advantages compared to written communication. For one thing, oral communication helps bring important information, positive or negative, out into the open; for another, oral communication helps build stronger relationships among project personnel and stakeholders. A person s tone of voice and body language, and short, frequent meetings are good examples of effective oral communications. Practical Communications, Inc. (a communications consulting company) conducted research about how well different types of formal and informal communication media, such as hard copy, Phone calls, voice mail, , meetings, and Web sites, are suited to different communication needs. Table 11.1 summarises their research results:

174 11.6 ELE4402 Software Engineering Project Management Table 11.1: Media choice table How Well Medium is Suited to Hard Copy Phone Call Voice Mail Meeting Web Site Assessing commitment Building consensus Mediating a conflict Resolving a misunderstanding Addressing negative behavior Expressing support/appreciation Encouraging creative thinking Making an ironic statement Conveying a reference document Reinforcing one s authority Providing a permanent record Maintaining confidentiality Conveying simple information Asking an informational question Making a simple request Giving complex instructions Addressing many people Understanding human and individual communications needs It is a common misunderstanding that one can add more manpower (people) to a project that is falling behind schedule in order to achieve the deadline. As illustrated in the well-known The Mythical Man-month by Brooks, adding more man power to a laggard project often causes more setbacks because of the increased complexity of communications. People are not interchangeable parts. As described in Module 10 (Project Human Resources Management), people have different personality traits, which often affect their communication preference. As a result, it is important for project managers and their team members to be aware of their own communication styles and preferences and those of other project stakeholders. Geographic location, culture background, and language barriers are three factors that also affect the complexity of project communications.

175 Module 11 Project Communications Management 11.7 Activity 11.1 The Mythical Man-Month and Effective Project Communications Management The Mythical Man-Month is an all-time classic essay on software engineering by the venerable F P Brooks, Jr, who is known as the father of the IBM System/360 (see the online Computer History Museum < As revealed in the article, the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. People and time are interchangeable only when a task can be partitioned among many workers with no communications among them. Otherwise, the added effort of communications may fully counteract the division of the original task. The article is concluded with the famous Brooks s Law: Adding manpower to a late software project makes it later. When Brooks first proposed his law, procedural programming languages dominated the market. As time goes by, the object-oriented programming methodology is taking control in the area of software engineering. How would this change affect Brooks s Law? Read through this classic article in the selected reading book. Write some dot points to reflect the above change, and whether or not effective and efficient project communications management can help interchange men and months Determining the number of communication channels With the increasing of the number of people involved in a project, the number of communication channels also increase, which can be determined by the following formula N c = n(n 1), (11.1) 2 where N c denotes the number of communication channels, and n is the number of people involved. In some situations such as virtual projects, people involved in a project cannot have opportunities to meet face-to-face. They must rely on , discussion threads, project Web sites, and other technologies to communication most project information. In general, project team members must possess good written communications skills in such situations.

176 11.8 ELE4402 Software Engineering Project Management If a large-scale project is viewed as composed of a lot of moving parts, communication can be considered as the oil that keeps every part working properly. Many good project managers know their personal strengths and weaknesses in communications. It is a good practice for them to have other qualified team members to complement project managers communication skills. Activity 11.2 Number of Communications Channels The complexity of information distribution increases as the number of people involved in a project increases. This is because there are more communications channels through which people can communicate. The number of the communications channels is determined by equation (11.1). Using (11.1), calculate how many communications channels there are, when the number of people involved n ranges from 3 to Performance reporting Performance reporting keeps stakeholders informed about how resources are being used to achieve project objectives. The main inputs to performance report are the project plan and work results, whereas the main outputs include status reports, progress reports, forecasts, and change requests: ➊ Status reports: describe where the project stands at a specific point in time in terms of meeting scope, time, and cost goals ➋ Progress reports: describe what the project team has accomplished during a certain period ➌ Project forecasting: predicts future project status and progress based on past information and trends. The status review meeting is an important technique for performance reporting. First introduced in Module 5 (Project Integration Management), the status review meeting is a good way to highlight information provided in an important project document, empower people to be accountable for their work, and have face-to-face discussion about important project issues. However, project managers should set ground rules for status review meetings to control the amount of conflict.

177 Module 11 Project Communications Management Administrative closure The final phase of a project is closure. Administrative closure consists of verifying and documenting project results. The main outputs of administrative closure are project archives, formal acceptance, and lessons learned: ➊ Project archives: include a complete set of organised project records that provide an accurate history of the project. ➋ Formal acceptance: a document that the project s sponsor or customer signs to show that they have accepted the products of the project. ➌ Lessons learned: reflective statements written by project managers and their team members. The lessons learned reports include the causes of variances on the project, the reasoning behind corrective actions chosen, the use of different project management tools and techniques, and personnel words of wisdom based on the team members experience Suggestions for improving project communications This section highlights some issues that all the project managers and project team members should consider in their quests to improve project communications. Guidelines provided in this section aim at managing conflict, developing better communication skills, running effective meetings, using effectively, using templates for project communications, and developing a communications infrastructure Using communication skills to manage conflict It is crucial for project managers to develop and use their human resources and communications skills to help identify and manage project conflict. Project managers should develop norms to deal with various conflicts during the course of their project, e.g., what is the disrespectful behavior toward any project stakeholder. Blake and Mouton (see reference in Schwalbe s text) delineated five basic modes for handling conflicts: ➊ Confrontation mode: Project managers directly face a conflict using a problemsolving approach that allows affected parties to work through their disagreements.

178 11.10 ELE4402 Software Engineering Project Management ➋ Compromise mode: Project managers use a give-and-take approach to resolve conflicts. ➌ Smoothing mode: Project managers deemphasise or avoid areas of differences and emphasise areas of agreement. ➍ Forcing mode: can be viewed as the win-lose approach to conflict resolution. ➎ Withdrawal mode: Project managers retreat or withdraw from an actual or potential disagreement. It is the least desirable conflict-handling mode. Research indicates that the most favored mode by project managers is confrontation mode. The next favored one is compromise mode. Project managers should realise that not all conflict is bad. Task-related conflict, derived from differences over team objectives and how to achieve them, often improves team performance. However, emotional conflict, stemming from personality clashes and misunderstandings, often depresses team performance. Research conducted by Bay (see reference in Schwalbe s text) at California State University revealed that core competencies for developing collaboration skills include conflict resolution, negotiation, and mediation Developing better communication skills Most software engineers enter the field because of their technical skills. However, many of them find that communications skills are the key to advancing in their careers. Training is important for people to develop better communications skills. Some companies spend a lot money on technical training. However, a minimal investment in communication and presentation training can have a tremendous payback to individuals, their project and organisations. These soft skills usually have a much longer shelf life than technical ones. For organisations which operate in a multicultural environment such as international companies and universities, it is important to invest in ways to improve communication with people from different countries and cultures Running effective meetings A well-run meeting can be a vehicle for facilitating the project, whereas a poorly-run meeting can have a detrimental effect on a project. Some guidelines for improving time spent at meetings are provided as follows: ➊ determine if a meeting can be avoided

179 Module 11 Project Communications Management ➋ define the purpose and intended outcome of the meeting ➌ determine who should attend the meeting ➍ provide an agenda to participants before the meeting ➎ prepare handouts, visual aids, and make logistical arrangements ahead of time ➏ run the meeting professionally ➐ build relationship Using effectively Although is fast and convenient, many people tend to misuse it. As suggested in table 11.1, is not appropriate for assessing commitment, building consensus, mediating a conflict, resolving a misunderstand, making an ironic statement, conveying a reference document, reinforcing one s authority, or maintaining confidentiality. Some guidelines for using more effectively are provided as follows: ➊ information sent via should be appropriate for that medium versus other media ➋ be sure to send to the right people ➌ use meaningful subject lines ➍ limit the content of the to one main subject ➎ the body of the should be as clear and concise as possible, and check the carefully before it is sent ➏ limit the number and size of attachments ➐ delete that is not needed ➑ respond to quickly, if possible ➒ file appropriately each message that needs to be kept ➓ learn how to use other important features such as mailing lists, sorting, meeting organiser, etc..

180 11.12 ELE4402 Software Engineering Project Management Using templates for project communications It is a good practice for project managers to provide examples and templates for common project communications documents such as project descriptions, project charters, monthly performance reports, oral status reports, and so on. Good documentation from previous successful projects can be an ample source of examples. Appendix D and the companion website < of the textbook provide many useful project templates. A one-page project description shows a snapshot of an entire project on one page. It should include the project objective, scope, assumption, cost information, and schedule information. An example of a sample one-page project description is illustrated in Figure 10-2 in Schwalbe s text. Monthly progress reports focus on accomplishments during a specific time period. On the contrary, status reports focus on where the project stands at a certain point in time. Sections of a monthly progress report should include accomplishments from the current period, plans for the next period, issues, and project changes. An example of a sample monthly progress report is provided in Table 10-3 in Schwalbe s text. Some small projects such as class projects do not have a contract or official project charter. Instead, they have a letter of agreement which provides similar information in a less formal manner than a contract or project charter. Such an example is shown in Table 10-4 in Schwalbe s text. A final project report should include the following critical sections: ➊ a cover page and table of contents ➋ a one-page executive summary for long reports which highlights the most important information in the project ➌ a description of the need for the project ➍ the original project description and letter of agreement ➎ the overall outcome of the project and reasons for success or failure ➏ project management tools and techniques used and an assessment of them ➐ project team recommendations and future considerations ➑ the final project Gantt chart ➒ attachments with all project deliverables. For very large projects, the report would probably include many more items. Tables 10-5 and 10-6 in Schwalbe s text provide the outline and an exhaustive lists of times for a sample final project report.

181 Module 11 Project Communications Management Developing a communications infrastructure A communications infrastructure is a set of tools, techniques, and principles that provides a foundation for the effective transfer of information among people: ➊ Tools: include , project management software, groupware, fax machines, telephones, teleconferencing systems, document management systems, and word processing software. ➋ Techniques: include reporting guidelines and templates, meeting ground rules and procedures, decision-making processes, problem-solving approaches, conflict resolution and negotiation techniques. ➌ Principles: include providing an environment for open dialogue using straight talk and following an agreed-upon work ethic. In his book the speed of thought: using a digital nervous system, Bill Gates suggested how organisations gather, manage, and use information to empower people will determine whether they win or lose in a competitive business environment Using software to assist in project communications Microsoft Project comes with several template files for various types of projects, including a a software development project. The Internet or intranet can be utilised to help distribute project information across the project team and the organisation. Project websites provide a centralised way of delivering project documents and other communications. Compared to single user project management software, enterprise project manager software or groupware such as Lotus Notes provide much more powerful functions to help organisations maintain consistent and complete project information. Microsoft s Enterprise Project Management solution provides the following tools to enhance communications: ➊ portfolio management ➋ resource management ➌ project collaboration.

182 11.14 ELE4402 Software Engineering Project Management Reading Read Schwalbe s text Chapter 10. Read Brooks, Jr s text Chapter 2. Review questions Complete Discussion Questions 1 7 in Chapter 10, Schwalbe s text to fulfil the objectives of Module 11. Exercises Complete Exercises 1 4 in Chapter 10, Schwalbe s text. Minicase Complete the Minicase in Chapter 10, Schwalbe s text.

183

184 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution. Brooks, F 1979, The mythical man-month, Addison-Wesley.

185 Module 12 PROJECT RISK MANAGEMENT

186

187 Module 12 Project Risk Management 12.1 Objectives On successful completion of this module, you should be able to: ➀ understand what risk is and the importance of good project risk management ➁ discuss the elements involved in risk management planning ➂ list common sources of risks on information technology projects ➃ describe the risk identification process and tools and techniques to help identify project risks ➄ discuss the qualitative risk analysis process and explain how to calculate risk factors, use probability/impact matrixes, the Top Ten Risk Item Tracking technique, and expert judgment to rank risks ➅ explain the quantify risk analysis process and how to use decision trees and simulation to quantitative risks ➆ provide examples of using different risk response planning strategies such as risk avoidance, acceptance, transference, and mitigation ➇ discuss what is involved in risk monitoring and control ➈ describe how software can assist in project risk management ➉ explain the results of good project risk management. Learning resources Text Chapter 11, Schwalbe (4th edition) Module overview This module provides an introduction to project risk management, one of the most misunderstood knowledge areas of project management. Important topics include understanding what risk is and why risk management is important, the project risk management processes, tools and techniques such as probability/impact matrices, Top Ten Risk Item tracking, and simulations.

188 12.2 ELE4402 Software Engineering Project Management Figure 12.1: Overview of project risk management (source: PMBOK Guide 2004, p. 239)

189 Module 12 Project Risk Management 12.3 Figure 12.1 provides an overview as to what processes, inputs, tools and techniques, and outputs project risk management involve, based on the PMBOK Guide In the following sections, we briefly summarise the key concepts and principles presented in this module Importance of project risk management Project risk management is the art and science of identifying, analyzing, and responding to risk throughout the life of a project and in the best interests of meeting project objectives. All industries, especially the software development industry, tend to neglect the importance of project risk management. A survey conducted by KPMG revealed that 55% of runaway projects did no risk management at all, 38% did some, and 7% did not know whether they did risk management or not. The general dictionary meaning of risk is possibility of loss or injury. Project risk involves understanding potential problems that might occur on the project and how they might impede project success. Risk management should be regarded as an investment, with costs associated. The benefit of the investment is to lessen the impact of potentially adverse events on a project. In any case, the cost for risk management should not exceed the potential benefits. Risk utility or risk tolerance is the amount of satisfaction or pleasure received from a potential payoff. Depending on their attitude towards risk, people are divided into the following three categories: ➊ Risk-averse: people who see utility rise at a decreasing rate of potential payoff. ➋ Risk-seeking: people who see utility rise at an increasing rate of potential payoff. ➌ Risk-neutral: people who achieve a balance between risk and payoff. There are six major processes included in project risk management: ➊ Risk management planning: involves deciding how to approach and plan the risk management activities for the project. ➋ Risk identification: involves determining which risks are likely to affect a project and documenting the characteristics of each. ➌ Qualitative risk analysis: involves characterising and analysing risks and prioritising their effects on project objectives.

190 12.4 ELE4402 Software Engineering Project Management ➍ Quantitative risk analysis: measuring the probability and consequences of risks and estimating their effects on project objectives. ➎ Risk response planning: involves taking steps to enhance opportunities and reduce threats to meeting project objectives. ➏ Risk monitoring and control: involves monitoring known risks, identifying new risks, reducing risks, and evaluating the effectiveness of risk reduction throughout the life of the project Risk management planning The main output of risk management planning is a risk management plan, which documents the procedures for managing risk throughout the project. A risk management plan summarises the results of the risk identification, qualitative analysis, quantitative analysis, response planning, and monitoring and control processes. A risk management plan should address the following questions: ➊ Why is it important to take/not take this risk in relation to the project objectives? ➋ What is the specific risk, and what are the risk mitigation deliverables? ➌ What risk mitigation approach is to be used? ➍ Who are the individuals responsible for implementing the risk management plan? ➎ When will the milestones associated with the risk mitigation approach occur? ➏ How much is required in terms of resources to mitigate risk? The risk management plan can include the following contents: ➊ a methodology for risk management ➋ roles and responsibilities for activities involved in risk management ➌ budgets and schedules for the risk management activities ➍ descriptions of scoring and interpretation methods used for the qualitative and quantitative analysis of risk ➎ threshold criteria for risks ➏ reporting formats for risk management activities ➐ a description of how the project team will track and document risk activities. In addition to a risk management plan, many projects also include the following items:

191 Module 12 Project Risk Management 12.5 ➊ Contingency plan: predefined actions that the project team will take if an identified risk event occurs. ➋ Fallback plan: developed for risks that have a high impact on meeting project objectives, and are put into effect if attempts to reduce risk are not effective. ➌ Contingency reserves or contingency allowance: provisions held by the project sponsor that can be used to mitigate cost or schedule risk if changes in project scope or quality occur Common sources of risk on information technology projects Several studies have shown some common sources of risks on software development and information technology projects. A study done by the Standish Group <http: // revealed the following common sources of risks on information technology projects: ➊ lack of user involvement ➋ insufficient executive management support ➌ clear statement of requirements ➍ poor planning ➎ unrealistic expectations ➏ too few project milestones ➐ lack of competent staff ➑ unclear ownership ➒ unclear visions and objectives ➓ lack of hardworking, focused staff. Other broad categories of risk include: ➊ market risk ➋ financial risk ➌ technology risk. Understanding common sources of risk also helps in risk identification, the next step in project risk management.

192 12.6 ELE4402 Software Engineering Project Management 12.4 Risk identification Risk identification is the process of understanding what potential unsatisfactory outcomes are associated with a particular project. This is done through reviewing the project s risk management plan, other planning documents, and the broad categories of risks. Risk identification can also be done through a review of historical information related to risks on similar projects. It is important to identify potential risks according to project management knowledge areas. The potential risk conditions that can exist within each knowledge area are listed below: ➊ Integration: Inadequate planning, poor resource allocation, poor integration management, lack of post-project review. ➋ Scope: Poor definition of scope or work packages, incomplete definition. ➌ Time: Errors in estimating time or resource availability, errors in determining the critical path, poor allocation and management of float, early release of competitive products. ➍ Cost: Estimating errors, inadequate productivity, cost, change, or contingency. ➎ Quality: Poor attitude toward quality, substandard design/materials/workmanship, inadequate quality assurance program. ➏ Human Resources: Poor conflict management, poor project organisation and definition of responsibilities, absence of leadership. ➐ Communications: Carelessness in planning or communicating, lack of consultation with key stakeholders. ➑ Risk: Ignoring risk, unclear analysis of risk, poor insurance management. ➒ Procurement: Unenforceable conditions or contract clauses, adversarial relations. There are several tools and techniques for identifying risks. Six common informationgathering techniques include brainstorming, the Delphi Technique, interviewing, SWOT analysis, checklists and diagrams: ➊ Brainstorming: a technique by which a group attempts to generate ideas or find a solution for a specific problem by amassing ideas spontaneously and without judgement. However, group effects such as fear of social disapproval, the effects of authority hierarchy, and domination of the session by one or two very vocal people often inhibit idea generation for many participants.

193 Module 12 Project Risk Management 12.7 ➋ Delphi Technique: developed by the Rand Corporation for the U.S. Air Force in the late 1960s, is to derive a consensus among a panel of experts who make predictions about future developments. The Delphi Technique uses repeated rounds of questioning and written responses, including feedback to earlier-round responses, to take advantage of group input, while avoiding the biasing effects possible in oral panel deliberations. ➌ Time: a fact-finding technique for collecting information in face-to-face, telephone, , or instant messaging discussions. ➍ SWOT : stands for strengths, weaknesses, opportunities, and threats as introduced in Module 6, Project Scope Management. It is often used in strategic planning. It can also assist in risk identification by having project teams focus on the broad perspectives of potential risks for particular projects. ➎ Checklists: based on risks that have been encountered in previous projects providing a meaningful template for understanding risks in a current project. ➏ Diagrams: include using cause-and-effect diagrams or Fishbone diagrams, flow charts, and influence diagrams. The main output of the risk identification process are identified risk events for the project, triggers or risk symptoms, and inputs to other processes. Risk events are specific things that may occur to the detriment of the project. Triggers or risk symptoms are indicators of actual risk events Qualitative risk analysis Qualitative risk analysis involves assessing the likelihood and impact of identified risks, to determine their magnitude and priority. A few techniques for qualitative risk analysis are introduced in this section, which include: ➊ using probability/impact matrixes to calculate risk factors ➋ top Ten risk item tracking ➌ expert judgement Using probability/impact matrixes to calculate risk factors A probability/impact matrix or chart lists the relative probability of a risk occurring on one side of a matrix or axis on a chart and the relative impact of the risk occurring on

194 12.8 ELE4402 Software Engineering Project Management the other. Each risk is labelled as being high, medium or low in terms of its probability of occurrence and its impact if it does occur. The results of all potential risks are then summarised in a probability/impact matrix or chart, which is illustrated in figure Figure 12.2: Probability/Impact Matrix (Schwalbe, K 2006, Figure 11-4) In the above figure, the project team should focus on any risks that fall in the high sections of the probability/impact matrix or chart, such as risk 6, risk 9, risk 1 & 4, and risk 12. Calculating risk factors is a more sophisticated approach to using probability/impact information. The technique was developed by Defense Systems Management College (DSMC). Risk factors are numbers that represent the overall risk of specific events, based on their probability of occurring and the consequence to the project if they do occur. Determined by the nature of each project, probabilities of a risk occurring can be estimated based on several factors. Factors evaluated for software development technology risks include: ➊ the technology is not mature ➋ the technology is too complex ➌ an inadequate support base for developing the technology. The impact of a risk occurring could include factors such as: ➊ the availability of fallback solutions

195 Module 12 Project Risk Management 12.9 ➋ the consequences of not meeting performance estimate ➌ the consequences of not meeting cost estimate ➍ the consequences of not meeting schedule estimate. In practice, calculating risk factors is done through assigning a Probability of Failure (Pf) value and a Consequence of Failure (Cf) value to each proposed technique. Both Pf and Cf values take a value between 0 and 1. This is shown in Table 11-6 in Schwalbe s text. A risk factor is defined as the Pf plus the Cf minus the product of the two like Rf = (P f + Cf) P f Cf, (12.1) where Rf is the resulting risk factor, whereas P f and Cf are the Pf and Cf values for the proposed technique, respectively. Note that both P f and Cf are normalised values, ranging from 0 to 1. Furthermore, the risk factors for all the proposed techniques can be grouped together to graph the probability of failure and consequence of failure to visualise the final result, as depicted in Figure 11-3 in Schwalbe s text Top ten risk item tracking Top Ten Risk Item Tracking maintains an awareness of risks throughout the life of a project in addition to identifying risks. It involves establishing a periodic review of the project s most significant risk items with management and with the customer (optionally). The following matters are likely to be discussed in the review: ➊ the status of top ten sources of risk on the project ➋ each item s current ranking, previous ranking, and number of times it appears on the list over a period of time ➌ a summary of progress made in resolving the risk item since the previous review. Table 11-7 in Schwalbe s text provides an example of a Top Ten Risk Item Tracking Chart. A risk management review accomplishes the following objectives: ➊ It keeps the management and the customer aware of the major influences that could prevent the project from being a success. ➋ The project team may be able to consider alternatives that could mitigate the risk by involving the customer. ➌ It is a means of promoting confidence in the project team by demonstrating to management and the customer that the significant project risks are under control of the project team.

196 12.10 ELE4402 Software Engineering Project Management Expert judgement Many organisations rely on the experience of experts in performing qualitative risk analyses. Expert judgement is one of the main methods with which these organisations conduct risk analyses. Expert judgement has a number of advantages compared to other sophisticated risk analysis techniques. For example, experts can categorise risks as being high, medium, or low without using sophisticated techniques such as calculating risk factors, which can easily confuse people with little math and statistics background Quantitative risk analysis Large and complex projects often require extensive quantitative risk analysis, which is not necessary for smaller projects. The main technique for quantitative risk analysis includes decision tree analysis and simulation Decision trees and expected monetary value A decision tree is a diagramming analysis technique, which helps select the best course of action in situation in which future outcomes are uncertain. A common application of decision tree analysis involves calculating expected monetary value (EMV), which is the product of a risk event probability and the risk event s monetary value. Figure 11-4 in Schwalbe s text illustrates how to select the most appropriate project(s) out of a number of candidate projects. Each candidate project needs to be assigned the probabilities of certain events occurring. There is a outcome value associated with each probabilities. The sum of the probabilities for outcomes for each candidate project must equal one. Probabilities are normally determined based on expert judgement. To calculate EMV, one multiplies the probability by the outcome value for each potential project and sum the results like the following EMV = p 1 s 1 + p 2 s p n s n, (12.2) where p n and s n are the probability and outcome value of the nth candidate project, respectively. EMV provides an estimate for the total value of a decision. A positive number is desired, and the higher the EMV, the better. Using EMV helps account for all possible outcomes and their probabilities of occurrence, thereby reducing the tendency to pursue overly aggressive or conservative risk strategies.

197 Module 12 Project Risk Management Simulation Simulation is another sophisticated quantitative risk analysis technique. It uses a representation or model of a system to analyse the expected behavior or performance of the system. Monte Carlo analysis is a common technique for performing simulations. It simulates a model s outcome many times to provide a statistical distribution of the calculated results. There are some basic steps involved in the Monte Carlo analysis: ➊ Assess the range (most likely, optimistic, and pessimistic estimates) for the variables being considered and determine the probability distribution for each. ➋ For each variable, select a random value based on the probability distribution for the occurrence of the variable. ➌ Run a deterministic analysis or one pass through the model using the combination of values selected for each one of the variables. ➍ Repeat the first and second steps above many times to obtain the probability distribution of the results. The number of iterations depends on the number of variables and the degree of confidence required in the results. It is important to distinguish Monte Carlo analysis from Program Evaluation and Review Techniques (PERT) analysis. PERT analysis, introduced in Module 7 Project Time Management, involves making three estimates of each activity s duration. The weighting factors in the PERT formula are fixed, i.e., the most-likely estimate weighs four times more than the pessimistic or optimistic estimates. Therefore, it does not provide the flexibility or accuracy of the Monte Carlo analysis Risk response planning Risk response is the subsequent step after an organisation identifies and quantifies risks. Risk response planning involves defining steps for enhancing opportunities and developing plans for handling risks or threats to project success. Important outputs of the risk response development process include a risk management plan, contingency plans, and reserves. There are four basic risk response strategies summarised as follows: ➊ Risk avoidance: involves eliminating a specific threat or risk, usually by eliminating its causes. ➋ Risk acceptance: means accepting the consequences should a risk occur. ➌ Risk transference: is shifting the consequence of a risk and responsibility for its management to a third party.

198 12.12 ELE4402 Software Engineering Project Management ➍ Risk mitigation: involves reducing the impact of a risk event by reducing the probability of its occurrence. General technical, cost, and schedule risks mitigation strategies are summarised in the following: ➊ Technical Risks: Emphasise team support and avoid stand-alone project structure, increase project manager authority, improve problem handling and communication, increase the frequency of project monitoring, and use work breakdown structure (WBS) and critical path method (CPM). ➋ Cost Risks: Increase the frequency of project monitoring, use WBS and CPM, improve communication, project goals, understanding, and team support, increase project manager authority. ➌ Schedule Risks: Increase the frequency of project monitoring, use WBS and CPM, select the most experienced project manager. Even with risk management in place, there are still residual risks, which are risks that remain after all of the response strategies have been implemented. Other outputs of risk response planning include: ➊ contractual agreements ➋ estimates of needed contingency reserve ➌ inputs to other processes and the project plan Risk monitoring and control Risk monitoring and control involves executing the risk management processes and the risk management plan to respond to risk events. Executing the risk management processes means ensuring that risk awareness is an ongoing activity performed by the entire project team throughout the entire project. Executing the risk management plan involves monitoring risks on the basis of defined milestones and making decisions regarding risks and mitigation strategies. The tools and techniques needed for performing risk monitoring and control include: ➊ project risk audits ➋ periodic risk reviews ➌ earned value management

199 Module 12 Project Risk Management ➍ technical performance measurement ➎ additional risk response planning. Outputs of this process include corrective action, project change requests, and updates to other plans Results of good project risk management There are some differences between the risk management and crisis management. The major differences are summarised as follows: ➊ Resolving a crisis has much greater visibility than risk management, whereas risk management often goes unnoticed. ➋ Good crisis management is often rewarded by management, whereas good risk management often results in fewer problems, and more expeditious resolutions Using software to assist in project time management Some software tools can be used to assist in various risk management processes. Databases can keep track of risks, spreadsheets can aid in tracking and quantifying risks, and more sophisticated risk management software can help one develop models and use simulations to analyse and respond to various risks. Several software packages are available to perform Monte Carlo simulations, such as Risk+ by C/S Solutions, Inc., and Crystal Ball by Decisioneering, Inc. The latter is Microsoft Excel add-on software. These software packages use Monte Carlo-based simulation techniques to estimate the probability of meeting specific schedule goals. To do so, one needs to collect optimistic, pessimistic, and most-likely duration estimates for project tasks. One must also collect estimates for the probability of completing each task between the optimistic and most-likely times. There is a crucial distinction between Monte Carlo and PERT analysis. The former focuses on schedule estimates, whereas the latter can also be used to estimate cost

200 12.14 ELE4402 Software Engineering Project Management risks. In addition to estimating overall probabilities of project goals, Monte Carlo analysis can also be used to find top sources of risks, i.e., risk drivers. Activity 12.1 Microsoft Solution Framework and Risk Management The Microsoft Solution Framework (MSF) is the framework Microsoft uses for managing projects. The MSF provides an adaptable framework for successfully delivering information technology solutions faster, requiring fewer people, and involving less risk, while enabling higher quality results. The MSF provides proven practices from Microsoft for managing software projects. Risk management is a core discipline of the Microsoft Solutions Framework. The MSF Risk Management Discipline advocates a proactive approach to dealing with this uncertainty, evaluates risks continuously, and uses them to influence decision-making throughout the life cycle. The white paper of the MSF Risk Management can be downloaded from < Read through and research the MSF Risk Management Discipline White Paper. Write a one-page article to discuss how project managers can utilise the Microsoft Solution Framework to reduce project risks in developing large-scale software projects.

201 Module 12 Project Risk Management Reading Read Schwalbe s text Chapter 11. Review questions Complete Discussion Questions 1 10 in Chapter 11, Schwalbe s text to fulfil the objectives of Module 12. Exercises Complete Exercises 1, 3, and 4 in Chapter 11, Schwalbe s text. Minicase Complete the Minicase in Chapter 11, Schwalbe s text.

202 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution.

203 Module 13 PROJECT PROCUREMENT MANAGEMENT

204

205 Module 13 Project Procurement Management 13.1 Objectives On successful completion of this module, you should be able to: ➀ understand the importance of project procurement management and the increasing use of outsourcing for information technology projects ➁ describe the procurement planning process, procurement planning tools and techniques, types of contracts, and statements of work ➂ discuss what is involved in solicitation planning and the difference between a request for proposal and a request for quote ➃ explain what occurs during the solicitation process ➄ describe the source selection process and different approaches for evaluating proposals or selecting suppliers ➅ discuss the importance of good contract administration ➆ describe the contract close-out process ➇ discuss types of software available to assist in project procurement management. Learning resources Text Chapter 12, Schwalbe (4th edition) Module Overview This module provides an introduction to the last of the nine project management knowledge areas, project procurement management. Depending on the project environment, project managers may need to know a lot about this area or very little. Important topics include the growth in procurement for information technology projects, the processes involved in procurement management, and the types of software available to assist in procurement management. Figure 13.1 provides an overview as to what processes, inputs, tools and techniques, and outputs project procurement management involve. In the following sections, we briefly summarise the key concepts and principles presented in this module.

206 13.2 ELE4402 Software Engineering Project Management Figure 13.1: Overview of Project Procurement Management (source: PMBOK Guide 2004, p. 272)

207 Module 13 Project Procurement Management Importance of project procurement management Procurement involves acquiring goods and/or services from an outside source. Procurement is the preferred term for government agencies. It is also referred to as purchasing by many private companies, and outsourcing by information technology professionals. Organisations or individuals who provide procurement goods and services are referred to as suppliers, vendors, subcontractors, or sellers. Outsourcing is a fast growing area. Project managers must be well versed in project procurement management. Outsourcing has the following advantages: ➊ reduce both fixed and recurrent costs by taking advantage of outsourcer s economies of scale ➋ allow the client organisation to focus on its core business ➌ access skills and technologies ➍ provide flexibility ➎ increase accountability. Outsourcing has also the following disadvantages: ➊ organisations do not have as much control of the outsourced projects ➋ organisations could become too dependent on particular suppliers ➌ organisations must be careful to protect strategic information that could become vulnerable in the hands of suppliers. Project procurement management includes the processes required to acquire goods and services for a project from outside the performing organisation. There are six main processes in project procurement management, as follows: ➊ Procurement planning: involves determining what to procure and when. This process creates a procurement management plan as part of the procurement planning process. ➋ Solicitation planning: involves documenting product requirements and identifying potential sources. At the end of this process, a request for proposal (RFP) is often issued. ➌ Solicitation: involves obtaining quotations, bids, offers, or proposals as appropriate.

208 13.4 ELE4402 Software Engineering Project Management ➍ Source selection: involves choosing from among potential suppliers through a process of evaluating prospective suppliers, negotiating the contract, and awarding the contract. ➎ Contract administration: involves managing the relationship with the supplier. ➏ Contract close-out: involves completion and settlement of the contract, including resolution of any open items. Figure 13.2 illustrates the major processes and their important milestones at each stage of the six processes involved in project procurement management. Figure 13.2: Project Procurement Management Processes and Key Outputs (Schwalbe, K 2004, Figure 12-1) 13.2 Procurement planning Procurement planning is the process of identifying which project needs can best be met by using products or services outside the organisation. It involves deciding whether, how, what, how much, and when to procure. The process includes the following inputs: ➊ project scope statement ➋ product descriptions ➌ market conditions ➍ constraints ➎ assumptions. It is important to understand why a company would want to procure goods or services and what inputs are needed to do procurement planning. It is also important to define clearly the scope of the project, the products, market conditions, and constraints and consumptions.

209 Module 13 Project Procurement Management Procurement planning tools and techniques Tools and techniques included in the procurement planning process are performing make-or-buy analysis and consulting with experts. Make-or-buy analysis is a general management technique that an organisation can use to determine whether it should make or perform a particular product or service inside the organisation or buy from some else. The organisation makes the decision by estimating the internal costs of providing a product or service, and comparing the estimate to the cost of outsourcing. Many organisations also use make-or-buy analysis to decide if they should either purchase or lease items for a particular project. Furthermore, both internal and external expert judgement should be utilised in making procurement decisions Types of contracts Contract type is an important consideration in procurement planning. There are four broad categories of contracts, which are listed in Table For the category of cost-reimbursable contracts, it can be further subdivided into three types as shown in Table Figure 13.3 visualises the risks to both the buyer and supplier for different types of contracts. As shown in the figure, firm-fixed price contracts have the lowest risk for buyers, whereas cost plus percentage of costs contracts have the most risk for buyers. From the supplier s perspective, cost plus percentage of costs contracts are most desirable, whereas firm-fixed price contracts are least desirable. Figure 13.3: Contract types versus risk (Schwalbe, K 2006, Figure 12-1) In some situations, it is important to include a termination clause in the contract, which allows the buyer or supplier to end the contract under certain circumstances.

210 13.6 ELE4402 Software Engineering Project Management Table 13.1: Four types of contracts Type of Contract Description Note Fixed-price (Lump-sum) Contracts Cost-reimbursable Contracts Time and Material Contracts Unit Price Contracts Involves a fixed total price for a well-defined product or service. Involves payment to the supplier for direct and indirect actual costs. A hybrid of both fixed-price and cost-reimbursable contracts. Requires the buyer to pay the supplier a predetermined amount per unit of service, and the total value of the contract is a function of the quantities needed to complete the work. Least amount of risk for the buyer. May include incentives for meeting or exceeding selected project objectives. Often includes fees such as a profit percentage or incentives for meeting or exceeding selected project objectives. Often used for services that are needed when the work cannot be clearly specified and total costs cannot be estimated in a contract. This type of contract often involves volume discounts Statement of work (SOW) Many contracts often include a statement of work (SOW), which is a description of the work required for the procurement. The SOW is a type of scope statement that describes the work in sufficient detail to allow prospective suppliers to determine if they are capable of providing the goods and services required and to determine an appropriate price. A SOW should be clear, concise, and complete. It is also important to use appropriate words in SOWs, e.g., using must instead of may. A good SOW gives bidders a better understanding of the buyer s expectations. A SOW should become part of the official contract to ensure that the buyer gets what the supplier bid on. It is common that many organisations use samples and templates to generate SOWs. A SOW example is given in Figure 12-3 in Schwalbe s text. For software development projects, a SOW could include the following items: ➊ scope of work ➋ location of work ➌ period of performance

211 Module 13 Project Procurement Management 13.7 Table 13.2: Three types of cost-reimbursable contracts Type of Contract Description Risk Cost plus Incentive Fee (CPIF) Contract Cost plus Fixed Fee (CPFF) Contract Cost plus Percentage of Costs (CPCC) Contract The buyer pays the supplier for allowable performance costs along with a predetermined fee and an incentive bonus. The buyer pays the supplier for allowable performance costs plus a fixed fee payment usually based on a percentage of estimated costs. The buyer pays the supplier for allowable performance costs along with a predetermined percentage based on total costs. Least amount of risk for the buyer out of the three contracts. Medium amount of risk for the buyer out of the three contract. Most amount of risk for the buyer out of the three contract.. ➍ deliverables schedule ➎ applicable standards ➏ acceptance criteria ➐ special requirements. Activity 13.1 Contract The contract is one of the most important documents in project procurement management. It is also the final output of the source selection process described in Section A contract is a legal document. It obligates the supplier to provide the specific products or services and obligates the buyer to pay for them. Read through an online sample contract for the Internet Telephony Interoperability project at Massachusetts Institute of Technology available at < What type of contract is it according to the classifications described in Section ? Review the language and clauses in the contract. Pay special attention to the SOW of the contract. Write some dot points to analyse the key features of the contract.

212 13.8 ELE4402 Software Engineering Project Management 13.3 Solicitation planning Solicitation planning involves preparing the documents needed for solicitation and determining the evaluation criteria for the contract award. There are two major solicitation documents, which include the request for proposal (RFP) and the request for quotes (RFQ). A request for proposal (RFP) is a document used to solicit proposals from prospective suppliers, whereas a request for quotes (RFQ) is a document used to solicit quotes or bids from prospective suppliers. It is usually easier and less time consuming to prepare a RFQ than a RFP. Writing a good RFP is a critical part of project procurement management. There are often legal requirements involved in issuing RFPs and reviewing proposals, especially for government projects. Figure 12-4 in Schwalbe s text shows a basic outline for an RFP, which includes the following main sections: ➊ a statement of the purpose of an RFP ➋ background information on the organisation issuing the RFP ➌ the basic requirements for the products and/or services being proposed ➍ the hardware and software environment (important for information technology related projects) ➎ a description of the RFP process ➏ the statement of work and schedule information ➐ possible appendices. The length of RFPs varies depending on the size of the project. A simple RFP might be three to five pages long, whereas more complicated ones might be hundreds of pages long. No matter the length of a RFP, it is of paramount importance that the RFP has enough information to provide the basis for a good proposal. There are also some other documents used in solicitation planning that include: ➊ invitations for bid ➋ invitations for negotiation ➌ initial contractor responses. All of the solicitation planning documents mentioned above should be rigorous enough to ensure consistent, comparable responses, but flexible enough to allow consideration of supplier suggestions for better ways to satisfy the requirements. It is important for the buying organisation to prepare some form of evaluation criteria, which the organisation uses to rate or score proposals. The criteria should be specific and objective. Some examples of criteria and their respective weighting are:

213 Module 13 Project Procurement Management 13.9 ➊ technical approach (30%) ➋ management approach (30%) ➌ past performance (20%) ➍ price (20%) Solicitation Solicitation involves obtaining proposals or bids from prospective suppliers, who do most of work in this process normally at no cost to the buying organisation. The buying organisation is responsible for advertising the solicitation. In some cases, some organisations have formed good working relationships with certain suppliers, so the buyer would just give solicitation information to its preferred supplier. However, in more cases, there are more than one qualified supplier to choose from. Providing information and receiving bids from multiple sources often gives the buying organisation the opportunity to take advantage of the competitive business environment. The buying organisation often holds some sort of bidders conference (also called prebid conference), which is a meeting with prospective suppliers priori to preparation of a proposal. The purpose of the meeting is to ensure that prospective suppliers have a clear, common understanding of the buyer s desired products or services. Moreover, the buyer may gather feedback information and amend the procurement documents accordingly Source selection Source selection is the next step after buyers receive proposals from suppliers. It involves evaluating bidders proposals, choosing the best one, negotiating the contract, and awarding the contract. Source selection is often a long, tedious process, and involves stakeholders in the procurement process. There might be a technical team, a management team, and a cost team to focus on each of those major areas of source selection. Buyers often develop a short list of the top three to five suppliers to reduce the work involved in selecting a source. Formal proposal evaluation sheets are highly recommended by experts during source selection. Figure 12-5 in Schwalbe s text provides a sample proposal evaluation sheet, which is a form of a weighted scoring model described in Module 6 (Project Scope Management). The listed criteria listed in the figure are the same as those listed in Section It is noted that many software development projects tend to pay too much attention to technical aspects of proposals. This tendency should be avoided as

214 13.10 ELE4402 Software Engineering Project Management experts recommend that technical criteria should not be given more weight than management or cost criteria. It is often the supplier s management team, not the technical team, that makes procurement successful. After shortlisting potential suppliers, the buying organisation often follows a more detailed proposal evaluation process. Figure 12-6 in Schwalbe s text lists some further criteria for the top three candidates for a large information technology project as follows: ➊ project manager s educational background and experience ➋ project manager is Project Management Professional (PMP) certified ➌ presentation on management approach ➍ organisation s project management methodology. It is customary to have contract negotiations during the source selection process. The shortlisted suppliers are often asked to prepare a best and final offer (BAFO). In addition, top managers from both the buying and selling organisations often meet before making final decisions. The final output from the source selection process is a contract that obligates the supplier to provide the specified products or services and obligates the buyer to pay for them Contract administration Contract administration ensures that the supplier s performance meets contractual requirements. The contractual relationship is a legal relationship and as such is subject to state and federal contract laws. As a result, legal and contracting professionals should be involved in writing and administrating contracts. Ideally, the project manager and their team should be actively involved in writing and administrating the contract so that everyone understands the importance of good procurement management. The project team should also seek expert advice in working with contractual issues. Change control is an important of the contract administrative process. Changes must be handled properly for items under contract. Some suggestions for ensuring adequate change control on projects include: ➊ changes to any part of the project need to be reviewed, approved, and documented by the same people in the same way that the original part of the plan was approved ➋ evaluation of any change should include an impact analysis

215 Module 13 Project Procurement Management ➌ changes must be documented in writing. When a project involves outside contracts, it is critical that project managers and team members watch for constructive change orders, which are oral or written acts or omissions by someone with actual or apparent authority that can be construed to have the same effect as a written change order Contract close-out Contract close-out is the final process in project procurement management. It includes performing the following activities: ➊ Product verification: determine if all work was completed correctly and satisfactorily. ➋ Administrative activities: update records to reflect final results and archiving information for future use. ➌ Procurement audits: identify lessons learned in the procurement process. Outputs from contract close-out include a contract file and formal acceptance and closure. The buying organisation should provide the supplier with formal written notice that the contract has been completed. The contract itself should include requirements for formal acceptance and closure Using software to assist in project communications Many organisations use word-processing software to write proposals or contracts, spreadsheet software to create proposal evaluation worksheets, database to track suppliers, and presentation software to present procurement-related information. The term e-procurement first emerged early 2000s, which describes various procurement functions that are now done electronically. Traditional procurement methods were very inefficient and costly, and new e-procurement services have proved to be very effective in reducing the costs and burdens of indirect procurement. Many different Web sites and software tools are now available to assist in various procurement functions. Some organisations invest heavily in enterprise resource planning (ERP) systems. ERP systems integrate several business functions, such as manufacturing, finance, human resources, sales, and distribution across an enterprise into a single computer system that can serve all those different departments particular needs.

216 13.12 ELE4402 Software Engineering Project Management Reading Read Schwalbe s text Chapter 12. Review questions Complete Discussion Questions 1 7 in Chapter 12, Schwalbe s text to fulfil the objectives of Module 13. Exercises Complete Exercises 3, 4, and 6 in Chapter 12, Schwalbe s text. Minicase Complete the Minicase in Chapter 12, Schwalbe s text.

217

218 References Schwalbe, K 2006, Information technology project maangement, 4th edn, Thomson Course Technology. Schwalbe, K 2004, Information technology project maangement, 3rd edn, Thomson Course Technology. Project Management Institution (PMI), 2004, Project management body of knowledge (PMBOK Guide 2004), Project Management Institution.