Acu Project Management Handbook

PROJECT MANAGEMENT HANDBOOK

Version 1.3

April 2007

DOCUMENT CONTROL Author

H. Terese Parks Heliograph Services Pty Ltd Paul Campbell, Director, Information Technology and Communication Services (ITCS) Rona Brown MIS Manager, Information Technology and Communication Services (ITCS) Barbara Olde Former Director, Information Technology and Communication Services (ITCS)

Contributors

File Name Last Edited

26.04.07

Record of Amendments Date

Version

Changed by

Description of Changes

June 2003 September 2003

1.0 1.1

Helen Terese Parks Helen Terese Parks

October 2003

1.2

Helen Terese Parks

April 2007

1.3

Sean Connell

Initial draft of entire Handbook  Inclusion of cost and benefit analysis methods  Inclusion of IT&T testing terms  Elaboration of Project Charter instructions  Inclusion of changes arising from initial review of draft by Barbara Olde, Former Director, ITCS and Rona Brown, Manager, MIS, ACU Inclusion of summary overview at request of Barbara Olde, Former Director, ITCS Inclusion of Communications Management section and template at request of Paul Campbell, Director, ITCS

Page 2 of 94

Table of Contents 1

Overview .......................................................................................................................................................................................... 7 1.1 Project Initiation ........................................................................................................................................................................ 8 1.2 Project Establishment ............................................................................................................................................................... 8 1.3 Project Planning ........................................................................................................................................................................ 8 1.4 Project Control .......................................................................................................................................................................... 9 1.5 Project Completion.................................................................................................................................................................... 9 2 Introduction .................................................................................................................................................................................... 10 What is a Project? ............................................................................................................................................................................. 10 3 Project Management Phases ......................................................................................................................................................... 11 4 Project Scope ................................................................................................................................................................................ 12 5 Role of the Project Manager........................................................................................................................................................... 13 6 User and project staff interrelationship ........................................................................................................................................... 13 7 Knowledge base ............................................................................................................................................................................ 14 8 Project Charter ............................................................................................................................................................................... 15 9 Business Process Mapping ............................................................................................................................................................ 16 9.1 Fact finding and recording techniques..................................................................................................................................... 16 9.2 Charting .................................................................................................................................................................................. 17 9.2.1 Types of Charts ............................................................................................................................................................... 18 9.2.1.1 Information Flow Charts ............................................................................................................................................ 18 9.2.1.2 Special Purpose Charts ............................................................................................................................................ 19 9.2.1 Entity Relationship Diagram ............................................................................................................................................. 19 9.2.3 Process Flow Chart.......................................................................................................................................................... 20 9.2.3 Analysis of Process Charts .............................................................................................................................................. 21 10 Project Management Life Cycle .................................................................................................................................................. 22 11 Project Initiation .......................................................................................................................................................................... 23 11.1 Define Project Scope and Objectives .................................................................................................................................. 24 11.1.1 Project scope ................................................................................................................................................................... 24 11.1.2 Project objectives ............................................................................................................................................................. 24 11.2 Cost and Benefit Analysis (CBA) ......................................................................................................................................... 24 11.2.2 Internal Rate of Return (IRR) ........................................................................................................................................... 24 11.2.3 Net Present Value (NPV) ................................................................................................................................................. 24 11.2.4 Return on Investment (ROI) ............................................................................................................................................. 25 11.3 Developing a cost/benefit analysis ................................................................................................................................... 25 11.3.1 Identify benefits................................................................................................................................................................ 25 11.3.2 Identify costs .................................................................................................................................................................... 25 Page 3 of 94

11.3.3 Develop the project cash flow schedule ........................................................................................................................... 25 12 Project Planning ......................................................................................................................................................................... 26 12.1 Change Management Plan .................................................................................................................................................. 27 13 Project organisation .................................................................................................................................................................... 27 13.1 Executive Sponsor .............................................................................................................................................................. 28 13.2 Project Sponsor ................................................................................................................................................................... 28 13.3 Project Manager .................................................................................................................................................................. 29 14 Scope Management ................................................................................................................................................................... 30 14.1 Scope creep considerations: ............................................................................................................................................... 31 14.1.1 Impact analysis ................................................................................................................................................................ 31 14.1.2 Cost analysis ................................................................................................................................................................... 31 14.1.3 Mandatory changes ......................................................................................................................................................... 31 15 Project Status Reporting ............................................................................................................................................................. 32 16 Issue Management ..................................................................................................................................................................... 33 17 Risk Management ...................................................................................................................................................................... 35 18 Communication Management ..................................................................................................................................................... 37 19 Project completion ...................................................................................................................................................................... 39 20 APPENDIX A –DATA MODELLING............................................................................................................................................ 40 19.1 Conceptual data modelling .................................................................................................................................................. 40 19.1.1 Entities. ............................................................................................................................................................................ 40 20.1.1.1 Defining .................................................................................................................................................................... 40 20.1.1.2 Composite entities .................................................................................................................................................... 40 20.1.1.3 Aggregates ............................................................................................................................................................... 40 20.1.1.4 Sub-classification of entities ...................................................................................................................................... 41 20.1.1.5 Physical boundaries .................................................................................................................................................. 41 20.1.1.6 Events ...................................................................................................................................................................... 41 20.1.1.7 Messages ................................................................................................................................................................. 41 19.1.2 Attributes. ........................................................................................................................................................................ 41 19.1.2.1 Attribute names......................................................................................................................................................... 42 19.1.2.1 Domains ................................................................................................................................................................... 42 19.1.2.2 Identifier attributes. ................................................................................................................................................... 42 19.1.2.3 Time-varying attributes. ............................................................................................................................................ 42 19.1.2.4 Optional attributes. .................................................................................................................................................... 42 19.1.3 Relationships ................................................................................................................................................................... 42 19.1.3.1 Number and type of roles .......................................................................................................................................... 42 19.1.3.2 Degree ...................................................................................................................................................................... 43 19.1.3.3 Optionality................................................................................................................................................................. 44 Page 4 of 94

19.1.3.4 Permanence ............................................................................................................................................................. 44 19.1.3.5 Dependencies ........................................................................................................................................................... 44 19.2 Logical Data Modelling ........................................................................................................................................................ 45 19.2.1 Data Modelling Objects .................................................................................................................................................... 45 19.2.2 Relationship diagrams ..................................................................................................................................................... 45 19.2.3 Attribute diagrams ............................................................................................................................................................... 46 19.2.3.1 Type/Occurrence Distinction ..................................................................................................................................... 46 19.2.3.2 Membership Class (Connectivity Characteristics) ......................................................................................................... 47 19.2.3.3 Degree ...................................................................................................................................................................... 49 19.2.3.4 Attribute Values ........................................................................................................................................................ 50 19.2.3.5 Domains ................................................................................................................................................................... 50 19.3 Physical Data Model ............................................................................................................................................................ 52 19.3.1 Overview.......................................................................................................................................................................... 52 19.3.2 Generating the Data Archive PDM ................................................................................................................................... 52 19.3.3 ISO Data Archive Physical Data Model – example: .......................................................................................................... 53 21 APPENDIX B – PROJECT CHARTER FORMAT ....................................................................................................................... 54 22 APPENDIX C - Critical Path Analysis (CPA) ............................................................................................................................... 57 23 APPENDIX D - Program Evaluation and Review Technique (PERT) .......................................................................................... 59 24 APPENDIX E - Gantt Chart ........................................................................................................................................................ 61 25 APPENDIX F - Work Breakdown Structure (WBS) ..................................................................................................................... 62 24.1 Phase .................................................................................................................................................................................. 62 24.2 Stage................................................................................................................................................................................... 62 24.3 Activity ................................................................................................................................................................................. 62 24.4 Task .................................................................................................................................................................................... 62 26 APPENDIX G - BUSINESS CASE TEMPLATE .......................................................................................................................... 63 TABLE OF CONTENTS .................................................................................................................................................................... 64 Section 1 – Executive Summary ........................................................................................................................................................ 64 Section 2 – Statement of the business issue ..................................................................................................................................... 64 Section 3 – Background and Business Drivers .................................................................................................................................. 64 Section 4 – Project Scope and Objectives ......................................................................................................................................... 64 Section 5 - Evaluation of Alternative Solutions................................................................................................................................... 64 Section 6 – Proposed System Description ......................................................................................................................................... 65 Section 7 – Economic Justification .................................................................................................................................................... 65 Section 8 – Implementation timeline .................................................................................................................................................. 66 Section 9 – Project structure .............................................................................................................................................................. 66 Section 10 – Critical Assumptions and Risk Assessment................................................................................................................... 66 Section 11 – Conclusions and Recommendations ............................................................................................................................. 67 Page 5 of 94

Section 12 - References & Related Documents ................................................................................................................................. 67 27 APPENDIX H – Project Status Report format ............................................................................................................................. 68 28 APPENDIX I - Issue Log format .................................................................................................................................................. 70 29 APPENDIX J – Risk Management Schedule .............................................................................................................................. 71 30 APPENDIX K – Communication Plan Template.......................................................................................................................... 79 1. Communications Plan Executive Summary ................................................................................................................................ 81 2. Marketing and Communication Strategies .................................................................................................................................. 81 a. Communicating Major Risks, Issues and Changes ................................................................................................................. 81 3. Stakeholder Communication....................................................................................................................................................... 82 4. Training Strategies ..................................................................................................................................................................... 82 31 APPENDIX L – Internal Rate of Return (IRR) ............................................................................................................................. 83 32 APPENDIX M – Net Present Value (NPV) .................................................................................................................................. 85 33 APPENDIX N – Return on Investment (ROI) .............................................................................................................................. 87 34 APPENDIX O – Weekly Project Review Meeting Minutes - Format ............................................................................................ 91 35 APPENDIX P – TESTING INFORMATION TECHNOLOGY APPLICATIONS............................................................................. 92 Terminology....................................................................................................................................................................................... 92 36 BIBLIOGRAPHY......................................................................................................................................................................... 94

Page 6 of 94

1 Overview This Handbook provides a standard framework to guide project management at ACU National. Because each Project is a self-contained related group of work activities with a specific predefined deliverable, it is not feasible to define every detail of work for every Project within a rigid template. However, this Handbook does define a set of documents that must be included in every Project. Hence, it provides a consistent framework within which to conduct all the work necessary for the success of each Project, notwithstanding that some of the tasks within the standard framework will vary according to the nature and complexity of the Project to which it is applied. The ACU National Project Management methodology is comprised of five phases, each of which results in specific documentation (refer Section 3). Also note that communication should be a key consideration when drafting and disseminating project documentation.

Initiation

Establishment

B usiness C ase

Pro ject C hart er

Planning

Pro Project ject Plan Plan

Control

Pro Project ject St at us St at us RReport ss eport

Completion

AAccept ance ccept ance Sig of ff Signnof

Post Im ple ment at i on R eview

Communication Communication

Page 7 of 94

1.1 Project Initiation Project initiation has the following objectives:           

Identify and document the business need/objectives that the project will address Determine and evaluate alternative ways in which the business need can be met and recommend the best solution Assure and establish sponsorship of the project Define the objective, approach and controls of the project Estimate the project effort, duration and cost Ensure a clear and common understanding of the deliverables that will be produced Specify what work needs to be completed in order to produce the deliverables Determine the type of skills that will be needed to complete the project Estimate how long it will take and what it will cost (once-off and ongoing/capital and operating expenditure) Specify what will constitute completion of the project Obtain appropriate management approval for effort and cost

Project initiation is completed upon sign-off of the final Business Case. The Business Case is a static document that is never to be changed after sign-off. The Business Case forms the baseline benchmark for the post-implementation evaluation of success, against which achievements will be measured.

1.2 Project Establishment Project establishment has the following objectives:    

Allocate responsibility, assign the project manager, specify the project sponsor and establish an appropriate steering committee Identify project team members (according to skill needs identified in the Business Case), identify and define the role of stakeholders Document the project team structure Establish project cost codes and allocate budget to those codes

Project establishment is completed upon sign-off of the Project Charter. The Project Charter is to be amended as and if any element of the initial Project Charter changes. However, version control is to be adhered to strictly, so that changes can be tracked in the quality assurance process and as input to the post-implementation review. Any change to the original Project Charter requires that a new version of the Project Charter be created and promulgated/published. 1.3 Project Planning Project planning has the following objectives and deliverables:     

Confirm all previous assumptions regarding skills required, number of project staff, effort and duration, etc. Confirm specific skill requirements, confirm that those resources are available (in-house or by external contract resources), identify the individuals who will be assigned according to the skill requirements for various tasks and sub-projects Document work breakdown structure, including specific tasks, milestones and deliverables Refine estimates of task efforts Determine task dependencies Page 8 of 94

     

Determine external dependencies Determine interface and interaction dependencies Determine milestones that will represent quality assurance checkpoints and their completion dates Schedule the work plan, inclusive of constraints Prepare and review the project plan Submit the initial project plan for approval by the relevant executive sponsor, project sponsor and steering committee

Project planning is an iterative and ongoing process. However, the initial project plan must be approved and signed-off before the project commences. At this point, the project plan is to be base lined, to ensure that any and all variances from that plan are tracked and recorded. 1.4 Project Control Project control is ongoing throughout the duration of a project. Project status reports must be completed at intervals agreed in the project planning phase, but no less often than monthly. Project control has the following objectives: 

   1.5

Capture actual data and compare that data to the relevant project plan and budget to: o Analyse performance o Review estimates of cost and time to complete o Post actual costs against budgeted costs and explain variances Communicate progress of the project Review and update the project plan as necessary Review and update the original project charter as necessary Project Completion

Project completion is a once-off activity. All stakeholders must sign-off their satisfaction with the project deliverable/s before a project can be deemed to be complete.

Page 9 of 94

2 Introduction What is a Project? A project is any related group of work activities which, when completed, will achieve specific objectives. A project has a stated scope, deliverables, tasks, work steps, duration and budget, as defined in a Project Charter. This Handbook is relevant to all related groups of work activities that have a business objective, whether the solution involves Information Technology and Telecommunications (IT&T) or not. While some terminology used in this Handbook may cause the reader to infer IT&T system development project management, the processes apply to all projects, whether technology based or not. A project:     

Has a beginning and an end; Is defined by specific objectives (deliverables); Is undertaken within a well defined organisational structure; Has a single project manager who is responsible for its success; Has a defined starting point, a defined end point, and defined work breakdown structure comprising a path from the start to the end.

To be successful, a project must move forward in a controlled manner, from initiation to completion. A project uses resources. These include work effort of the project team, including significant stakeholders not assigned directly to the team, infrastructure support, project administration, money for project related travel and training, etc. Resources must be used effectively or the project will be late, or over budget, or both. Project milestones, comprised of specific deliverables, are developed to show tangible results of work done and to provide substance for quality assurance reviews. Quality Assurance (QA) reviews are essential, to identify issues at the earliest possible stage, to enable them to be addressed so that the overall project objectives, delivery date and budget are not adversely impacted. Risks are inherent in all projects. A risk management plan is an essential element of any project charter. Any and all foreseeable risks must be documented and relevant mitigation strategy devised. Project Management is the process by which a project is initiated, controlled, and brought to a successful implementation. The objective of project management is to plan and control a project from start to end, with high levels of productivity and quality. A project must be managed in terms of its structure, work performed by staff assigned to it, specific deliverables and budget constraints. Levels of control and monitoring will vary depending on the timeframe and criticality of the project at hand. Progress reporting will also vary depending on its intended audience.

Page 10 of 94

3 Project Management Phases INITIATION

BUSINESS CASE

ESTABLISHMENT PROJECT MANAGEMENT

PLANNING CONTROL

INITIATION Business need recognise d Project scope & objectives define d and agreed

COMPLETION Alternative solutions determined PROJECT PLAN PLANNING

Alternative solutions evaluated and compared

Confirm assumptions Recommended solution determine d Confirm resource (skill) requireme nts Confirm resource ava ilability, identify individua ls to be assigned to skill needs Determine tasks, work breakdown structure, milestones and de liverables

Business Case developed Business Case presented to appropriate manage ment Committee for approval and budget allocation Proposa l approved by ma nageme nt and budget approve d

Estimate task effort Determine task dependenc ies

PROJECT CHARTER ESTABLISHMENT

Determine externa l depe ndenc ies Determine interface/interaction dependenc ies

Allocate responsibility, assign project ma nager, project sponsor, establish steering committee

Determine key milestone completion dates

Identify project team and stakeholders

Schedule pla n, inc lusive of constraints Review Project Plan

Docume nt project team structure Establish project cost codes and a llocate budget

Submit Project Plan for acceptance

PROJECT STATUS REPORTS CONTROL Analyse performance

ACCEPTANCE SIGN-OFF COMPLETION

Capture actual data, compare and ana lyse Actuals VS Plan

Review estimates to complete Post actual against budget

Process Owner & Executive Sponsor sign-off CHARGE (if applicable) POST IMPLEMENTATION REVIEW

Communicate progress Review Project Plan

Page 11 of 94

4 Project Scope The scope of any project should be derived from and be consistent with an overall enterprise model of business needs, priorities, strategies and infrastructure. Projects should be identified based on a number of complementary developments and prioritised according to prevailing business objectives. The planning phase of any project is critical to its ultimate success. During the planning phase, the University‟s goals, objectives and critical success factors have to be taken into account. Similarly, the strategies, data, processes and organisational structure must be reflected in the planning of any project. Each functional division will be a cluster of processes and data and reflect a part of the overall University strategy and organisational elements associated with them. All processes will cross numerous functional divisions, and the end-to-end impact of any change to any process needs to be identified and addressed during a project‟s planning phase.

UNIVERSITY OBJECTIVES BUSINESS PROCESS

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

BUSINESS PROCESS

BUSINESS PROCESS BUSINESS PROCESS SUPPORTING RESOURCES

No project can be an island in the context of an holistic organisation. Projects should not be single point solutions to business problems or needs. The top down planning process will ensure that each project represents a tactic within an overall business program. Project managers have to manage these interdependencies without compromising the success of the individual projects for which they are responsible.

Page 12 of 94

5 Role of the Project Manager The project manager acts as a leader and a process manager. As a leader, the project manager is responsible for managing and communicating a clear vision of the project objectives, and for motivating the project team to achieve them. As a process manager, the project manager must ensure that work efforts are sequenced to achieve the overall project schedule. A project manager must have credibility with their project team and with the project sponsor. So it is essential that the project manager have, or acquire, some knowledge of the technical aspects of any project to which he/she is assigned. Project deliverables are very rarely static over the life of a project. Objectives and deliverables may, and usually do, change as new information is gathered by the project team and evaluated by the project sponsor. The project manager must assure a well defined scope management plan, provide continuous leadership for the development team, manage the project sponsor relationship effectively, and create a project environment that allows all participants to maintain maximum productivity and effectiveness.

6 User and project staff interrelationship Business users, not technology or external providers, should be the focus of every project. User involvement ultimately determines the quality of business systems. Past practices isolated users from the project process. It was, therefore, hard for users to commit to a process in which they had not participated, or had been afforded the opportunity to understand. This “them” and “us” approach inevitably militates against success of any project. When designing a project organisation structure, the roles of users as members of the project team, the management and control structure, and support groups need to be defined before the project begins. Users need to be involved in any project;    

to assure project direction continues towards the specific business needs and objectives, as an information source, as reviewers and evaluators of deliverables, as members of the project team in the functional analysis and process modelling stages.

Business process models need to be developed to ensure that the current procedures and proposed changes are understood clearly. Such models need to be developed jointly by the business users and the project staff, to derive a common understanding of the business and its needs. Models developed by project staff in isolation from the business knowledge base are insufficient to assure a common understanding. Many projects fail because they lack credibility with the end users. This lack of credibility often arises from:  

Past failures to deliver on commitments; projects are often late, over budget and deliver less than the end users expected. Poor communications; users are not listened to, project staff prefer to minimise interaction with end users, assumptions are made, there is a reliance on informal communications, overuse of jargon and an unpreparedness to speak to the users in their own terms. If end users are not sufficiently involved in the project the project will inevitably lose support. Page 13 of 94

 

Perceived lack of structure and process. Interviews and work shops will appear random unless the users receive timely and professionally structured feedback. An over emphasis on technology, rather than the business need. Often, to the end users, a project can seem to be predicated on the project teams‟ desire to use technology, particularly topical technology, rather than to address the actual business need, which may be resolved without technology at all.

7 Knowledge base A thorough knowledge base should underpin every project. A knowledge base is the set of all information relevant to the identified business need that is collected during the planning, analysis, design, development and implementation phases of a project. The accumulated knowledge base should be documented using a conceptual data model, a logical data model and a physical data model to constitute a central repository of the University‟s accumulated knowledge relevant to the particular project. Assuring a comprehensive knowledge base is essential to maintaining a rigorous structure in any project. The scope of information represented in the knowledge base is far greater than the traditional project information of tasks, money, time and resources. Strategic plans, organisational models, requirements models and functional design specifications are documented, integrated and preserved in the knowledge base. The knowledge base must be stored in a central location, available (as read only) to all who need to know its contents. Use of the knowledge base enables the business knowledge gained within a single project to be shared and reused by other projects. Effective knowledge coordination improves the effectiveness of each project manager and assures that individual project findings comprise a collective organisational memory over time. Most usually, the central location is a specific local area network domain set aside specifically for the purpose of accumulating and integrating the organisation‟s total knowledge. Elements of the knowledge base are described as objects. Objects include entities that are elements of the business process (lecturer, tutor, student, lecture room, etc), outputs (including forms, letters, screen layouts, etc), critical success factors and organisational units. All deliverables are described in terms of the knowledge base objects that comprise them. Iterative performance and analysis of tasks and activities are used to refine the information in the knowledge base. Knowledge coordination is critical to ensure smooth translation of models between project phases. Refer Appendix A for details of data modelling techniques.

Page 14 of 94

8 Project Charter The Project Charter is essential to ensure user involvement and understanding, particularly because the Charter must:   

Document the agreement between the project sponsor and the project manager; Provide a clear statement of the purpose of the project and what is to be delivered by it; Define the project roles and responsibilities.

Refer Appendix B for the format of a Project Charter. A Project Charter is the blueprint of a project; it constitutes the foundations upon which the project will proceed. If the Project Charter does not achieve the objectives stated above, then the project will most probably fail, simply because the criteria for success are not described accurately and there is no common understanding of what constitutes success. The Project Charter is not a static document. It needs to be updated as, if and when the project scope changes, when staff assigned to the project change, when stakeholders change, when budget variances occur, etc. The Project Manager must treat the Project Charter seriously and exert all efforts to achieve the commitments within the Project Charter. An effective Project Charter requires that the business needs be understood to the appropriate level of detail, which necessitates comprehensive needs analysis (functional specification). In many ways, business needs analysis (business process mapping) is the hardest part of the development (or configuration) of a computer application. This arises because the analyst is the “middle man”, trying to serve both the user community and IT&T staff. Finding solutions that will satisfy both parties is inevitably difficult, because there will often be conflicting interests and priorities, and communication difficulties between the business and the “technologists”. Surveys over three decades have indicated that approximately 70% of total computer system costs are incurred in maintenance and modification of the original implementation. This results from, primarily, two related aspects of business systems development: 1. The system design (base functionality and configuration in the case of packaged systems) does not end up reflecting the users‟ functional requirements. 2. It is difficult and costly to alter system logic after the original design has been implemented. There is a big difference between business analysis and business systems design, one that is often blurred to the disadvantage of all parties. An analyst must be objective in determining the optimum business process, not be constrained by pre-determined ideas or advice as to the business system‟s functionality. Business system design must be based on the business process analysis. It is at this point that any discrepancies between what the business needs and what the business system software can deliver will be identified. Narrative is a very ineffective way of trying to ensure a clear understanding of the business requirements, as reflected in the optimal business processes.

Page 15 of 94

To design and install cost-effective business systems that meet the needs of the user base, those needs must be completely and reliably met by functionally rich and robust solutions. In all instances, the end user must be provided with:  

A functional specification (needs analysis) of the business system to be developed (or purchased and installed). The functional specification represents the essential activities which must be performed, whether they can be computerised or not. The functional specification should set out, clearly, the logical requirements of the business system, without including so much information that it verges on a technical specification and becomes unintelligible to the business users/process owners. It is essential that the functional specification be understood by the end-user/process owner, so that he/she can: o



Agree, and sign off to the effect that, the functional specification meets his/her/their business process functional requirements (and that any compromises or trade-offs in functionality have his/her/their assent)

The functional specification should make it clear what options are available to meet the business needs, and what trade-offs may be required (for other than essential functions).

An effective functional specification can only be prepared on the basis of a clear understanding of the business processes that the business systems application is being developed (or installed and configured) to support. Business process mapping is, therefore, the first and most essential step in business systems development or re-design.

9 Business Process Mapping 9.1

Fact finding and recording techniques

It is essential in business systems analysis not to overlook sources of valuable background information relevant to the business process being analysed. What is relevant will be determined by how well the objectives of the analysis have been defined. A high level preliminary review, preceding detailed analysis, will often facilitate the information gathering exercise. Normally, useful background information can be obtained from: 

Organisation charts and Policy manuals If these are unavailable or out-of-date, the current organisation structure or policies need to be determined. The analyst needs to understand the constraints that may apply to changing any process.



Operating instructions and/or Procedural documentation Again, these may be out-of-date, but will act as a guide. Even when current, they are a guide to understanding the present process, rather than a constraint on improving them. It is important to understand the reason behind any obvious inefficiency in the current process.



Previous reports, Minutes of meetings, correspondence Ask people who have been around long enough to know (and preferably, who appear to be unbiased in the process analysis). Page 16 of 94



Personal conversations Be aware of the person who may have been closely involved with the process/processes under review in the past, who may now be in another department, school or faculty. Identify the key people who interact with the process or system being analysed, particularly indirect users.

By identifying and researching as much background information as practical within the time available, the person conducting the analysis of the business process:     

Will be sure of the information he/she requires, and from whom it can be obtained Can anticipate likely opposition and obstruction Can prepare well for interviews, deal with uncooperative people, and more readily distinguish facts from opinions Be able to complete interviews more quickly Begin to understand the real motives for the study being undertaken: o o

Why this process and not some other? What does senior/executive management expect to get from the analysis?

9.2 Charting Charting is the principle documentation approach within business analysis. Charting has five main uses:     

Fact finding Analysis Design Presentation Implementation

In regard to fact finding, an effective and comprehensive chart of the process is the way in which the analyst will know and understand the existing process, including:      

Who What Where When Why How

The chart of the existing process (or system) will set the direction for further analysis and for improvement. It is important to chart at the highest level first, then to “drill down” to more detailed levels as, if and when the need for such becomes apparent (as it inevitably will in the context of proposed automation of business processes).

Similarly, charting of the design of the new (or possible alternative) process, in the context of the chart of the existing system, will reveal the complexity of the new (or possible alternative) system and, particularly, the extent to which it varies from the existing system. Page 17 of 94

Charts are very effective presentation tools (“a picture is worth a thousand words”), as they:     

Obviate long narratives which may not make the flow of work obvious Provide succinct and compact guidance as the functional flow of the process Facilitate checking of correctness with functional operatives within the business areas Assist identification and analysis of gaps, bottlenecks, inefficiencies and opportunities for improvements Facilitate comparison between current and proposed processes

Accurate charts also form the basis for functional specifications of IT&T systems and for training of functional operatives and information technology system users. Charting must take account of:    

The type of process being analysed The level of detail required in the analysis The purpose to which the chart is to be put The use of the charts in presentations; they may become the key to convincing management to support the change (and approve the costs of making the change)

It‟s important to note that all business process analysis and improvement depends to some degree on trial and error (“iterative analysis”). Effective business process mapping helps to identify:     

The sub-processes and steps within the process being analysed The purpose for which the business process exists (outputs) The resources required to achieve the purpose of the business process (inputs) The existence (or not) of controls that ensure accuracy, reliability, maintainability, timeliness, audit ability, etc. The interdependencies and interfaces of the business process being analysed.

9.2.1

Types of Charts

9.2.1.1 Information Flow Charts     

Operational/procedural flow process charts/maps Schematic flow charts, diagrams or maps Form flow chart Forms routing charts Computer logic charts

Page 18 of 94

9.2.1.2 Special Purpose Charts    

GANTT1 or BAR charts (Project Planning) PERT2 network charts (Project Planning) FAST3 diagrams DFD (data flow diagram)

9.2.1

Entity Relationship Diagram

This is a diagram used to show how various entities (elements of the process) are related to each other. The following chart provides an example of an entity-relationship diagram in which the relationship between student and course is many, because each student may attend many courses and each course will have many students. The relationship between tutor and course is one to many, because each tutor will teach many courses, but each course will have only one tutor (in this example):

Students

Courses Enrols in

Tutor Taught by

1

The Gantt chart, devised as a charting method by Henry Gantt, is a visual display to represent scheduling which is based on time, rather than quantity, volume or weight. 2

PERT charts: (sometimes called Network Charts or Logic Diagrams) are widely used project management diagrams, used for displaying project schedules depicting tasks and the dependencies between tasks. 3

Function Analysis System Technique

Page 19 of 94

9.2.3

Process Flow Chart

Process Flow Charts are used at ACU National to map the business activities that support the University‟s vision, mission, strategies and operational plans. A Process Flow Chart shows the information and/or activity flow represented by separate forms, records, and other media. It may be presented in either a horizontal or vertical flow, and is especially useful in defining the functional requirements of an information technology application. The conventions and symbols applying to process flow charting are:     

Each horizontal line on the chart represents a discrete information flow (usually a separate paper form in each case) The symbols on each line represent the activities in which that particular information or paper form is involved, or handled The vertical lines indicate the relationship between different forms or records. Where two forms are linked vertically through several operations, it indicates that the same forms are used in multiple operations Information or activity flow is from left to right, or from top to bottom Basic symbols have the following meanings: Activity Something is done to or with the information on the form (or in the computer). The nature of the activity being performed needs to be explained on the chart. A new form or record is created  Information is being added. This is usually associated with a vertical connection, indicating the source from which the information being added is obtained. Indicates a sorting or distribution of copies S

MO

Indicates a machine operation (most usually a computer system; the process map should include a notation as to the computer application to which the information is submitted, or from which the information is obtained. Movement; indicates transfer of a form physically from one point to another; the destination or origin of the move should be notated below the arrow. A decision, inspection, check or review point. No information changes.

Page 20 of 94

9.2.3

Analysis of Process Charts

The business process chart provides the most effective means of eliminating unnecessary work and streamlining business processes, because it provides a detailed description of a particular task or piece of work. There are five key questions that need to be answered to perform an effective analysis: 1. What is being done and why is it necessary? Does each step serve a useful purpose? Does it actually contribute to the end result? An excuse for performing a step is often not a true reason for it being done, often, it will be found to be unnecessary. 2.

What is being done and why should it be done there?

Can it be done more easily in some other step of the process, or in another department? Will a change to where and when it is being done save steps, time and effort? 3. Who is doing the job? Why should he/she do it? Would someone else do it better? Is someone else better qualified or skilled to do the work? Who can do it most easily and most practically? Ensure that high-salaried time is used discriminately, and delegate tasks to lesser-paid employees wherever feasible. 4. When should this step or task be done? Why? Should this step be done earlier or later or combined with some other step? Is it really in its proper sequence in the end-to-end process? By doing it at this time and at this juncture in the end-to-end process, is it really slowing down or holding up another business operation? 5. How is it being done? Why should it be done that way? Is the process too complicated in its present form? Can it be done in an easier way? Should different forms or supplies be used? Can shortcuts be adopted? Is automation feasible? Will automation make it happen faster, more efficiently, with less cost? For many activities there are explicit rules for how activities are done. Rules are of two types - constraints and operational guidance. Constraints define conditions under which an activity cannot be done or conditions under which an activity must be done. In the University environment these are determined primarily by Legislation and statistical reporting requirements and cannot be changed by the University unilaterally. Operational guidance is the University‟s determination of how activities should be done. These can be analysed and changes recommended without reference to external authority. Never overlook the people aspects and cultural issues that will need to be addressed, which include changes in: • Organisational structures: options: specialist/generalist; teams/individuals etc • Job roles: logical grouping of tasks; management roles; how these fit together; skills, capabilities etc. • Reward systems, performance measures and career paths • Training and development • Terms and conditions of employment.

Page 21 of 94

10 Project Management Life Cycle The Project Management Life Cycle is most usually referred to as the System/Software Development Life Cycle (SDLC). The processes shown in green shaded arrows related specifically to projects that are initiated to implement an Information Technology & Telecommunications (IT&T) solution. The other processes apply to all projects, whether IT&T based or not:

User Acceptance testing

Implement

Integration testing

Maintain, Support enhance Identify business need

Unit testing

Establish Framework  Strategies  Policies  Procedures

Analyse and specify requirements

Program coding

Program design

Technical specification

Functional specification

Page 22 of 94

11 Project Initiation Project initiation has the following objectives:           

Identify and document the business need/objectives that the project will address Determine and evaluate alternative ways in which the business need can be met and recommend the best solution Assure and establish sponsorship of the project Define the objective, approach and controls of the project Estimate the project effort, duration and cost Ensure a clear and common understanding of the deliverables that will be produced Specify what work needs to be completed in order to produce the deliverables Determine the type of skills that will be needed to complete the project Estimate how long it will take and what it will cost (once-off and ongoing/capital and operating expenditure) Specify what will constitute completion of the project Obtain appropriate management approval for effort and cost

If a project is part of a larger business program, as well as developing project charters and high-level plans for each individual project, a master project plan will need to be prepared to identify project interdependencies. If the business program consists of a number of sequential, as opposed to concurrent, projects, it may be enough to create the master project plan and a detailed project charter for the first project only. Initiation of a project must be supported by a business case, signed off by the appropriately authorised officers of the University. The business case documents all the information required to make a decision on the merit of a proposed project Preparation of the business case is an essential discipline, in that it requires concepts to be detailed and fully considered. Any flaws in the understanding of the business need or the proposed solution should become apparent during writing of the business case. Retrospective documentation of a business case, documenting work already done, is unacceptable. The business case constitutes the justification for the project. It is designed to gain approval at the appropriate levels of the University to proceed with the project. Formulation of the business case is a response to an identified business need, problem or issue, part of an ongoing strategy for business improvement, a request for increased funding, justification for continuing funding, or consequent upon a seemingly good idea to test the merit of that idea. Option 1 in every evaluation of alternative solutions is “do nothing”. This base case or do nothing scenario is the foundation upon which all benefits from the proposed business process re-engineering (BPR) effort are determined. By documenting everything together in one document, it is easy to link the issues to the solution and the benefit, and identify where the business would be without the BPR project. The development of the overall business case simplifies the development of the financial justification, and will usually identify holes or problems with the solution. Moreover, post implementation review of benefits derived can only be effected when there was an initial projection of such benefits. The business case provides a consistent message to many different audiences. It is a high level view of the entire project and enables all staff and functional units impacted by the project to have a common understanding of the project‟s scope and objectives. Refer Appendix G for a sample Business Case. Page 23 of 94

11.1 Define Project Scope and Objectives Failure to clearly define the scope and objectives of any project is the most common cause of project failure. Project scope and objectives are closely related to the business objectives but represent more specific deliverables so must be expressed in a way that facilitates post implementation review against the original scope and objectives. Effective and comprehensive functional analysis is essential at the outset and relies on appropriate business process analysis. 11.1.1 Project scope The project scope should be expressed as a concise and accurate description of the end deliverables to be expected from the project and that meet specified requirements as agreed between the project‟s stakeholders. It is important to specify exclusions from scope, where misunderstandings are probable. 11.1.2 Project objectives A project‟s objectives are synonymous with “goals”.

11.2 Cost and Benefit Analysis (CBA) Every project competes for limited funds and finite resources. It is therefore essential to analyse the costs versus the benefits of every project so that they can be prioritised and allocated budgets. There are numerous ways to approach a CBA, some of which are: 11.1.1 Discounted cash flow (DCF) This is a method that considers the time value of money. DCF assumes that the value of any given amount of money will be less in the future than in the present or the past. Cash flows in the future are discounted, as opposed to compounded, by a specific discount rate, to convert them to present value. DCF includes Internal Rate of Return (IRR) and Net Present Value (NPV): 11.2.2 Internal Rate of Return (IRR) IRR is method that calculates the rate of return on an investment by finding the discount rate that equates the present value of future cash flows to the cost of the investment. That is, the internal rate of return is defined to be the discount rate that makes the net present value of the cash flows over time equal to zero. Refer to Appendix J for details and examples of how to calculate IRR. 11.2.3 Net Present Value (NPV) NPV is a method for assessing investment proposals in which the value is equal to the present value of future returns, discounted at the cost of capital*, minus the present value of the cost of the investment., As a rule, the higher the NPV, the better the monetary returns are on an investment. Refer to Appendix L for details and examples of how to calculate NPV. *Cost of capital is the discount rate used for project investments evaluations and capital budgeting. It is the opportunity cost of an investment, that being the rate of return that the University would otherwise be able to earn at the same risk level and the investment that is being proposed and subjected to calculation of NPV. The opportunity cost is the value of the next best purpose that the money available could have been used for.

Page 24 of 94

11.2.4 Return on Investment (ROI) ROI is the yield that will manifest as a “profit” from expenditure. ROI is usually expressed as a percentage of the initial investment amount. Refer to Appendix M for details and examples of how to calculate ROI. 11.3

Developing a cost/benefit analysis

The following standards and guidelines need to be determined before a realistic CBA can be developed:      

The cost of capital (discount rate) to be used The recommended investment analysis time line applicable to each of capital and operating expenditure respectively, ascertained from Finance. Cost and benefit categories Treatment of intangible (qualitative) benefits Treatment of taxes, depreciation and consumer price index (CPI) Full absorption cost of labour, by level and skill set, computer time usage, etc.

11.3.1 Identify benefits Work with the project‟s sponsor to identify benefits that will result from implementation of the project. This requires a clear understanding of the project‟s scope and objectives and of the current method of doing the business process addressed by the project. Always start with the expected tangible (quantitative) benefits and document assumptions clearly. Always ensure that it is possible to track and audit tangible benefits. Intangible (qualitative) benefits do not enable actual cost/benefit analysis and are usually only relevant as considerations for a project that is at the margin of being cost justified. It is not always clear whether a benefit is tangible. Tangible benefits, such as reduced staff (which can be recruitment avoided, as opposed to redundancies) and avoidance of rental of extra office space are easy to quantify. Ethereal intangible benefits such as “better decision making support” cannot be quantified.

11.3.2 Identify costs Determine the costs and the intervals at which those costs will be incurred over the life of the project. Consider both direct and indirect costs. An indirect cost will inevitably be the organisational change impacts, including the temporary reduction in productivity while users are familiarised with the new system and while they are seconded to the actual project team. Costs will vary depending on the staffing approaches and the supporting technology (if applicable). Operating leases will vary the scheduling of capital costs compared to outright purchase. 11.3.3 Develop the project cash flow schedule Determine the timeframe over which the cost of the project is to be amortised (usually three to five years). Allocate the anticipated costs and benefits monthly across the timeframe.

Page 25 of 94

12 Project Planning Project planning is an iterative and ongoing process. Detailed plans must be revised as necessary throughout the life of the project. When planning a project, the project manager must confirm and build on the business case developed during the project initiation phase to prepare an appropriately detailed project charter. The project manager is responsible to create the project plan. The detailed project plan is used to document deliverables and to achieve the project objectives detailed in the project charter. Project plans should include:        

task schedules, being project specific detailed work plans, resource schedules, quality management and review plans, a risk management plan, a communications plan, an issue management plan, a scope management plan, and a detailed budget addressing all aspects of the project and its management

When preparing the detailed work plans, the project manager must ensure consideration of:   

task dependencies task and resource scheduling addition of any new tasks manifested as the project progresses (assuring also that the scope of the project is closely managed and changes to that scope are documented thoroughly).

Project plans must be reviewed regularly to identify any slippage from original delivery dates, to implement corrective measures and to evaluate the flow on effect on the project schedule overall. The master project plan and all subsidiary plans must include milestones. Milestones will usually be the completion of project stages. Resource constraints, quality issues and project risks need to be factored into the milestone plan. Each task within a project plan has a narrative description sufficient to communicate:   

What is to be achieved/delivered; The steps involved in achieving the deliverable; The completion criteria of each deliverable.

Maintaining and tracking a detailed project plan is impractical if done manually. ACU uses Microsoft‟s Project Plan software to create and maintain project plans. There is some overlap between initiation, establishment and planning of a project. Generally, details from the business case, created during project initiation, will be carried forward into the project charter created during the establishment phase and the project charter may be modified when detailed plans are created. The high level project schedule in the project charter will be to an activity level, whereas the actual detailed plans will be at a task level. Similarly, the high level plan, on which the budget is based, will show skill types needed, whereas the detailed plans will show particular staff‟s names. Page 26 of 94

During the planning process, it is essential to recognise that some or all of the project team, and potentially some of the extended stakeholder team, will need training. Determine the type and duration of training required and include that training in the detailed project plan. The most common time based techniques for displaying project plans are shown below; the Gantt Chart is the default display option within Microsoft Project, so is used most often at ACU National.   

CPA – critical path analysis (refer Appendix C) PERT – program evaluation and review technique (refer Appendix D) Gantt Chart - A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist (refer Appendix E)

A project plan has many uses, not only as a schedule to manage the timeliness, sequence and interdependency of tasks, but as a tool to assure clear communications.

12.1 Change Management Plan A change management plan must be prepared in conjunction with the project plan, to ensure that user training and procedural documentation are available at appropriate junctures. Change management is the mechanism through which a change to a process or system in the University is initiated, assessed and implemented. Any change to a process or system will involve resources to make the change and have the potential to impact on other parts of the overall process or system. Only when the change is assessed in relation to its overall impact on the University can an informed decision be made as to the merit of the proposed change.

13 Project organisation A project team is brought together for a pre-determined period of time to achieve a specific set of objectives. The project organisation chart must be augmented by role definitions and assignment of responsibilities for each member of the team. It is essential that the project team be given sufficient authority to achieve the project‟s objectives. Some of the factors that influence the perception and effectiveness of the project team include:    

The active and visible support and sponsorship of most senior management and the project sponsor The reputation and credibility of the particular individuals assigned to the project team The strength of the working and reporting relationships within the team The organisational culture in which the project team will function

The first appointment within any project team will be the project manager. If more than six people need to report to the project manager, then consideration should be given to assigning team leaders for identifiable modules of the project, through whom other team members will report.

Page 27 of 94

Roles in the overall project organisation will typically include:

13.1 Executive Sponsor This is the person who has ultimate authority over the project and is ultimately accountable for its success. The executive sponsor:  has control of the budget,  resolves otherwise irreconcilable conflicts in the course of the project,  provides high level direction,  approves changes to project scope, including their time and budget impacts. Sometimes, the executive sponsor and the project sponsor will be the same person. Often, the executive sponsor will delegate routine participation in the project to the project sponsor.

13.2 Project Sponsor The Project Sponsor provides the interface between project ownership and delivery. The Project Sponsor is the client side representative who acts as a single focal point of contact with the project manager for the day-to-day management of the interests of the client organisation. The Project Sponsor is responsible for ongoing management on behalf of the project owner to ensure that the desired project objectives are delivered. The person in this role must have adequate knowledge and information about the business and the project to be able to make informed decisions. They may be known as the Project Sponsor; sometimes referred to as the Project Director. For smaller/straightforward projects the roles of Project Sponsor and Project Manager may be combined, subject to the proviso that the person taking on the combined responsibilities possesses the requisite competencies, expertise, experience and has the available time and resources. Where roles are combined, it is essential that delegations and responsibilities are clearly understood and do not overlap with other roles. This role description assumes that the roles of Project Sponsor and Project Manager are separate. The Project Sponsor is responsible for:              

Ensuring an appropriate project or programme management framework is in place, incorporating the Gateway review process if required. Preparing the project brief, Project Initiation Document (or equivalent) and business case Appraising options and submitting for approval Securing resources and expertise from the client organisation as required, for example, appointing professional advisers to support the project sponsor role Co-ordinating and directing end user input Co-ordinating value management strategy Controlling changes following approval Determining and managing risks to the project Managing the project budget, including risk allowance Acting as sole point of contact with project manager Co-ordinating and fostering teamwork Managing the project manager‟s performance of delegated responsibility Establishing formal reporting arrangements on project progress Defining criteria for control and management of the project Page 28 of 94

    

Assisting the project manager in the resolution of problems Receiving and reviewing detailed reports on the project from the project manager Ensuring the project manager receives departmental decisions on time Establishing with the project manager a common approach to major issues that arise Establishing a mechanism to ensure regular dialogue with contractors to promote problem solving, team working and risk-sharing

The Project Sponsor should be able to:    

Apply quality management principles and processes Apply risk assessment and management principles and processes Network effectively, negotiate well and influence people, broker relationships with stakeholders within and outside the project Be aware of the broader perspective and how it affects the project.

13.3 Project Manager The Project Manager, operating within agreed reporting structures, is responsible for:                

Designing and applying an appropriate project management framework for the project (using relevant project standards) Managing the production of the required deliverables Planning and monitoring the project Adopting any delegation and use of project assurance roles within agreed reporting structures Preparing and maintaining the Project Plan Manage project risks, including the development of contingency plans Liaison with business programme management (if the project is part of a business programme) and related projects to ensure that work is neither overlooked nor duplicated Overall progress and use of resources, initiating corrective action where necessary Change control and any required configuration management Reporting through agreed reporting lines on project progress through status reports, change request logs and issue logs Liaison with appointed project assurance roles to assure the overall direction and integrity of the project Adopting technical and quality strategy Identifying and obtain any support and advice required for the management, planning and control of the project Managing project administration Preparing a “Lessons Learned” report Preparing any follow-on action recommendations as required

The Project Manager should be able to:       

Apply standard project management approaches to the specific requirements of the project Direct, manage and motivate the project team Develop and maintain an agreed project plan and detailed stage plan(s) Tailor expert knowledge to meet specific circumstances Plan and manage the deployment of resources to meet project milestones Build and sustain effective communications with other roles involved in the project as required Apply quality management principles and process.

Page 29 of 94

14 Scope Management Any additional functionality, deleted functionality, modification of deliverables, etc., as detailed in the project charter, constitutes a change in the project‟s scope. Many projects fail to meet their schedules and their budgets because of “scope creep”. It is essential that any and all changes to scope be managed closely. Such management requires that any request for change be documented, evaluated, tabled and, if approved, scheduled into a revision of the project plan. Scope management:        

Maintains the integrity of the project charter Provides a way to process and record change requests Provides a single point of entry to record and process change requests Enables quick and efficient assessment of change requests Helps to ensure that any requested change is evaluated objectively in the context of its impact on the project overall Enables formal review and approval processes for change requests Provides a basis for routine standard reporting of changes requested Captures historical change information as input to the knowledge base for subsequent projects and for the post implementation review of the affected project.

Each request for change to the scope of the project must be considered and a decision made as to whether it is to be accepted, rejected, or deferred until post-implementation of the original scope. Acceptance of any change will require that the project charter, project plan, project budget and resource requirements be amended. Change requests need to be categorised, as follows, to assist in determining how to deal with them. Mandatory (M) changes are those which are mandated by legislation or statutory reporting requirements. Such changes must always be included into the original implementation schedule. They should not arise, as all such requirements should have been identified during preparation of the project charter. They will arise as the result of internal oversight, or changes to the legislation or government reporting requirements. Essential (E) changes are changes that the University stakeholders consider it impossible to do business without. Again, manifestation of such will be as the result of a failure during the analysis and design leading to the functional specification. Desirable (D) changes are changes that stakeholders advise would facilitate and optimise operations. Almost without exception, these should be deferred from the initial implementation scope and, instead, be scheduled as post-implementation production enhancements. Nice to Have (N2H) changes are changes that, if the University had infinite resources, infinite funds and infinite time, would marginally enhance the implemented solution. They will always be deferred from initial scope, and post-implementation, will always stand behind desirable changes. Most often, N2H are “in our dreams, but not in our lifetimes”.

Page 30 of 94

Any stakeholder of the project may submit a change request. All change requests are to be assigned to the project manager in the first instance. The project manager will then assign one of his/her team members to analyse each request, including a high level cost/benefit analysis. After this preliminary analysis, it is the responsibility of the project sponsor to decide whether the change will be included in the initial implementation, deferred to post-implementation, or rejected. A good scope management process is essential to delivering the commitments documented in the project charter. When changes are rejected, the stakeholder who requested such change is going to need to understand the reasons for that rejection; no-one likes to be told “no”. The request for a change may arise at any time, so the change request process is ongoing throughout the life of the project. It is best to establish a clear schedule for consideration of change requests, at least once a month, and possibly weekly, depending on the duration of the project overall and the deliverables/milestones impacted by the change request.

14.1 Scope creep considerations: 14.1.1 Impact analysis Short term and long term consequences of implementing VS not implementing the requested change need to be considered. 14.1.2 Cost analysis Inevitably, the cost of including additional functionality within the project scope will be outside the original project budget. However, sufficient funds should be provided in the original project budget for resources to spend the time assessing the change requests themselves. Change analysis hours should be included as scheduled and assigned tasks of selected project team members in the original project plan. 14.1.3 Mandatory changes Consistent with the category, mandatory changes must be accepted and included in the project scope. When mandatory changes are identified, the fact that it/they have been identified must be communicated throughout the immediate and extended project team.

Page 31 of 94

15 Project Status Reporting The project status report communicates project progress against project plans. Refer to Appendix H for the format of a Project Status Report. Project Status Reports are distributed to the project sponsor, project team, project steering committee, where applicable, user community and other interested stakeholders. A Project Status Report must be produced no less frequently than monthly, on an agreed date that enables reporting of budget VS actual expenditure for the month to which the Status Report relates. Preparation of a Project Status Report is essential to:   

report the progress of a project towards its objectives, as measured against the project plan evaluate progress, as measured against the success criteria detailed in the project charter report issues to the appropriate stakeholders and seek assistance through escalation, when and as necessary

The purpose of a Status Report is to keep stakeholders informed. The reports must be concise and honest. The level of detail in a report should be consistent with the audience to whom it is sent. The report submitted to executive management/steering committee will be derived from, but be less detailed than, the version provided to the immediate project team. The Project Status Report is also a key mechanism to control the project. As work on the project proceeds, the project manager will use the Project Status Report process to:   

compare actual progress to planned progress use the preceding comparison to determine the overall status of the project recommend or take appropriate actions based on the results of the comparisons

The project manager must be alert to potential or actual problems, look for trends in performance by individuals or groups within the overall team and make good use of the issue log within the Project Status Report as an early warning signal. Every team leader within a project team should submit a formal Project Status Report to the project manager, who will then be kept fully informed and be able to ensure that the overall Project Status Report reflects the project as a whole. When a project runs into problems, controlling that project becomes even more difficult then when all is proceeding to plan. During the project, the project manager may need to take critical decisions on matters such as individual or team performance, user relationships, technical and management issues, project organisation and project schedules. The project manager must maintain a balance between the frequency of formal Status Reporting and the need to respond to issues in a timely manner. Formal control involves procedure, effort and time. Informal control allows quicker response, but involves more uncertainty. Effective project control requires that information is timely and true. In times of difficulty, there is a temptation to tell the user community what they want to hear, and for members of the project team to conceal problems from the project manager. Inevitably, this is counter productive for the project overall. The project manager must analyse project plans scrupulously to identify problems. The overall time spent on the project may appear to be “spot on” to estimates. But, this could be caused because excess hours have been spent on one or more tasks, while others that should have begun have not. Page 32 of 94

The full functionality of Microsoft Project‟s variance analysis tools must be employed to ensure that the project is genuinely on track.

16 Issue Management To avoid having to spend time on problem management, regular monitoring, beyond just the facts as represented in project status reports, needs to be undertaken by the project manager and team leaders. If the project manager is not proactive in monitoring the overall project, then urgent issues will overtake genuinely important ones and the “squeaking gates”, within either the project team or the broader user community, will receive all the attention, while serious issues will arise from lack of attention in the early stages. Maintenance of an up-to-date “to do list” is never more important than in the context of a time driven project. To do lists include items that don‟t warrant inclusion on the overall project plan, but which are the essence of effective time management in any work environment. For projects in particular, the to do list must be reviewed at the start of each day and updated at the end of each day. Outstanding items must be prioritised according to their real importance, not someone else‟s definition of urgency. An effective project manager must ensure that his/her involvement is constant and visible. The best way to do this is to interact with each member of the team daily. A comprehensive round of good mornings, in the context of genuinely meaning “how are things going” is a good discipline to adopt. Similarly, such daily contact with key users is essential too. A good project manager will track and manage use of his/her time very carefully, whether his/her time is charged out or not. Maintenance of such records, by time intervals no less frequent than hourly per day, will identify “time wasters” and excessive administrative overheads that distract from the real work of the project. Each week, the project manager should: 

Collect and collate project actual data, including,    



All details required for project status report (refer Appendix H) All tasks on project plan with scheduled completion dates for the ensuing week All tasks on project plan with past due scheduled completion dates Costs incurred during the preceding week

Team meeting A team meeting should be held every week, on the same day, at the same time, in the same venue. Such a meeting should not exceed one hour. Each attendee is required to:  Have filtered the project plan for their own assigned tasks,  Have prepared an individual status report, inclusive of: o an issue log, o explanations of any past due scheduled dates for their assigned tasks, o proposed remedial actions to complete overdue task/s, o Give a commitment to a revised completion date that takes account of the flow on effects of such delay/s where the task is a prerequisite/predecessor of a subsequent task.

Any and all issues raised must be documented and carried forward to the formal issue register, the format of which is shown at Appendix I. Page 33 of 94

Where any scheduled deliverable has slipped, the project plan must be revised accordingly. Formal Minutes of this weekly meeting must be kept. Usually, the role of Minute taker will rotate through the attendees, excluding the project manager. Alternatively, if the project has been assigned administrative support, the same person will take the Minutes each week. Pursuant to the weekly team meeting, the project manager should meet with the project sponsor to discuss and update the status of open issues and any outstanding change requests. Each month, prepare the comprehensive, collated and complete Project Status Report, in accordance with Appendix H:    

Update the project plan Update the project budget; summarise the actual expenditure compared to the budget for the month by each budget category (capital expenditure, operating expenditure) on the status report, but ensure that the variances are captured to line item before such summary is created. Review and update the issues log Review and update the change request log

When an issue attains amber or red status, it may be considered a problem and requires corrective action. Depending on the impact of a problem, such action may need to be immediate, or scheduled into the project plan for a future date. Any problem constitutes a risk to the success of the project.

Page 34 of 94

17 Risk Management

Likelihood

With reference to AS/NZS 4360:1999 “Risk Management”, the magnitude of risk is assessed according to the following matrix:

Almost Certain (5)

Significant N5

High/ major L5

High/ major M5

Severe (V5)

Severe (E5)

Likely (4)

Moderate N4

Significant L4

High/ major M4

High/ major VH4

Severe E4

Moderate (3)

Low/ trivial N3

Moderate L3

Significant M3

High/ major VH3

High/ major E3

Unlikely (2)

Low/ trivial N2

Low/ trivial L2

Moderate M2

Significant V2

High/ major E2

Rare (1)

Low/ trivial N1

Low/ trivial L1

Low/ trivial M1

Moderate V1

Significant E1

Negligible (N)

Low (L)

Medium (M)

Very High (VH)

Extreme (E)

“Unacceptable” Risk Ratings

Consequence

Risk management requires that risks be determined, assessed, prioritised and controlled. Effective risk management is an ongoing discipline throughout the life of any project. Regular review of the project plan will manifest uncertainties which may constitute risks. Risks are contingencies that may adversely impact the budget, the timeliness of deliverables and, ultimately, the implementation date, or the extent to which the project, upon implementation, actually meets the end-users requirements. Risks which, upon assessment, are determined to be within the red, amber or yellow sectors of the matrix above require preventative measures to be put in place. Categorisation of risks in accordance with the matrix automatically assists prioritisation, as “High/Major” obviously constitutes a greater risk than “Significant”. It will still be necessary to prioritise risks within each of those categories and this requires that the potential consequences be considered. Risks can be mitigated by reducing either the likelihood or the consequence. Likelihood can be reduced by proactive mitigation strategies. Piloting a project implementation in a small self-contained functional area is a standard risk mitigation measure. All mitigation strategies must be assigned to a specific person/role who will be accountable to implement the resolution. This assignee will also be responsible, as the project manager‟s delegate, to monitor the risk, to take appropriate preventative action and to recover from the impact if preventative measures fail. Page 35 of 94

All project risks need to be put into the context of the three standard project measurables; cost, delivery schedule and user satisfaction. Some risks have been shown to be inherent in projects and can be anticipated; others will arise and require action that has not yet been incorporated into the prevailing body of experience. That a project will be late is not a risk, it is the consequence of a risk that has not been managed appropriately. Some generic project risks, derived from prior experiences among project managers, are shown in the table at Appendix J.

Page 36 of 94

18 Communication Management Effective communication within a project environment is the key to not only ensuring that all stakeholders are kept informed of the project‟s progress but the appropriate opportunities are created for them to provide the necessary inputs into the process. Without appropriate channels of communication the project is susceptible to a number of significant risks including:    

misinterpreted objectives – leading to undesired project outcomes incorrect emphasis on priorities with regards to budget, quality and scope management resistance to change – leading to possible problems with the implementation phase decreased momentum or stalling – leading to slippage and lowered quality

To mitigate the risks associated with poor communication it is necessary to include a communications section as part of the Project Plan or create a separate Communications Plan as an attachment outlining the communication strategies that will be used during the course of the project. Before attempting to develop a communication plan the project manager should conduct a stakeholder analysis. This can be as simple as compiling a list of project participants and customer groups, to performing an in-depth analysis producing comprehensive stakeholder profiles. The choice of complexity should be based on the nature and complexity of the project but the most important information that should be gathered includes:      

Name, contact details and their functional role (individual) Group name/description and functional role (group) Project role or interest in project Responsibilities in project Specific requirements already flagged by stakeholder Training needs

Once this process is complete the methods and frequency of communication and interaction can be mapped to each stakeholder and incorporated into the communication plan. Communication during the project can be by various methods, including:       

Project team meetings Steering committee meetings Project status reports User forums and discussion groups Newsletters Training sessions Conferencing and workshops

The communication plan should include the following information:     

A list of stakeholders and the selected methods of communication, the frequency and content for each Roles and responsibilities of staff for each communication noted A strategy for dealing with unscheduled communications Details of mechanisms for stakeholder feedback A strategy for the communication of major issues, risks and changes to the project‟s scope Page 37 of 94

Project communications are essential to the coordination of project tasks and events and as such should be included items in the project schedule. The integration of communication tasks into the schedule will lessen the chances of them being overlooked. The communication plan should be reviewed and changed as needed throughout the project and a number of questions should be asked:     

Is the information being communicated meeting the needs of its intended audience? Is the information presenting the true status of the project? Do all project team members and other stakeholders understand their role and responsibilities? Have all project team members and other stakeholders met their obligations? Has the communication schedule been adhered to?

Communication in a project environment is an ongoing process that is often overlooked. By going through the process of developing plans and strategies the project is more likely to succeed.

A communication plan template has been included in this handbook (see Appendix K)

Page 38 of 94

19 Project completion A project will have been completed successfully when it has met all of the objectives and success criteria detailed in the project charter. A project may also be completed by virtue of being abandoned. Project completion is the point at which the project will be evaluated for addition to the cumulative knowledge base that will help assure the success of future projects. Project acceptance needs to be documented; the following is an example of an appropriate document for sign-off by the project owner/project sponsor and other identified key stakeholders.

PROJECT COMPLETION APPROVAL AND ACCEPTANCE Project Name:

Project Manager:

Date:

Completion statement:

Additional comments:

Approvals (position title/name/signature):

Page 39 of 94

20 APPENDIX A –DATA MODELLING 19.1 Conceptual data modelling Conceptual data modelling is the first stage in the process of top down functional analysis. The aim is to describe the information used by an organisation in a way which is not governed by implementation-level issues and details. It should make it easy to see the overall picture so that non-technical staff can contribute to discussions. A common method of analysis involves identifying: 1. the ENTITIES (persons, places, things etc.) which the organisation has to deal with. 2. the ATTRIBUTES - the items of information which characterise and describe these entities. 3. the RELATIONSHIPS between entities which exist and must be taken into account when processing information. In the abstract, or illustrated by superficial examples, this looks a very simple idea. An explanation may put forward a car as a typical entity, point to make, colour, registration number as obvious attributes, and suggest owning and driving as relationships in which it takes part. But applying the method of analysis to some useful purpose in a working organisation will be difficult, simply because the world does not fit so neatly into boxes. 19.1.1 Entities. 20.1.1.1 Defining In a global data model for a hospital, for example, the entity names employee and patient are likely to occur. In some situations the same individual may be both an employee and a patient; is s/he one entity or two? In such a case it is more accurate to define a fundamental entity such as a person able to take a role in the relationship. Note: the name given to an entity should always be a singular noun descriptive of each item to be stored in it. e.g. student NOT students 20.1.1.2 Composite entities Sometimes an entity may be considered as a single entity or as multiple entities. For example, a firm may have a number of different premises for the delivery of goods or supply of services - multiple entities - but one head office for the payment of accounts - a single entity. Similarly, a single object - e.g. an aeroplane - may be made up of many components. These components have a hierarchical / recursive relationship: e.g. A is made up of B and C which in turn are made up of X, Y and Z. It is impossible to treat such entities at a single level; for example the CAA has rules about the expected life of different aircraft components but these must be related to the flight history (take-offs, landings, flight hours) of the plane in which they are fitted. 20.1.1.3 Aggregates For some applications, e.g. stock control of low cost items, we are not concerned with individuals but with AGGREGATES - e.g. how many cans of baked beans are in the warehouse? It is easy to overlook the fact that a definition refers not to an individual but to a type of object. More problems arise when manufactured objects change status part-way through their lives - a car on an assembly line may be indistinguishable from those immediately before and after it, but it must at some point acquire an individual identity for sale and registration. Page 40 of 94

20.1.1.4 Sub-classification of entities The need for sub-classification of entities arises frequently. For example, a transport pool handles resources which in a global data model might be all classed as vehicles. Although certain attributes and relationships may be common to all vehicles, they are not inter-changeable and for practical purposes must be subdivided into vans, lorries, limousines, etc. each with their own particular characteristics. 20.1.1.5 Physical boundaries It may be difficult to determine the physical boundaries of entities which are identified primarily by geographical location. For example, a motorway is a road which is part of one continuous system; it may, however, be necessary to specify points on the motorway, where one section stops and the next begins. 20.1.1.6 Events So far we have been talking about entities which are fairly tangible objects; however, there are many more that are more abstract, for example a sale or a birth. In terms of the overall model these are events which trigger off processes. Nevertheless, we may wish to count them, attach attributes to them, and relate them to one another, as if they were entities. The more abstract the entity, the more difficult it is to decide whether it should really be classed as an event or a relationship. 20.1.1.7 Messages Similar difficulties occur with entities which exist only as messages within an existing clerical business system. As a piece of paper, a receipt is a tangible object, but it is doubtful whether it should be a first class citizen of a conceptual data model, since in different technological situations its functions could equally well be performed by a notch on a stick or a series of pulses on an electronic document interchange (EDI) network. As these examples indicate, entities are not easy to pin down and compromise is required between a fruitless search for some ultimate truth and a short-term expedient which will break down as soon as it is seriously tested. It is necessary to consider the purpose for which the information is being collected, what sort of questions are likely to be asked and how future developments may require the initial requirements specification to be extended. 19.1.2 Attributes. Attributes are pieces of information ABOUT entities. The analysis must of course identify those which are actually relevant to the proposed application. Attributes will give rise to recorded items of data in the database so it is important that nothing potentially useful is omitted here even though not all may be included later. At this level we need to know such things as: 

attribute name.



the domain from which attribute values are taken.



whether the attribute is part of the entity identifier.



whether it is permanent or time-varying.



whether it is required or optional for the entity.

Page 41 of 94

19.1.2.1

Attribute names.

Names should be explanatory words or phrases; coding and/or abbreviations should be postponed until the implementation level. They should enable users of the data model to see what is being recorded, and identify where the same piece of information occurs in different places (e.g. through a DATA DICTIONARY.) 19.1.2.1

Domains

A DOMAIN is a set of values from which attribute values may be taken. Examples are: dates, sums of money, temperatures, grid references, colours, gradings and nationalities. In one way the more definite we can be here the better - it is more helpful to know that an attribute is a linear measurement than that it is a number - but precise formatting specifications are not required. A date is a date, however it is stored or presented, and the conceptual data model is not the place to specify that it is a six-digit number in the format ddmmyy. On the other hand it will be useful to know the kind of accuracy which may be expected for this attribute - is the measurement to the nearest day, week or year? 19.1.2.2

Identifier attributes.

We must distinguish between attributes which just describe an entity (and perhaps change over time), and those which help to identify it uniquely. This will certainly influence the lower level design. But some care is required. In natural discourse very few things have one unique name or identifying attribute - they are distinguished by a combination e.g. name, address and date of birth for a person. In formal business systems, it is convenient to give unique but arbitrary labels to persons or objects (e.g. National Insurance Number, Vehicle Registration Number) so as to have quicker and easier means of identification. But however convenient such KEYS are at the implementation level they should not be introduced into the conceptual design unless they are already familiar to users of the information, and there is an understandable process for getting from the entity itself to its identifying attribute. 19.1.2.3

Time-varying attributes.

It is important to know which attributes may change their values over time, as they will have to be updated when the system is implemented. It may also be necessary to hold previous values somewhere for AUDITING or the production of HISTORICAL REPORTS. 19.1.2.4

Optional attributes.

Entities may have attributes whose values will sometimes be unknown or irrelevant. This happens with very general entities such as vehicle more often than with those more narrowly defined. A record of which attributes are OPTIONAL or MANDATORY will help when defining general consistency constraints for the data base at lower levels. 19.1.3 Relationships In many applications one external event or process may affect several related entities, requiring the setting of LINKS from one part of the database to another. Important information to be recorded is: 19.1.3.1

Number and type of roles

Like an attribute, a relationship should be named by a word or phrase which explains its function. The same applies to the role names within the relationship, e.g. owner, driver etc. Role names are different from the names of entities forming the relationship: one entity may take on many roles; the same role may be played by different entities. Where a relationship is symmetrical (e.g. 2 roads intersecting) role names are arbitrarily assigned. An important point about a relationship is how many entities participate in it. In practice BINARY RELATIONSHIPS are most convenient for data modelling; however it is by no means the case that all relationships must necessarily be binary in this sense. For example, consider a model built around vehicle Page 42 of 94

manufacturers, types of vehicle and garages. In such a model we may wish to represent the information specified by a TERNARY RELATIONSHIP e.g. 

(Vehicle_Manufacturer, Vehicle_Type, Garage)



Vehicle_Manufacturer supplies Vehicle_Type to Garage.

This ternary relationship is not in general equivalent to the combination of the three binary relationships: 

Vehicle_Manufacturer SUPPLIES Vehicle_Type



Garage SELLS Vehicle_Type



Garage IS SUPPLIED BY Vehicle_Manufacturers

For example the information that: 1. Ford supplies cars to Hills tells us more than the combination: 2. Ford supplies cars 3. Hills sells cars 4. Hills is supplied by Ford Relationships (2), (3) and (4) only tell us that: 

Ford supplies cars to some garage(s)



Hills sells cars supplied by some supplier



Ford supplies some type of vehicle to Hills.

One cannot validly infer (1) from (2), (3) and (4); e.g. it may be that Hills only sells Ford trucks, not cars. The false inference (2, 3, 4) => (1) is sometimes called the connection trap. 19.1.3.2

Degree

Relationships may be: 

ONE-TO-ONE, e.g. Building - Location,



ONE-TO-MANY, e.g. hospital - patient,



MANY-TO-MANY, e.g. Author - Book.



RECURSIVE, e.g. Manager - Employee.

To decide the DEGREE of a relationship one must be clear about whether individuals or types are involved. The relationship (vehicle_manufacturer, vehicle_type) is one-to-many if we are talking about an individual manufacturer, but many-to-many where (vehicle_manufacturer, vehicle_type) are types. Consider also the time dimension - whether the relationship is being recorded at a single point in time or over a period of time. For example, in Britain the legal relationship husband-wife is one to one in the first case, but potentially many to many in the second. Page 43 of 94

19.1.3.3

Optionality

A relationship may be required or optional for either participant, e.g. a piece of property must be owned by a person but not all persons need own a piece of property. 19.1.3.4

Permanence

A relationship may be defined as permanent (e.g. parenthood) or temporary (e.g. ownership or employment). If temporary but required by one of the participants (e.g. ownership) it must be transferable. 19.1.3.5

Dependencies

One relationship may necessarily exclude or imply another, or be excluded or implied by another. Membership of the City University Students Union necessarily implies membership of the University itself. Many of the above constraints will require consistency checks on incoming data. Some database management systems (DBMS) allow such checks to be declared as part of the logical data model so that they are applied automatically whenever the data base is updated.

Page 44 of 94

19.2 Logical Data Modelling Logical data modelling is a graphic-intensive technique that results in a data model representing the definition, characteristics, and relationships of data in a business, technical, or conceptual environment. Its purpose is to describe end-user data to systems and end-user staff. Various methods of data modelling exist, each using a host of conventions and tools. The most popular approach is called the entity-relationship (ER) approach, developed by Peter Chen in the late 1970s. Although a number of authors and tool designers have modified and expanded ER concepts, most still have a strong Chen flavour. Also, with the introduction of CASE tools, the number of diagrammatic conventions that the data modeller must master has increased sharply. 19.2.1 Data Modelling Objects The three types of data objects--entities, attributes, and relationships--are the basic building blocks of modelling: 

Entities are persons, places, or things about which an organization wishes to save information. Employees, States, Orders, and Time Sheets are examples of entities. (As a convention, I capitalize the first letter of entities.)



Attributes are the properties of entities. Attribute examples include Colour, Employment Date, Name, and Tax File Number.



Relationships are verbs that describe how entities relate to each other; for example: 'Customers Buy Products,' 'Employees File Time Sheets,' 'Salespeople Place Orders.' A sentence in this entity-relationship-entity construct is called a "relationship entity pair," which is a fashionable mechanism for representing relationships. Relationship entity pairs are bidirectional. Therefore, 'Customers Buy Products' is the same as 'Products are Bought by Customers.' "Relationship" describes an end-user relationship, not a technical one.

While a number of graphical conventions represent data objects, one convention on which all the different approaches seem to agree is the use of a rectangular box to represent an entity. Relationships are represented by a line. However, for various reasons, including time, space, and laziness, modellers often do not label relationships in both directions. One reason is that it is often unnecessary to label the relationships if the meaning of the relationship is easily understood. 19.2.2 Relationship diagrams The conventional way to show relationships is shown in the following diagram:

Page 45 of 94

Proper procedure is to label all relationships in both directions, as shown in the top figure (plumbers prepare pipes/pipes are prepared by plumbers). However, many modellers place the relationship in a diamond, as shown in the bottom figure (seamen sail ships/ships are sailed by seamen). 19.2.3 Attribute diagrams Attributes are diagrammed in several different ways or not diagrammed at all. Some modellers place attributes in the entity box while others use ovals to hold attribute names:

However, it is common practice not to place attributes on a diagram at all. Simple models, such as those above, are illustrative. In real analysis exercises, an entity may have so many attributes that a diagram becomes unreadable. A more practical approach is to keep attributes out of the data model and in the data dictionary. 19.2.3.1

Type/Occurrence Distinction

Before proceeding, the distinction between an entity type and an entity occurrence or instance needs to be understood (“occurrence" and "instance" being interchangeable.). An entity type represents the class of objects that share a distinguishing factor. An occurrence is a single case or instance of a type. For example, "Detective" is an entity type, while "Sherlock Holmes," "Hercule Poirot," and "Ellery Queen" are entity instances. The distinction between entity type and entity occurrence is the same as the distinction between record type and record occurrence. To say that entity type 'A' relates to entity type 'B' means that one or more occurrences of 'A' are (or can be) related to one or more occurrences of 'B.' If this argument sounds familiar to you, it might be because you studied a similar issue in your college philosophy class. Philosophers have what they call the "type token distinction," where 'Man' can represent the set or 'type' of all men (or women), and 'Socrates' represents a single 'token' or occurrence of that set. Attributes and relationships, like entities, have types and occurrences. The distinction between type and occurrence is important for understanding the data modelling concepts of cardinality and modality, which are the two characteristics of relationships.

Page 46 of 94

19.2.3.2 Membership Class (Connectivity Characteristics) If entity 'A' relates to entity 'B,' knowing more about how the occurrences of 'A' relate to the occurrences of 'B' is important. One concern is the cardinality of the relationship. Cardinality5 is the specification of the number of occurrences of one entity type that can be related to the number of occurrences of another entity type. Cardinality is usually expressed as simply "one" or "many." For example, a husband can have only one wife (in most cultures), while a parent can have many children. Thus, two entities can be related as: 

One-to-one (1:1)--An occurrence of entity 'A' can relate to one and only one occurrence of entity 'B,' and an occurrence of 'B' can relate to only one occurrence of 'A.' For example, a husband can have only one wife, and a wife can have only one husband (at least here in New Jersey).



One-to-many (1:N)--One occurrence of entity 'A' can relate to one or many occurrences of entity 'B,' but an occurrence of 'B' can relate to only one occurrence of 'A.' For example, a mother can have many children, but a child can have only one mother.



Many-to-many (M:N)--An occurrence of entity 'A' can relate to one or more occurrences of 'B,' while an occurrence of 'B' can relate to one or more occurrences of 'A.' For example, an uncle can have many nephews, and a nephew can have many uncles. The most popular way to represent cardinality is to use a bar to express one and a trident (also called a "crow's foot" or "chicken foot") to express many:

5

The term cardinality refers to the number of cardinal (basic) members in a set. Cardinality can be finite (a non-negative integer) or infinite. For example, the cardinality of the set of people in the United States is approximately 270,000,000; the cardinality of the set of integers is infinite. In tables, the number of rows is called the cardinality. In practice, tables always have positive-integer cardinality. The reason for this is simple: tables with no rows, or with a negative number of rows, cannot exist. In theory, however, tables with infinite cardinality can exist. An example is a multiplication table of non-negative integers in which entries are implied for all possible values: 0

1

2

3

..

1

1

2

3

..

2

2

4

6

..

3

3

6

9

..

The concept of cardinality is of interest to set theoreticians because it has been used to demonstrate that some infinite sets are larger than others. The cardinality of the set of real numbers is greater than the cardinality of the set of integers, even though both sets are infinite. The cardinality of the set of integers is called aleph-null or aleph-nought; the cardinality of the set of real numbers is called aleph-one.

Page 47 of 94

However, several other approaches and diagramming conventions exist:

Note that Chen and Reiner use a diamond to represent a relationship, while the Trident approach uses a line. (For a discussion of the Reiner technique, see Reiner et al., "The Data Base Design and Evaluation Workbench [DDEW] Project at CCA." Database Engineering 7(4):10-15, 1985.) The diamond does a better job of representing certain types of relationships, but it is not as good at showing the bi-directionality of relationships. Chen represents cardinality by using a 1, N, or M on the relationship line, while Reiner fills in the diamond. Also, most tools now use the trident to show a cardinality of many, while some give the user a choice of symbols. In contrast to cardinality, the modality of a relationship indicates whether an entity occurrence must participate in a relationship. Cardinality tells you the maximum number of entity occurrences that can participate in a relationship, while modality (also called optionality) tells you the minimum number of occurrences. The modality values are zero if an occurrence is not needed or optional, and one if an entity occurrence is required or mandatory. Take the example of Invoice and Line Item entities: An Invoice occurrence can relate to many Line Items, but a Line Item can relate to only one Invoice. This tells you the cardinality. But is it possible to have a Line Item occurrence not related to an Invoice occurrence? The answer, of course, is no. For a Line Item to exist, it must be linked to an Invoice. Therefore, the relationship is mandatory. The same is true in the other direction. It makes no sense to have an Invoice without a Line Item. The relationship is mandatory in both directions. A bar represents a modality of one, while a circle represents a modality of zero. The following diagram shows relationship entity pair, 'Artists Paint Pictures.':

Because it is impossible to have a picture without an artist, the relationship 'Pictures Are Painted by Artists' is mandatory. However, it is possible to have Artists who are not related to any Pictures (just go into Greenwich Village some Saturday night); therefore, in the other direction, the relationship is optional. When dealing with the modality of a relationship,

Page 48 of 94

modellers usually refer to the "one" end of a one-to-many relationship first. This relationship, then, is mandatory-optional. There may also be optional-optional relationships. For example, the relationship 'Banks Finance Cars' is optional-optional, because you can have a bank that doesn't finance cars, and there are cars that are not financed. Most data modellers use the term "optionality" instead of modality. This is an awkward and unfortunate use of the term because the optionality of a relationship could be either optional or mandatory. While an optional optionality appears redundant, it is not as bad as the seeming contradiction of a mandatory optionality. Modality is a term from modal logic. It is used to distinguish necessary statements (in which truth is necessary or mandatory) from contingent statements (in which truth is conditional or dependent on external conditions). Modality is, in fact, a more accurate, meaningful, and lessconfusing term than optionality. By now you have probably noticed that the bar specifying a cardinality of one can usually be inferred, because a cardinality of zero is impossible. However, the cardinality bar does serve a purpose. Because modellers do not always know the cardinality of a relationship, they must have a way to distinguish not knowing from one. Note that many tool vendors do not require, nor do some allow, a bar for a cardinality of one. In that case, the best practice is to specify the nature of the relationship in the relationship description. 19.2.3.3 Degree Relationships can have any number of entity types associated with them. When an entity type is related to itself, the relationship degree is called unary or recursive. For example, a child can be related to another child through the relationship 'Sibling.': This is a unary, or recursive relationship, that is, an entity type is related to itself

. The most common relationship is the binary relationship that links two entity types. N-ary relationships are those involving more than two entity types, such as 'Customer Buys a Car from a Dealer.':

Page 49 of 94

All data modelling tools support binary relationships, and most support unary relationships, but only a few support n-ary relationships. The reason is that most database management systems (DBMS) support binary relationships only. 19.2.3.4 Attribute Values As with entities and relationships, there are attribute types and attribute occurrences. An attribute value is an instance or occurrence of an attribute type. An attribute value is a characteristic of or fact about an entity occurrence. The fact might be that the entity's Colour is "blue" (the convention is to place attribute values in double quotes) or that the AUTHOR NAME is "Thomas Rowley." Attribute values are what data processing is all about. They form the core of information management and represent the most tangible and least abstract aspects of all data processing. Many data modellers divide the world into data and metadata. Data consists of tangible data values, such as "blue," "French fries," and "mustang." Metadata is data about data. For example, the attribute type Menu Item tells us something about the attribute instance "curried pancakes," while the entity type Employee tells us something about the instances of "employee." These objects are called metadata because they are one step removed from the data. 19.2.3.5 Domains A domain is the set of possible values an attribute type can have. Examples of domains include: dates, text, integers between 200 and 399, real numbers with two decimal places, state abbreviations, and so on. However, while "July 11, 1983" is an acceptable value for Employment Date, "Curried Pancakes" is not. Domains are important because they tell you not only what the acceptable values of an attribute are, but also how to use the attribute. For example, the statement: "Medical Coverage = 'Yes' if Claim Date is greater than or equal to Employment Date and less than or equal to Termination Date" makes sense only if the values for Claim Date, Employment Date, and Termination Date share the same domain. If Claim Date = "May 5, 1987," Employment Date = "July 11, 1983," and Termination Date = "123 South Main Street," the results will be quite unpredictable. Domains can be specific or generic. Generic domains, such as 'integer,' 'text,' or the everpopular 'alphanumeric,' are the easiest to work with, but they're also the least meaningful. Domains such as 'Dates between 1/1/50 and 12/31/94' or 'acceptable Zip codes' are more useful. Domains can also be nested; that is, the scope of one domain can incorporate another. The domain 'Dates between 1/1/50 and 12/31/94' is incorporated in the domain 'Dates,' which, in turn, is incorporated in the domain 'Integers,' and so on. There are three main types of domains: 

A data type is a programming language term that identifies broad domain categories, such as integers, real numbers, and text, as well as the more specific dates, financial numbers, and U.S. dollars.

Page 50 of 94



Ranges, such as dates between 1/1/1950 and 12/31/1967, non-negative values (for example, real numbers between 0 and 4.0), and last names beginning A to J, indicate which values between two end points are acceptable.



Acceptable Values, such as street names, suburbs, post codes and State names are the most specific types of domains. They specify the only values an attribute can have. Thus, the acceptable values for the Gender attribute would be "Male" and "Female." In effect, a domain hierarchy is created with the data type at the highest level and acceptable values at the lowest.

The entity-relationship (ER) approach to logical data modelling does not end here. What has been set forth in this article is just a cursory view of some rather complex notions involved in data modelling. The following figure shows how the topics discussed in this appendix relate to each other.

The preceding article was written by George Tillmann who is a principal with New York-based Booz-Allen & Hamilton's Information Technology Group.

Page 51 of 94

19.3 Physical Data Model6 19.3.1 Overview This section describes the generation of the Data Archive Physical Data Model (PDM), as described by the Infrared Space Observatory (ISO) and should be used to aid further understanding of the detailed descriptions hereinafter. A PDM represents the structure of the data as it will be implemented in the database. The ISO Data Archive PDM was originally generated from the ISO Data Archive Conceptual Data Model (CDM) taken into account the features and physical restrictions of the Data Base Management System (DBMS) which is used to implement the ISO Data Archive PDM. 19.3.2 Generating the Data Archive PDM The ISO Data Archive PDM is generated from the ISO Data Archive CDM by translating conceptual objects into physical objects, as shown below: Object in a CDM

Generated object in a PDM

Attribute Entity Identifier

Column Table Primary or foreign key depending on independent or dependent relationship Reference

Relationship

Independent one-to-many relationships In independent one-to-many relationships, the identifier of the entity on the one side of the relationship becomes a: 

primary key in the table generated by the entity on the one side of the relationship



foreign key in the table generated by the entity on the many side of the relationship.

Dependent one-to-many relationships In dependent relationships, the identifier of the non-dependent entity becomes a primary/foreign key in the table generated by the dependent entity. Independent one-to-one relationships In independent one-to-one relationships, the identifier of one entity migrates as a foreign key to the table generated by the other. Independent many-to-many relationships In independent many-to-many relationships, the identifiers of both entities migrate to a join table as primary/foreign keys.

6

Source of definition is http://www.iso.vilspa.esa.es/ida/pdm/pdmp6.html

Page 52 of 94

19.3.3 ISO Data Archive Physical Data Model – example:

Page 53 of 94

21 APPENDIX B – PROJECT CHARTER FORMAT Substantial information required to be included in the project charter will be extracted directly from the business case upon which approval of the project was based. The project charter brings this information together with other information critical to the project‟s ability to achieve the benefits represented in the business case. The business case, unlike the project charter, is a static document for reference in the post-implementation review to evaluate the success of the project. Section Contents I.

DOCUMENT CONTROL DETAILS  Author  Contributors  Revision Dates and descriptions

II.

DISTRIBUTION LIST

III.

ENDORSEMENTS AND APPROVALS

1.

EXECUTIVE SUMMARY High level summary of the Project Charter for senior management review

2.

KEY STAKEHOLDERS Name and position title of stakeholders in the Project, together with a short description of the strategy that will be used to liaise with those stakeholders to ensure their “buy-in” to the Project.

3.

STATEMENT OF THE BUSINESS REQUIREMENT Explicit definition of the business need being addressed, expressed in terms of the functional area objectives that need to be met.

4.

PROJECT OBJECTIVES The statement of objectives specifies the outcomes sought to meet the business need described in Section 3. Ensure that the project‟s objectives are consistent with the objectives of the University as a whole. It is essential to define the objectives clearly, as their realisation will determine the outcome of the evaluation of success in the post-implementation review. Objectives should follow the “SMART” approach:  Specific  Measurable  Achievable  Realistic  Time-driven

Page 54 of 94

5.

PROJECT SCOPE The scope of the project specifies the activities and defines the boundaries of the work to be done. It identifies the deliverables required to meet the project objectives. This guides the further design of the system and the use of resources in its implementation and operation. The project scope needs to be very specific in describing what will be produced, how long it will take to deliver the specific outcomes, and how much it will cost to deliver those outcomes. It is essential to obtain the approval of the project sponsor to the project scope, otherwise the project cannot succeed. Time, cost and deliverables are inextricably interrelated. If the project sponsor cannot fund the cost, then deliverables will need to be reduced. If an implementation date is mandated that is not achievable with current resources, then extra resources will need to be funded, etc. If the project sponsor does not sign-off on any one of time, cost or deliverables, then the project manager will need to work with the project sponsor to reconcile the scope and objectives and change the project charter accordingly. This can be achieved by any one of:   

6.

making changes to goals, objectives and/or deliverables changing the scope; if the scope seems unachievable within the available time and budget then in all probability it will be and the project will fail, doing more analysis of the underlying baseline assumptions and refining those assumptions.

KEY DELIVERABLES A detailed project plan will not be developed until the project manager begins work in earnest, but this section of the project charter must include a high level summary of that subsequent detailed plan. It is essential to ensure that the list of key project deliverables is complete. Any omission will adversely impact the project cost estimates. Deliverables need to include not only writing programs or implementing revised procedures and processes, but also the time and resources required to convert data from current systems, whether manual or computerised. Each deliverable must be allocated specific completeness and correctness criteria that constitute acceptance criteria for the final product.

7.

MILESTONES & DEPENDENCIES Milestones at specific points in the project, short of completion, need to be identified as check points to evaluate the progress and quality of the project, to avoid waiting until the day before implementation to determine that the project is a failure or success.

Page 55 of 94

8.

INFORMATION AND PERFORMANCE REQUIREMENTS This section details the proposed system‟s requirements, in terms of functionality, accuracy, timeliness, frequency, criticality, etc., that support the project‟s scope and objectives. Management information requirements, including security needs, are stated separately from operational information needs.

• • • • • •

Gather relevant information about the business operations, documents, reports, processes, procedures and business rules that are used to achieve the business objective

If the requirement is for a totally new computer application, then analyse the current system to see whether any of its components warrant retention, as interfaces to the new system. Document the business processes in a process map that represents the business activities that support the end-to-end process. This will enable identification of data flows relevant to the information system. When requirements have been defined fully in the mapping and analysis of the business processes, identify those which are most appropriately handled by a computer application and those that are more effectively and efficiently kept as, or created as, manual systems. Based on analysis of the information gathered, the use to which the information is put needs to be determined, including an analysis of the data that will need to be used to give the required information to the end-user. The systems objectives for the end-user functional requirements can then be documented and ranked in order of importance to the business objectives according to the categories of mandatory, essential, desirable and nice to have. End users will insist on describing their wants, but it‟s essential to ensure all functions are prioritised, which will assist in determining needs:

The objective is to define what the system, whether computer based or manual, is required to do to support the business (i.e. specify its functionality). It is essential to understand the University‟s business processes and business needs. It is inexcusable to contrive to justify purchase of a third party solution then try to manipulate the University‟s business needs and processes to fit it If buying a third party solution, thorough analysis of to what extent the package does not meet the defined business needs, in the form of a gap analysis, is essential. This cannot be done unless the functional analysis and specification (needs analysis) has been documented to an appropriate level of detail to enable a clear gap analysis of any third party solutions.

Page 56 of 94

22 APPENDIX C - Critical Path Analysis (CPA) The critical path is the longest path through the project from start to end. If tasks that are on the critical path are delayed and fail to meet their scheduled delivery date, the end of the project will similarly be delayed. Dupont and Remington Rand devised the Critical Path Analysis technique in the 1950‟s, to standardise the presentation of large projects. It is sometimes also called “critical path method (CPM), or just “arrow network”. CPA is a mathematical model that calculates the earliest possible start and end dates for each task (forward pass), then the latest possible finish and start dates for each task (backward pass). The critical path is, therefore, a sequence of tasks, each of which must finish on schedule for the overall project to finish on time. There can be more than one critical path within an overall project. An example of a CPA is:

Design Packaging

Develop Packaging

Research Market

Package Product

Design Product Produce Product

Once the CPA calculation is finished, the contingency margin in non-critical tasks can be determined. The contingency margin is the amount of time that a task can slip before it affects the end of the project, and, therefore, becomes critical in it. Calculating the critical path The following example shows a project with two distinct paths, A-B-C-E-F and A-B-D-E-F: eks

2 we

A

3 weeks

B

C

3w ee

ks

ks 5 wee

4 weeks

E

3 weeks

F

D The first calculation is the Forward Pass, which determines the Early Start (ES) and Early Finish (EF) dates for each task. This is the earliest possible time that the task can start and finish.

Page 57 of 94

FORWARD PASS BC ES=3 EF=5

A

3 weeks

B

AB ES=0 EF=3

eks 2 we

C

CE ES=5 3 w EF=8 ee ks

5 wee

4 weeks

D BD ES=3 EF=7

ks

E

3 weeks

F

EF ES=12 EF=15

DE ES=7 EF=12

The second calculation is the Backward Pass, which determines, firstly, the Late Start (LS), then the Late Finish (LF) for each task. This is the latest possible time the task can start and finish without adversely impacting the project‟s overall end date: BACKWARD PASS BC ES=3 EF=5 LS=7 LF=9

A

3 weeks AB ES=0 EF=3 LS=0 LF=3

B

eks 2 we

C

5 wee

4 weeks BD ES=3 EF=7 LS=3 LF=7

CE ES=5 EF=8 LS=9 3w ee LF=12 ks

D

ks

DE ES=7 EF=12 LS=7 LF=12

E

3 weeks EF ES=12 EF=15 LS=12 LF=15

F

Upon completion of the forward and backward passes, the critical path, and the contingency margin/s, can be determined. The critical path is shown above in the shaded circles (A-B-D-EF). The critical tasks are those where the early and late dates are the same. The contingency margin available is calculated as: Late Finish – Early Finish = Contingency Margin

Page 58 of 94

23 APPENDIX D - Program Evaluation and Review Technique (PERT) The PERT chart graphically displays tasks as boxes, or nodes, with lines joining them to show dependencies. The PERT chart is sometimes confused with a Critical Path Analysis (CPA). The main difference is in how the PERT method calculates the estimated duration for a task. A traditional PERT chart will also show task relationships accurately by the way the line joins each node/box:

The PERT scheduling method was developed by Lockheed in 1958, for the Special Projects Office of the United States of America‟s navy. The methodology represents project timelines graphically according to the following disciplines:

Finish to Start

Start to Finish

Start to Start

Finish to Finish

Page 59 of 94

A PERT chart will appear as follows (in this instance specifically in Microsoft Project):

Page 60 of 94

24 APPENDIX E - Gantt Chart Henry Gantt developed a bar chart, now called a Gantt Chart, during the First World War. The chart is used to display tasks and durations as bars plotted against a timescale. The “Year Planners” that many of us use in our offices is a derivative of the Gantt Chart. The Gantt Chart is effective because it‟s simple. This advantage will be lost if project managers try to put in too much detail. An example of a Gantt Chart is:

Page 61 of 94

25 APPENDIX F - Work Breakdown Structure (WBS) The WBS is based on the deliverables that the work needs to produce. WBS is a decomposition of the work required to achieve the specific set of deliverables. There are four levels to WBS, each of which produces one or more deliverables or a part of a deliverable:

24.1 Phase The highest level of WBS, below the Project itself, is a phase. Each phase (Initiation, Planning, etc) has its own set of goals and objectives. Each phase produces a set of major deliverables that feed into one or more future phases the overall project plan.

24.2 Stage A stage is the largest logical unit of work within a phase. A stage groups a broad category of related work and serves as the primary mechanism for planning, managing, and tracking project activity at the highest level. In general, a stage produces one or more final deliverables of the project. Stages are the best points to designate as project milestones for peer/third party quality assurance (QA) reviews.

24.3 Activity An activity groups a logical block of work that is smaller and more easily managed than a stage. Generally, an activity produces a draft deliverable, or a part of a deliverable. Activities provide the project manager with formal checkpoints for performing his/her own project quality reviews and other aspects of the project control process.

24.4 Task The lowest level of the work breakdown structure (WBS) is a task. A task generally produces a part of a work product, such as a knowledge base object. A task can typically be assigned to one individual, or to a team leader, and should take no more than 40 work hours of effort to produce. The overall project work plan should be comprised of tasks. The WBS is used to develop the work plan/project plan, but it is not in itself a project plan, since it includes only the tasks that are directed related to the output of deliverables.

Page 62 of 94

26 APPENDIX G - BUSINESS CASE TEMPLATE

BUSINESS CASE PROJECT NAME Prepared by: Contributors: Audience:

Page 63 of 94

TABLE OF CONTENTS Section 1 – Executive Summary To be completed last

Section 2 – Statement of the business issue What is the business issue that has resulted in the need to initiate a project?

Section 3 – Background and Business Drivers What has led to identification of the current business issue? What are the adverse consequences of continuing with the present processes?

Section 4 – Project Scope and Objectives Describe the project and define the project scope from a “process” perspective clearly stating where the process begins, and where the process ends. Describe what is included, and what is not included in the project, including the organisations and functions involved, and list those not involved. Describe those systems included in the project, and those that are not included. Clearly state the project objectives, and the associated conditions of satisfaction (how will success be measured). It is important that this section not only addresses the overall goals, but also defines what success looks like for this project.

Section 5 - Evaluation of Alternative Solutions This section addresses alternative solutions that would meet the business need, to varying levels of effectiveness and cost. Describe the do-nothing scenario, and other alternatives including incremental improvement projects. Alternatives should include selected sub-sets of that solution. Using the information gathered to complete previous sections, it should be possible to develop a number of alternative solutions. 5.1

Option 1 – Do nothing 5.1.1 5.1.2

5.2

Option 2 5.2.1 5.2.2

5.3

Advantages Disadvantages

Option 3 5.3.1 5.3.2

5.4

Advantages Disadvantages

Advantages Disadvantages

Option 4 5.4.1 5.4.2

Advantages Disadvantages

Page 64 of 94

Evaluation Matrix Specific evaluation criteria should be developed to cover functional, technical and economic aspects of each alternative solution, in relation to the specific objectives of the project, as they relate to meeting the business need. Recommendation After applying the evaluation criteria to each alternative, a recommendation should be made and substantiated for the alternative that offers the best functional, technical, economic and timely solution.

Section 6 – Proposed System Description Begin with a narrative description of the proposed process re-design, or new system, supported by high-level flow charts. If applicable, the proposed system should be compared with any current system that it seeks to replace. Technology Requirements A description of any specific technical infrastructure or software needs, or assumptions, including dependencies. System Interfaces Identification of any interfaces, whether manual or automated, with any other existing or proposed systems. Organisational Impact Identification of any existing policies that may be impacted or changes that may affect organisational structures and/or functional area‟s responsibilities. Performance Objectives This section should refer to the performance requirements previously described at Section 8 and describe how they will be measured. This information will also form the basis of the Service Level Agreement to be put in place upon implementation of the system.

Section 7 – Economic Justification Cost/Benefit analysis (CBA) and budgeted cash flow analysis Refer Appendices K, L and M. This section of the business case describes the costs associated with implementing the recommended solution: Implementation costs List all “once-off” costs associated with training, systems development (if applicable), form design, stationery costs (including cost of stationery on hand that will be discarded consequent upon implementation of the new system), lost productivity, Page 65 of 94

change management, capital equipment ( both new, and “sunk cost” of any capital equipment displaced if not fully depreciated), premises, consultancy or contract support, etc. Recurring costs Describe and quantify any and all costs that will recur year after year to maintain the recommended solution over the projected life of the new system. Benefits This section describes the quantitative benefits associated with the recommended solution. It is important that the benefits link back to the situational assessment and the key business drivers that led to the project being initiated. Operational savings This section describes all cost savings, or costs avoided, associated with the realisation of the proposed project‟s objectives.

Section 8 – Implementation timeline Describe the high level project timeline with key milestones and project checkpoints. The project timeline should reflect key steps in the approach and include major decision making milestones.

Section 9 – Project structure Describe the resulting sub-projects that stem from the overall solution. Sub-projects may be separated by process, systems and tools, organisational changes, training needs or other drivers. At this stage, the project structure does not address individual staff names, but specifies the skills required and the number of such skilled resources estimated to be needed. If the project resource requirements cannot be met within current staffing, ensure that any and all estimated incremental staff costs, including back-filling if staff are to be seconded to the project, are taken into the economic justification section. This section provides the framework for more detailed specifications in the project plan and also some information on resource requirements for those to be involved in the implementation:

Section 10 – Critical Assumptions and Risk Assessment This section provides information about any assumptions or constraints that are critical to the successful development, implementation and operation of the proposed system and assesses any risks that can be foreseen as possible with the project‟s progress and implementation: Refer to Appendix J for some typical project risks, but ensure that adequate specific thought is given to particular risks to the particular project being initiated. Functional Risk The impact of, or on, any pending or proposed system, skills and resources required in Page 66 of 94

faculties, schools, ITCS, application development teams, training resources and dependencies on external suppliers. Technical Risk Level of experience, degree of complexity, magnitude of effort, time constraints for implementation. Economic Risk Possibility and consequence of not achieving expected benefits, ease of measurement of those benefits, quality of estimating assumptions, and availability of ongoing funding. Security, Privacy and Audit Considerations Security aspects required, privacy and confidentiality of information being processed, audit requirements of the proposed system. Business Continuity Measures High-level descriptions of alternatives available to continue to meet the mandatory functionality of the proposed system in the event that any supporting resource becomes unavailable. These measures should be addressed in terms of the Standards Association of Australia‟s Business Continuity Management Guideline.

Section 11 – Conclusions and Recommendations State the conclusions the reader should draw from the business case, and recommendations for the next steps. Iterate key themes from each major section of the case as part of the executive summary and closing.

Section 12 - References & Related Documents Document

Date

Page 67 of 94

27 APPENDIX H – Project Status Report format Distribution (position titles)

ACTIVITIES DURING THIS PERIOD PROPOSED WORK FOR NEXT MONTH Action required by (date)

Matters Requiring Action

Action required by (person)

Progress against Budget – Month to nn/nn 200x Original Budget Cost to date Revised Budget $

$

CONTRACT RESOURCE

# DAYS

Progress against Project milestones Task

$

Budget remaining $

DAILY RATE

COST

Scheduled completion date

Project completion

Page 68 of 94

Status at date

Revised completion date

Actual completion date

ISSUE LOG Participant

Priority *

Issue

Status / Actions

By Whom

By When

*Priority categories:

RED Roadblock, potential to stop/severely hinder progress

AMBER Significant/potential problems – needs addressing now



GREEN Not critical yet – raised for awareness, to ensure covered

RESOURCE CONSTRAINTS Resource

Absence

Reason for absence

Page 69 of 94

Project Impact

Remedial Action

28 APPENDIX I - Issue Log format Issue No Sub-project element

Summary description of issue

7

Mandatory, Essential, Desirable or Nice to Have (N2H) Member of project team 9 Open, Active, Deferred, Closed 8

Page 70 of 94

Priority

7

Assigned 8 To

Status

9

Scheduled completion date

Actual completion date

29 APPENDIX J – Risk Management Schedule Risk Functional specifications not clearly stated

L

10

C

11

Impact No specific success criteria; disparate expectations among user base resulting in dissatisfaction upon implementation. Quality assurance reviews will return unfavourable reports.

Project management structure not defined and agreed

Confusion in the project as to roles and responsibilities, leading to a potential lack of decision making.

Insufficient resources assigned to make timely implementation possible

Project can not be implemented on the agreed date

Vendor consultants do not have adequate experience to add necessary value to the project

Will impact the implementation date and potentially could have serious ramifications if inappropriate configuration settings are defined Conflicting priorities for the project team resources will impact the delivery date.

Backfilling of key business users is not planned for

10 11

L = Likelihood C= Consequence

Page 71 of 94

Mitigation strategy Clearly document functionality to be delivered. Ensure that the functional specification is signed off by every key stakeholder. Document specific success criteria and have them signed off, particularly by the project sponsor. Ensure that not quality assurance review delivers any surprises, be sure to communicate the acceptance criteria for each deliverable, as well as the project overall. Be very alert to any attempt to modify the scope of the original functional specification; maintain the change log scrupulously. Define the project management structure in the project charter. This must cover the various roles within the management structure and their level of responsibility. The project MUST have a nominated Project Sponsor who is the ultimate decision making authority. The project should also have a steering committee comprised of the key stakeholders. Develop the project plan as part of the project charter. Identify as many of the significant tasks of the project as possible and estimate the resources required. Negotiate ability to reject any proposed candidate on the basis of their experience or performance on the project.

Develop a detailed project plan as part of the project charter and identify any resource constraints. Ensure that a strategy to support the project team members is in place.

Risk To many part time resources on the project Key business stakeholders not identified

Critical path through the project needs to be identified and maintained

Decision making process is not clear

L

10

C

11

Impact Tasks can not be completed in time due to conflicting priorities The project will have negligible support from the end-users, causing difficulties in operational running Without a critical path identified the project team members may be working on less critical tasks without being aware of the impact. Critical decisions are not resolved in a timely manner and impact the implementation date

Technology infrastructure is not available to support a particular phase of the project.

Delays to the project that could impact the implementation date

Lack of facilities to support the project team

Project is delayed at the start.

Documentation not managed in any structured fashion

Difficult for the project team to access information easily

A third party package is implemented without the support of business groups

There is little user acceptance of the package and difficulties in operational running.

Page 72 of 94

Mitigation strategy Try to avoid any and all part time assignments to the project team. Ensure that the key business users are identified and endorse the project charter.

The project plan must identify the critical path and ensure that this is maintained through the life of the project.

Develop and maintain an issues register. The register forms part of the overall management structure and options for outstanding issues will be brought before the steering committee meetings for resolution. Ensure that all required elements of the infrastructure environment are acquired/established early in the project and that the production environment is available for acceptance testing of the design. Environments for development, testing, training and production need to be set up early in the project and procedures implemented that ensure that all of the environments are robust. Ensure that accommodation and support services, including telephones and desktop computers, are available for the project team. . Set up a documentation directory structure that provides for simple shared access. Ensure that a defined nomenclature is used to categorise documents. Establish a reference group as one element of a communication strategy that will enable the affected functional units to be informed of the progress of the project.

Risk Customisations are required in the package to perform critical business requirements

L

10

C

11

Impact Implementation is delayed or significant business workarounds have to be implemented.

Substantial new reporting is identified to support current business processing

Project is unable to deliver the required reporting by the implementation date and the cost of report development has an adverse effect on the project budget

Lack of available skilled business resources in the project‟s initiation and design.

The quality of the design suffers. Existing business practices are not well understood and the capacity to implement changed practices not explored. When the application goes into production there is significant user resistance to the package.

Substantial business process re-engineering is adopted without reference to the impact within the business environment

Design is overly complex

Issues are hard to uncover and end-to-end testing is complex putting pressure on achieving the implementation date.

Page 73 of 94

Mitigation strategy Use the application design phase of the project to identify any significant business issues. Work closely with the business to look for alternatives to the proposed customisations. Try to find ways of configuring the system to give the desired results. Work with the business users to determine how on-line queries and standard reports can be used in conjunction to run the business. Evaluate the implementation of changed business practices to also reduce the reliance on „existing‟ business reports. Resist the compulsion to develop more reports for day 1 processing and request the user base to evaluate existing enquires and reporting before requesting additional functions. Be mindful that some existing reports will be used heavily by the business and it will require business expertise to design new business management techniques in the new package environment Ensure that the business is committed to the project through the charter process and that the project is a key priority of the identified business resources

Get stakeholders commitment to the BPR processes. Implement, if possible, parts of the revised business process prior to the implementation of the package. Ensure that key business users (and champions of the application within the business) are part of the user acceptance team. Identify issues early. Make business processes as easy to understand as possible. If there are complex workflows to implement then consider the potential of implementing these in phase 2 of the project.

Risk Design does not reflect business requirements

Project team spends excessive time on non critical business processes

Business process design changes the dynamics of data capture and processing

Pre-printed stationery not available in time for “golive”

L

10

C

11

Impact Implementation does not support required business processing and alternative systems and procedures are necessary to support the business. Some key business processes are not supported at implementation time causing problems Some business areas will not feel that they have adequate resources to support the change in business practice Unable to produce anything requiring preprinted stationery

Design does not pay sufficient attention to the complete business process but concentrates primarily on the application aspects

Although the business process works in theory it breaks down when it is tested in the field

Size of the task is underestimated

Potential to delay the implementation date if key data can not be transferred in time.

Quality of the data is poor

More data cleansing and decision making is required to ensure project timelines are met May impact the ability to achieve the implementation date

Volume of data

Page 74 of 94

Mitigation strategy Ensure that the application design process produces a design that is understandable by the business users. It also needs to be signed of by the key business stakeholders Prioritise the functionality to be provided in the application. Identify those „must have‟ items and ensure the project plan delivers those for the implementation date. Identify issues of concern and raise these through the Faculty reference group.

Agree on all output formats in the design process; wherever possible, include stationery formats in actual documents produced by the system. Ensure that a walkthrough of the end-to-end business process is undertaken with the specialist staff. Map data capture from input to output as part of functional design. Identify all data sources required to support the new environment. In the case of multiple data sources estimate the degree of data cleansing and consolidation required. Ensure that the data migration tasks are started as soon as possible in the project plan. Identify data quality issues as soon as possible after the commencement of the project Data loading may have to consider a phased approach. Key data to support daily business transactions first followed by historical data.

Risk Reliability of the development environment is poor

L

10

C

11

Impact Delays the project. Frustrates the project team. The loss of an environment due to hardware or software corruption could have a significant impact on the project.

Poor management control of the various application environments

Loss of progress due to having to recover previous environments

Vendor experiences package problems

If the problems are severe it may impact the implementation date. The more problems that are identified in testing, the longer the implementation phase will be, Functionality will be impaired and systems to which interfaces are required (in or out) will cease to provide correct results.

Not all interfaces are identified

Testing of interfaces can be difficult and time consuming

Potential data errors will occur due to the particular condition having not been tested in the acceptance testing phase.

Page 75 of 94

Mitigation strategy Set up the development environment as soon as possible after project commencement. Ensure that a backup strategy is in place that allows the project team to return to a prior development without substantial outage time. Put in place the procedures to request a special backup to enable the capturing of an environment post a significant event (for example a data load). Implement a set of processes to deal with the development and migration of functionality from the development to test and then production. Develop and maintain an issue log.

Make sure that all of the business areas are aware of the fact that the existing systems will cease to operate from the implementation date. Depending on the degree of difficulty, change all output reports from the HR system and Finance system to say „will not be available from 99 XXX 99‟ to alert people that the reports will not be produced. Request that all system owners which feed the HR or Finance system provide details of the existing interface. Develop an interface map to depict all known interfaces. Ensure there is adequate support after implementation to deal with errors that arise out of the system interfaces. Encourage as much end to end and variance testing in the user acceptance testing period as possible. End to end testing of bank tapes etc could involve a number of test runs.

Risk Insufficient training provided to project team and/or users

L

10

C

11

Impact Project team and users ineffective in using the application and may develop a negative attitude

Key business users not made available for testing

Application is implemented but key business problems have not been identified.

Not enough business cycles or end-to-end testing is performed

Although application performs most functions correctly the integrity and accuracy of data has not been sufficiently verified

Acceptance testing is performed with user profiles that have global privileges

Problems can arise at package implementation occurs.

Transaction response times do not meet objectives

Users unable to use the system as they expected to.

Organisation does not handle the change process well

Perception within the user base that they have received little benefit from the introduction of the application.

Page 76 of 94

Mitigation strategy Develop an appropriate training strategy that covers the project team and their requirement to be trained in the packages functionality. User training needs to consider a train the trainer approach or direct training of the end user in key business functionality. As part of the marketing and training approach identify process champions within the business areas. Ensure that acceptance testing is on the plan with business users identified. Resist the pressure to limit the amount of user acceptance testing due to unavailability of resources or lack of time. Estimate a realistic amount of time to the user acceptance testing. Develop a testing strategy in the design phase of the project to ensure that as many aspects of the design are verified. Ensure that the development of the testing strategy as well as the testing is included in the project plan. The testing strategy must contain the tests to be conducted with the expected results. Acceptance testing must be conducted in an environment that mirrors the expected production environment. The user acceptance environment should be able to become the production environment once the final data migration is undertaken. Monitor the situation, particularly through the user acceptance phase. Identify the need for infrastructure upgrades. Ensure volume testing is targeted at maximum throughput times. Ensure that appropriate training is provided throughout the implementation phase of the product. Provide regular reporting to the University user base on the process being undertaken.

Risk Limited skills transfer has occurred to end-user staff

L

10

C

11

Impact Providing a consistent service is difficult and requires the on-going support of external staff or project team members.

Production environment is not stable

Users lose confidence in the new application

Capacity is exceeded soon after production

User performance suffers and ability to process business transaction load may be questioned

Project budget is underestimated

More funding is required or functionality reduced

Excessive overtime worked by project team

Morale will suffer and the quality of work will deteriorate

Lack of teamwork within the project team, both core and extended

Morale will suffer and the quality of work will deteriorate. A crisis mentality will hang over the team most of the time and information will not be shared readily between team members. Dysfunctional groups and cliques will form.

Page 77 of 94

Mitigation strategy Ensure that staff who need to be trained, in what, and when. Do not effect training too early, certainly not “just in time” and do not train all users in all aspects of the system, only what they will need to know. Implement redundancy features within the hardware and software to support a high availability environment Elicit a variety of sources (software vendor, hardware vendor and independent) to provide estimate hardware configuration to support expected volumes. Closely monitor the usage of external resources and provide regular Project Status Reports to the Steering committee. Ensure each member of the project team has the skills appropriate to perform their assigned role, and that there are sufficient staff to meet the scheduled delivery dates, or that the scheduled delivery dates are feasible within the available resources. Ensure that uncontrolled scope creep is not causing the overtime. As above. Also, do not assume that all team members accept the project‟s objectives and understand their role in delivering those objectives. Interpret project goals into clear individual goals for each team member so that they know what is expected of them and how their performance will be evaluated. Wherever possible, align each team member‟s role within the project with their own personal professional goals. Ensure that all key participants have timely access to project information, including status reports, change log, issue log, etc. Informal communications are also very important.

Risk Failure to reach agreement between the project manager and the project sponsor.

L

10

C

11

Impact The project deliverables will never meet the mercurial expectations of the project sponsor. Versions of the detailed plan will change dramatically and the project team will lose focus.

Page 78 of 94

Mitigation strategy Do not allow personal issues to cloud the project‟s objectives. Ensure that the process owner is kept informed.

30 APPENDIX K – Communication Plan Template

Communications Plan Project Details Project Name: Date: Project Owner: Prepared by:

Principal Staff Name Role

Position @ ACU

Document Version Control Version Date Details

Written by

Page 79 of 94

Contact Details

Authorized By

TABLE OF CONTENTS

1. 2. 3 4.

Communications Plan Executive Summary ................................................................ 1 Marketing and Communication Strategies .................................................................. 1 Stakeholder Communications……………………………………………………………….2 Training Strategies ..................................................................................................... 2

Page 80 of 94

1. Communications Plan Executive Summary

2. Marketing and Communication Strategies a. Communicating Major Risks, Issues and Changes

Page 81 of 94

3. Stakeholder Communication

Stakeholders

Method

Message

Timing

Frequency Communicator

4. Training Strategies

Stakeholders

Training Required

Stakeholder1 Stakeholder2 Stakeholder3

Page 82 of 94

Format

Timing

Frequency Trainer

31 APPENDIX L – Internal Rate of Return (IRR) The following extract from a Computerworld article is a good summary of IRR; searching the internet for “internal rate of return” will assist you to fully understand the method as there are many examples of how to calculate it: The internal rate of return (IRR) is the discount rate that results in a net present value of zero for a series of future cash flows. Avoid a project if the IRR is less than the cost of capital or minimum desired rate of return. IRR provides a simple hurdle rate for investment decision-making, but IRR is not as easy to understand as some measures and not as easy to compute. IRR is the flip side of net present value (NPV) and is based on the same principles and the same math. NPV shows the value of a stream of future cash flows discounted back to the present by some percentage that represents the minimum desired rate of return, often your organisation‟s cost of capital. IRR, on the other hand, computes a break-even rate of return. It shows the discount rate below which an investment results in a positive NPV (and should be made) and above which an investment results in a negative NPV (and should be avoided). It's the break-even discount rate, the rate at which the value of cash outflows equals the value of cash inflows. Consider the three scenarios shown below (see table), each involving an initial investment of $1 million. The investment returns $300,000 (undiscounted) per year in each of the five years after the initial investment, for a net return of $500,000. A company evaluating this investment using cash flow discounted at 10% would compute an NPV of $137,000, a decent but not spectacular result. But if the company evaluates the same investment at 15%, the project has a present value of only $6,000, essentially just breaking even, and at 20% the project's present value is negative. The IRR is a fraction of a percentage point above 15%; at that discount percentage, the investment's NPV is zero. IRR is often used as a hurdle rate, a sort of go/no-go investment threshold. Like NPV, IRR doesn't measure the absolute size of the investment or its return. And because of the way the math works, the timing of periods of negative cash flow can affect the value of IRR without accurately reflecting the underlying performance of the investment. IRR can also produce misleading results because, as classically defined, it assumes that the cash returned from an investment is reinvested at the same percentage rate, which may not be realistic.

Page 83 of 94

Internal Rate of Return: What It Looks Like12 Discount rate: 10% Year

Discount rate: 15%

Discount rate: 20%

Cash flow

Factor

Amount

Factor

Amount

Factor

Amount

0

-$1 million

1.000

-$1 million

1.000

-$1 million

1.000

-$1 million

1

+$300,000

0.909

$273,000

0.870

$261,000

0.833

$250,000

2

+$300,000

0.826

$248,000

0.756

$227,000

0.694

$208,000

3

+$300,000

0.751

$225,000

0.658

$197,000

0.579

$174,000

4

+$300,000

0.683

$205,000

0.572

$172,000

0.482

$145,000

5

+$300,000

0.621

$186,000

0.497

$149,000

0.402

$121,000

Total

+$500,000

NPV = +$137,000

NPV = +$6,000

NPV = -$102,000

IRR = slightly more than 15% IRR is often used as a hurdle rate, a sort of go/no-go investment threshold. In this example, there is an initial investment of $1 million, with a net (undiscounted) return of $500,000. The NPV of the $1 million outlay depends on the discount rate, or cost of capital, used to evaluate the investment. The NPV is zero at the IRR, here a fraction of a percentage point above 15%.

12

Source: Computerworld

Page 84 of 94

32 APPENDIX M – Net Present Value (NPV)13 The net present value (NPV) of an investment is the present (discounted) value of future cash inflows minus the present value of the investment and any associated future cash outflows. It's the net result of a multiyear investment expressed in today's dollars. By considering the time value of money, NPV allows consideration of such things as cost of capital, interest rates and investment opportunity costs. It's especially appropriate for long-term projects. But, ranking investments by NPV doesn't compare absolute levels of investment. NPV looks at cash flows, not at profits and losses the way accounting systems do. NPV is highly sensitive to the discount percentage, and that can be tricky to determine. Unlike the more widely used payback period expressed in current values, NPV accounts for the time value of money by expressing future cash flows in terms of their value today. It recognises that money has a cost (interest), so that you would prefer to have $1.00 today to having $1.00 a year from now. If you earn 10% interest on your money, $1.00 today will be worth $1.10 a year from now. Or, turning that around, the "present" value of $1.10 one year out is $1.00. Calculating NPV requires use of a discount rate equal to some minimum desired rate of return. This could be your company's average weighted cost of capital (debt and equity) as computed by your finance department. If capital costs your company 10%, you aren't likely to invest that capital for an 8% return. The discount rate (say, 10%) determines the discount factor for each year (say, .909) that is applied to that year's cash flow to convert it to today's dollars. The discount factor for year n can be computed as: discount factor = 1/(1+i)n, where i is the target rate of return. So at a discount rate of 10% in Year 1, discount factor = 1/(1.1), or .909. Thus, in the earlier example, the present value of $1.10 a year from now is $1.10 x .909, or $1.00. Fortunately, this math is automated in spreadsheet packages. You enter only the undiscounted cash flows, the years in which the flows are expected and some target interest rate. NPV will be calculated by, say, Excel. The chart below compares two projects that a bank could undertake. Each has an initial investment of $1 million and a minimum desired rate of return of 10%. On the basis of absolute (undiscounted) return, the ATM installation is better because it generates $250,000 more cash over the life of the investment. But when the time value of money is considered, the server consolidation project looks slightly better, with an NPV higher by $9,000. Its present value is higher because the returns occur earlier in the project's life. The yearly cash flows from a hotel or entertainment project are net revenues, but for an IT&T project, they generally are cost savings. NPV isn't appropriate for an IT&T project that can't be associated with clearly defined cash flows. NPV is a good "no-go indicator," because you'd normally reject an investment with a negative NPV without further consideration. Those with a positive NPV should then be further measured by other yardsticks.

13

Source = Computerworld

Page 85 of 94

Net Present Value: What It Looks Like14 ATM installation

Server consolidation

Year

Discount factor (at 10%)

Cash flow

Present value of cash flow

Cash flow

Present value of cash flow

0

1.000

-$1 million

-$1 million

-$1 million

-$1 million

1

0.909

+$500,000

+$454,500

+$1 million

+$909,000

2

0.826

+$500,000

+$413,000

+$750,000

+$619,500

3

0.751

+$500,000

+$375,500

+$500,000

+$375,500

4

0.683

+$500,000

+$341,500

5

0.621

+$500,000

+$310,500

Total

+$1.5 million

+$895,000

+$1.25 million

+$904,000

NPV considers the time value of money. In this example, we compare two $1 million projects with a minimum desired rate of return of 10%. On the basis of simple cash flow, the ATM installation looks better because it generates $250,000 more over the life of the investment. But when the time value of money is considered, the server consolidation project looks slightly better, with an NPV higher by $9,000, because the returns occur earlier in the project‟s life.

14

Source Computerworld

Page 86 of 94

33 APPENDIX N – Return on Investment (ROI) The following elaboration of ROI, and example calculation, relates to a proposal for eLearning (electronic learning). However, the methods are identical for all proposals, whether technology is involved or not.

21.1

Introduction

Building a business case that is centred around a quantifiable, reliable, and compelling estimate of the Return on Investment (ROI), is an essential element of any value proposition. The key to producing a credible ROI lies in ascertaining the cost and income impact. This article provides guidelines for quantifying the hard (quantifiable) benefits and soft (qualitative) benefits that are important in developing a complete picture of the total return on investment. In this example, the eLearning solution is expected to deliver a minimum ROI of 400% in the first twelve months versus traditional education and training approaches, when the full business impact is measured. Any ROI analysis should include the following four categories of potential benefits:    

Quantitative cost savings vs. alternative solutions Quantitative revenue/income impacts vs. alternative solutions Qualitative benefits vs. alternatives Qualitative benefits vs. alternatives

This paper defines these benefit categories and provides a primer on the mathematics of the ROI calculation.

21.2

Quantitative (“hard”) Cost Savings

Quantitative cost savings can always be expressed in financial value terms and can be easily estimated or measured. When calculating the total quantifiable cost savings, consider the following factors: 

    

Travel Traditional instructor-led training (ILT) requires personnel to travel to one central location. The hard travel savings are easy to calculate. Take the sum of airfare, hotel, meals, car rental, etc. and multiply by the headcount number. In many cases, this alone yields a 400% ROI. Facilities (cost of renting premises to conduct training, electricity, overhead projector purchase and/or depreciation, floor space cost, etc.) Instructor fees Printing, distribution and storage costs Repeated training for new staff, refresher courses, content updates, etc. Reduction of customer support costs (the average staff cost per minute for support calls, telephone handset costs avoided, telephone call charges, PABX capacity needs, etc.).

Page 87 of 94

21.3

Quantitative (“hard”) Income/Revenue Impact

Quantitative revenue impact is the total revenue dollar value of the solution that can be estimated or measured. When rolling up hard revenue impact, consider the following factors: 

Increased productivity o



Shorter time to course deployment o



Reducing the time taken to develop and deliver a course expands the duration of its availability; this may lead to increased revenue through being able to deliver the course to more students over the longer delivery period.

Increased revenue opportunities o

21.4

More income-producing days per instructor or other customer facing personnel, such as support staff.

Delivering fee-based training and/or certification to students, and the ability to deliver more revenue-generating courses to more students

Qualitative (“soft”) Benefits

Qualitative benefits are difficult and sometimes impossible to quantify and measure. Most usually, qualitative benefits should not be the prime reason for proceeding with a project proposal. Often, they will be the weighting consideration in an otherwise marginal business case. Sometime, they can be as compelling as quantitative cost savings and strong positive revenue impact. Typically, the business case for any investment starts with ROI calculations based on the quantitative cost savings and income impact. The qualitative benefits are then layered on top of the business case to provide a more complete view of the total return. When developing qualitative benefits, consider the following values:  Immediacy o Since education is treated as an ongoing process and not an event, knowledge transfer is always only a web browser away.  Consistency o Automated, technology-based approaches to large-scale knowledge transfer are inherently more consistent in their delivery than human interaction, which can vary from trainer to trainer and instance to instance.  Certification o Web-based eLearning is a cost-effective medium for certifying knowledge on a large scale.  Closed loop o Course improvement with each iteration 

Lecturers developing courses and adding value elsewhere, not teaching classes

Page 88 of 94



Increased morale gained from simultaneous training o



"We're no longer last on the up here in Malaysia."

Individual Values o



Individual values are benefits that are experienced at the individual learner level. They represent an additional category of soft benefits that should not be ignored in understanding the complete business impact of an eLearning solution. Individual values include:

Timeliness of learning, etc.

21.5

Calculation of Return on Investment (ROI)

Three data points are required: o

The time period over which the ROI is to be calculated (typically one year).

o

The investment. All costs directly attributable to the proposed solution and allocation of appropriate percentages of indirect costs.

o

The return. This is the total of the cost savings and revenue enhancements known, or reasonably estimated, to be gained from the proposed solution.

There are three ways to calculate the ROI: 1.

As a percentage. If you gain benefits equal to $1,000,000 in 12 months on a total investment of $250,000 in the same time period, the ROI can be calculated as follows: Return = Payback - Investment ROI = [(Payback - Investment)/Investment)]*100, in this example: [($1,000,000-$250,000)]/$250,000*100 = 300%

2. As a ratio

Divide the return by the investment. $1,000,000/$250,000 = 4:1 3. As a time to break-even

Determine the number of days, weeks, or months it will take to break even on the investment. Time period to break-even = (Investment/Return)*Time Period ($250,000/$1,000,000)*12 months = (0.25)*12 = 3 months or 90 days

Page 89 of 94

21.6

Conclusion

ROI analysis needs to be used in context of a broader evaluation framework because it is just one of several financial measurement tools that can be used to support an investment decision. You may want to complement your ROI financial measures with other methods that address the key limitations of ROI metrics. For example, ROI does not factor in risk and does a poor job accounting for intangible rewards. ROI is particularly effective at: 

Facilitating investment prioritisation by making hard number comparisons between investment options, allowing decision-makers to focus on the intangible benefits separately.



Setting investment screening thresholds (e.g., consider only projects that deliver an ROI of at least 200%).



Imposing some discipline on the part of vendors and decision-makers to support business impact claims by taking a more methodical and quantifiable approach to business justification.



Enforcing an understanding of the top/bottom line business impact of the investment since it is impossible to complete an ROI analysis without understanding the potential impact on cost and revenue generation.

Page 90 of 94

34 APPENDIX O – Weekly Project Review Meeting Minutes - Format Meeting Date Review the Acme Project Plan

Purpose of Meeting Participants

OUTSTANDING ACTION ITEMS Meeting (Date)

Item #

Assigned to

Description

Status

Scheduled completion date

(initials)

Actual Completion Date

250999

14

AA

To develop a training navigation document template

Open

14/11/99

071099

24 (b)

CC EE FF

What are the environmental problems consequent upon the installation and configuration of the Acme environments and V2.0 of XXX? Requires DD to participate in this action item. She cannot until she completes installation of Project Y

Open

29/11/99

071099

24

DD CC FF

What caused problems? How can ZZZ prevent recurrences? DD unable to prepare detailed report until she completes installation of Project Y.

Open

29/11/99

GG HH/ DD CC FF

Ensure that installation and configuration process is documented fully, so that it becomes a repeatable and easily manageable procedure. DD cannot participate in this documentation until she completes installation of Project Y.

Open

Description

Status

Scheduled completion date

Actual Completion Date

(c) 071099

24

(d)

29/11/99

CLOSED ACTION ITEMS Meeting (Date)

Item #

Assigned to (initials)

230999

1

CC

Review supplier issues regularly with relevant provider and present findings at weekly meeting

Closed

07/10/99

07/10/99

250999

2

CC

Follow-up the status on screen format.

Closed

07/10/99

07/10/99

071099

3

EE

Build product releases and upgrades into schedule

Closed

24/09/99

24/09/99

230999

4

BB

Follow-up with supplier re keeping the old environment. BB to discuss with third party provider

Closed

01/10/99

01/10/99

230999

5

KK

Identify whether test system needs to be a refresh from backup or a full release.

Closed

30/09/99

30/09/99

NEW BUSINESS 

Item 1



Item 2



Item 3 Page 91 of 94

35 APPENDIX P – TESTING INFORMATION TECHNOLOGY APPLICATIONS Terminology15 In IT&T projects, a test is an activity in which a system or component is executed under specified conditions, the results are observed or recorded and an evaluation is made of some aspect of the system or component. The term “testability” is used to describe:  The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met,  The degree to which a requirement is stated in terms that enable establishment of test criteria and performance tests to determine whether those criteria have been met (see measurable). Testing terms and their meanings are contained in the following table: TERM Black-box testing Boundary value analysis

MEANING See functional testing. A test data selection technique in which values are chosen to lie along data extremes. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. The hope is that, if a systems works correctly for these special values then it will work correctly for all values in between.

Cause effect graphing

A testing technique that aids in selecting, in a systematic way, a high-yield set of test cases that logically relates causes to effects to produce test cases. It has a beneficial side effect in pointing out incompleteness and ambiguities in specifications.

Closed-box testing Equivalence class partitioning

See functional testing A software testing technique that involves identifying a small set of representative input values that invoke as many different input conditions as possible.

Error based testing

Testing where information about programming style, error-prone language constructs, and other programming knowledge is applied to select test data capable of detecting faults, either a specified class of faults or all possible faults.

Failure directed testing

Software testing based on the knowledge of the types of errors made in the past that are likely for the system under test. Synonymous with "heuristics testing"

Functional testing

The application of test data derived from the specified functional requirements without regard to the final program structure. Synonymous with "black-box testing" and "closed-box testing"

15

Source = IEEE (Institute of Electrical and Electronics Engineers)

Page 92 of 94

Heuristics testing

See failure directed testing.

Test case

Documentation that specifies inputs, predicted results, and a set of execution conditions for a test item. Synonymous with test case specification. See also test procedure.

Test case generator

A software tool that accepts as input source code, test criteria, specifications, or data structure definitions and uses those inputs to generate test input data and, sometimes, determines expected results. Synonymous with test data generator and test generator.

Test design

Documentation that specifies the details of the test approach for a software feature or combination of software features and identifies the associated tests. Refer also:  Boundary value analysis  Cause effect graphing  Equivalence class partitioning  Error based testing  Functional testing

Test documentation

Documentation that describes plans for, or results of, the testing of a system or component. Types include test case specification, test incident report, test log, test plan, test procedure and test report.

Test driver

A software module used to invoke a module under test and, often, provide test inputs, control and monitor executive, and report test results. Synonymous with test harness.

Test harness

See test driver.

Test incident report

A document that reports on any event that occurs during testing that requires further investigation. See also failure directed testing.

Test log

A chronological record of all relevant details about the execution of a test.

Test phase

The period of time in the software development life cycle (SDLC) in which the components of software (developed or purchased) are evaluated and integrated, and the software is evaluated to determine whether or not requirements (functional specifications) have been satisfied.

Test plan

Documentation that specifies the scope, approach, resources and schedule of intended testing activities. A test plan identifies test items, the features to be tested, the testing tasks, responsibilities, required resources, and any risks requiring contingency planning. See also test design and validation protocol.

Validation protocol

Validation Protocol provides the test scripts and specific guidelines to prove the effective functional use of the software. See test plan.

Page 93 of 94

BIBLIOGRAPHY The Office of Government Commerce, United Kingdom http://www.ogc.gov.uk/sdtoolkit Computer World periodical publications The Data Base Design and Evaluation Workbench [DDEW] Project at CCA." Database Engineering 7(4):10-15, 1985” Intelligent Enterprise periodical publications U.S. Department of Transportation - Volpe Center Logical Data Modelling Infrared Space Observatory http://www.iso.vilspa.esa.es

Page 94 of 94