PROJECT MANAGEMENT HANDBOOK

Version 1.3

April 2007

DOCUMENT CONTROL Author Contributors

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)

File Name Last Edited 26.04.07

Record of Amendments
Date
June 2003 September 2003

Version
1.0 1.1

Changed by
Helen Terese Parks Helen Terese Parks

Description of Changes
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

October 2003 April 2007

1.2 1.3

Helen Terese Parks Sean Connell

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

................3 Time-varying attributes......................................................................................................... 41 19..............................................................................................................................................................................................................................................2 Cost analysis ................ 31 14.....................................................2 Identifier attributes............................3.........................................................................................................1............2 Degree .1.... 40 19....................................................................3 Relationships ..............................................................................2...............................1...................................................................... 37 19 Project completion ..........................................1...........................1..........................................................1 Number and type of roles ................. 41 20....................................................................................................... 44 Page 4 of 94 ....................3 Project Manager .........................................1..........1.........................................................2 Composite entities ..................................................3 Aggregates ..........3........ 27 13..................2...................1 Executive Sponsor ..2....................................................... 42 19..................................... 26 12....4 Sub-classification of entities ...................................1......................................1........................................... 43 19.. 40 20......................1...................1...............5 Physical boundaries .............................................................7 Messages .........3 Develop the project cash flow schedule ..... ............................1......................................................... 40 20.......................3........................................................................................................................................................................................................................................................ 42 19...................1 Impact analysis ............. 42 19..................................................1............................1 Entities....................... ............................................................................................................ ..................................................................................1..........1....................................................................................................................................................... 28 13...................................................................................................................... 32 16 Issue Management ........ 42 19..................................................1........................................................... 27 13 Project organisation ....................................... 40 20.........................................................................1..........................................1..2 Attributes.......... 39 20 APPENDIX A –DATA MODELLING.......... 31 14......... 42 19.....................................................1 Conceptual data modelling ...................................................................................................................................................................................1............................4 Optional attributes............................................... 31 14............................................................................................................ 31 15 Project Status Reporting ...............................3 Optionality.............................................. 35 18 Communication Management .............. 40 20.............................. 29 14 Scope Management .....................................................................................................................................................................................................................................................................2....................................................................................................................................1 Scope creep considerations: ........................1................................................................... 30 14......................................................................................... 41 20.................................................................................2........................................................... 33 17 Risk Management ................1............................................. 25 12 Project Planning ...1................................... ..........................................................................................................................1............1 Domains ...........................................................1 Change Management Plan .............1 Defining ..................................................................................................1.............................................................................................................................2 Project Sponsor ..................3 Mandatory changes ................................................................... ........ 41 19.................................................11.................... 28 13...............................................................................................................................1..........1.............6 Events .............................................................................................1 Attribute names............................................3.............................................................................................................. 42 19.................................1.................. 40 19............................................................................................................................................................................................................................ 42 19......................................................................................... 41 20..........................................1..............................................................................................................................................................................

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

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

Also note that communication should be a key consideration when drafting and disseminating project documentation. Hence.of Post Im ple ment at i on R eview Communication Communication Page 7 of 94 . Because each Project is a self-contained related group of work activities with a specific predefined deliverable.of f f Sig n. Initiation Establishment Planning Control Completion B usiness C ase Pro ject C hart er Pro ject Pro ject Plan Plan Pro ject Pro ject St at us St at us R eport s R eport s A ccept ance A ccept ance Sig n. each of which results in specific documentation (refer Section 3). this Handbook does define a set of documents that must be included in every Project. it provides a consistent framework within which to conduct all the work necessary for the success of each Project. The ACU National Project Management methodology is comprised of five phases. However.1 Overview This Handbook provides a standard framework to guide project management at ACU National. 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. it is not feasible to define every detail of work for every Project within a rigid template.

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.2 Project Establishment Project establishment has the following objectives:     Allocate responsibility. 1. assign the project manager.3 Project Planning Project planning has the following objectives and deliverables:      Confirm all previous assumptions regarding skills required. version control is to be adhered to strictly. including specific tasks. 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. 1. confirm that those resources are available (in-house or by external contract resources).1. specify the project sponsor and establish an appropriate steering committee Identify project team members (according to skill needs identified in the Business Case).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. against which achievements will be measured. milestones and deliverables Refine estimates of task efforts Determine task dependencies Page 8 of 94 . Confirm specific skill requirements. effort and duration. The Business Case forms the baseline benchmark for the post-implementation evaluation of success. Any change to the original Project Charter requires that a new version of the Project Charter be created and promulgated/published. The Business Case is a static document that is never to be changed after sign-off. identify the individuals who will be assigned according to the skill requirements for various tasks and sub-projects Document work breakdown structure. etc. However. approach and controls of the project Estimate the project effort. number of project staff. so that changes can be tracked in the quality assurance process and as input to the post-implementation review.

the initial project plan must be approved and signed-off before the project commences. but no less often than monthly.      Determine external dependencies Determine interface and interaction dependencies Determine milestones that will represent quality assurance checkpoints and their completion dates Schedule the work plan. All stakeholders must sign-off their satisfaction with the project deliverable/s before a project can be deemed to be complete. project sponsor and steering committee Project planning is an iterative and ongoing process. to ensure that any and all variances from that plan are tracked and recorded.5 Project completion is a once-off activity. the project plan is to be base lined. 1. At this point. Project status reports must be completed at intervals agreed in the project planning phase. However. Page 9 of 94 . Project control has the following objectives:  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    1. inclusive of constraints Prepare and review the project plan Submit the initial project plan for approval by the relevant executive sponsor.4 Project Control Project control is ongoing throughout the duration of a project.

Is undertaken within a well defined organisational structure. Is defined by specific objectives (deliverables). comprised of specific deliverables. To be successful. controlled. to enable them to be addressed so that the overall project objectives. Levels of control and monitoring will vary depending on the timeframe and criticality of the project at hand. These include work effort of the project team. Has a single project manager who is responsible for its success. Any and all foreseeable risks must be documented and relevant mitigation strategy devised. Quality Assurance (QA) reviews are essential. money for project related travel and training. This Handbook is relevant to all related groups of work activities that have a business objective. will achieve specific objectives. A project has a stated scope. delivery date and budget are not adversely impacted. or both. A project must be managed in terms of its structure.2 Introduction What is a Project? A project is any related group of work activities which. 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. project administration. tasks. Project milestones. and defined work breakdown structure comprising a path from the start to the end. Page 10 of 94 . infrastructure support. and brought to a successful implementation. a project must move forward in a controlled manner. whether the solution involves Information Technology and Telecommunications (IT&T) or not. with high levels of productivity and quality. Progress reporting will also vary depending on its intended audience. to identify issues at the earliest possible stage. including significant stakeholders not assigned directly to the team. a defined end point. A project:      Has a beginning and an end. work steps. A risk management plan is an essential element of any project charter. The objective of project management is to plan and control a project from start to end. specific deliverables and budget constraints. deliverables. from initiation to completion. work performed by staff assigned to it. as defined in a Project Charter. when completed. duration and budget. whether technology based or not. Has a defined starting point. or over budget. Resources must be used effectively or the project will be late. Project Management is the process by which a project is initiated. etc. are developed to show tangible results of work done and to provide substance for quality assurance reviews. A project uses resources. Risks are inherent in all projects.

milestones and de liverables Estimate task effort Determine task dependenc ies Determine externa l depe ndenc ies Determine interface/interaction dependenc ies Determine key milestone completion dates Schedule pla n. assign project ma nager. inc lusive of constraints Review Project Plan Allocate responsibility. work breakdown structure. compare and ana lyse Actuals VS Plan Review estimates to complete Post actual against budget Communicate progress Review Project Plan Page 11 of 94 . project sponsor. establish steering committee Identify project team and stakeholders Docume nt project team structure Establish project cost codes and a llocate budget PROJECT CHARTER ESTABLISHMENT 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 Alternative solutions evaluated and compared Business need recognise d Project scope & objectives define d and agreed BUSINESS CASE INITIATION Submit Project Plan for acceptance PROJECT STATUS REPORTS CONTROL Analyse performance ACCEPTANCE SIGN-OFF COMPLETION Process Owner & Executive Sponsor sign-off CHARGE (if applicable) POST IMPLEMENTATION REVIEW Capture actual data. identify individua ls to be assigned to skill needs Determine tasks.3 Project Management Phases INITIATION ESTABLISHMENT PROJECT MANAGEMENT PLANNING CONTROL COMPLETION Alternative solutions determined PROJECT PLAN PLANNING Confirm assumptions Recommended solution determine d Confirm resource (skill) requireme nts Confirm resource ava ilability.

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. processes and organisational structure must be reflected in the planning of any project. priorities. UNIVERSITY OBJECTIVES BUSINESS PROCESS 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 SUPPORTING RESOURCES No project can be an island in the context of an holistic organisation. Page 12 of 94 . strategies and infrastructure. Projects should not be single point solutions to business problems or needs. 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.4 Project Scope The scope of any project should be derived from and be consistent with an overall enterprise model of business needs. data. the strategies. objectives and critical success factors have to be taken into account. the University‟s goals. Similarly. Project managers have to manage these interdependencies without compromising the success of the individual projects for which they are responsible. All processes will cross numerous functional divisions. The top down planning process will ensure that each project represents a tactic within an overall business program. and the end-to-end impact of any change to any process needs to be identified and addressed during a project‟s planning phase. During the planning phase.

Users need to be involved in any project. overuse of jargon and an unpreparedness to speak to the users in their own terms. or acquire. as reviewers and evaluators of deliverables. Business process models need to be developed to ensure that the current procedures and proposed changes are understood clearly. Objectives and deliverables may. to derive a common understanding of the business and its needs. It was. the roles of users as members of the project team. project staff prefer to minimise interaction with end users. as members of the project team in the functional analysis and process modelling stages. some knowledge of the technical aspects of any project to which he/she is assigned. The project manager must assure a well defined scope management plan. should be the focus of every project.5 Role of the Project Manager The project manager acts as a leader and a process manager. 6 User and project staff interrelationship Business users. This lack of credibility often arises from:   Past failures to deliver on commitments. and for motivating the project team to achieve them. as an information source. the management and control structure. A project manager must have credibility with their project team and with the project sponsor. Such models need to be developed jointly by the business users and the project staff. and create a project environment that allows all participants to maintain maximum productivity and effectiveness. Page 13 of 94 . If end users are not sufficiently involved in the project the project will inevitably lose support. assumptions are made. therefore. Models developed by project staff in isolation from the business knowledge base are insufficient to assure a common understanding. there is a reliance on informal communications. provide continuous leadership for the development team. the project manager is responsible for managing and communicating a clear vision of the project objectives. When designing a project organisation structure. and usually do. not technology or external providers. As a process manager. As a leader. change as new information is gathered by the project team and evaluated by the project sponsor. Past practices isolated users from the project process. and support groups need to be defined before the project begins. or had been afforded the opportunity to understand. Many projects fail because they lack credibility with the end users. Project deliverables are very rarely static over the life of a project. So it is essential that the project manager have. Poor communications. over budget and deliver less than the end users expected. projects are often late. the project manager must ensure that work efforts are sequenced to achieve the overall project schedule. User involvement ultimately determines the quality of business systems. hard for users to commit to a process in which they had not participated.     to assure project direction continues towards the specific business needs and objectives. manage the project sponsor relationship effectively. users are not listened to. This “them” and “us” approach inevitably militates against success of any project.

Most usually. critical success factors and organisational units. integrated and preserved in the knowledge base. Strategic plans. development and implementation phases of a project. to the end users. screen layouts. Refer Appendix A for details of data modelling techniques. letters. organisational models. design. 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. etc). Objects include entities that are elements of the business process (lecturer. 7 Knowledge base A thorough knowledge base should underpin every project. lecture room. Effective knowledge coordination improves the effectiveness of each project manager and assures that individual project findings comprise a collective organisational memory over time. A knowledge base is the set of all information relevant to the identified business need that is collected during the planning. Interviews and work shops will appear random unless the users receive timely and professionally structured feedback. Assuring a comprehensive knowledge base is essential to maintaining a rigorous structure in any project. Elements of the knowledge base are described as objects. outputs (including forms. 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. tutor. The accumulated knowledge base should be documented using a conceptual data model. rather than the business need.  Perceived lack of structure and process. All deliverables are described in terms of the knowledge base objects that comprise them. rather than to address the actual business need. available (as read only) to all who need to know its contents. time and resources. money. Often. particularly topical technology. Use of the knowledge base enables the business knowledge gained within a single project to be shared and reused by other projects. Knowledge coordination is critical to ensure smooth translation of models between project phases. etc). The knowledge base must be stored in a central location. which may be resolved without technology at all. requirements models and functional design specifications are documented. student. Iterative performance and analysis of tasks and activities are used to refine the information in the knowledge base. An over emphasis on technology. The scope of information represented in the knowledge base is far greater than the traditional project information of tasks. a project can seem to be predicated on the project teams‟ desire to use technology. Page 14 of 94 . analysis.

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

Even when current. without including so much information that it verges on a technical specification and becomes unintelligible to the business users/process owners. preceding detailed analysis.  Operating instructions and/or Procedural documentation Again.To design and install cost-effective business systems that meet the needs of the user base. therefore. correspondence Ask people who have been around long enough to know (and preferably. useful background information can be obtained from:  Organisation charts and Policy manuals If these are unavailable or out-of-date. the end user must be provided with:   A functional specification (needs analysis) of the business system to be developed (or purchased and installed). It is essential that the functional specification be understood by the end-user/process owner. whether they can be computerised or not. 9 Business Process Mapping 9. 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. The functional specification should set out. the logical requirements of the business system. these may be out-of-date. the current organisation structure or policies need to be determined. The functional specification represents the essential activities which must be performed. It is important to understand the reason behind any obvious inefficiency in the current process. In all instances.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. The analyst needs to understand the constraints that may apply to changing any process. A high level preliminary review. the first and most essential step in business systems development or re-design. and sign off to the effect that. and what trade-offs may be required (for other than essential functions). Normally. who appear to be unbiased in the process analysis). but will act as a guide. Business process mapping is. rather than a constraint on improving them. will often facilitate the information gathering exercise. those needs must be completely and reliably met by functionally rich and robust solutions. so that he/she can: o Agree. Page 16 of 94 . they are a guide to understanding the present process. What is relevant will be determined by how well the objectives of the analysis have been defined.  Previous reports. 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. clearly. Minutes of meetings.

particularly indirect users. 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. Charting has five main uses:      Fact finding Analysis Design Presentation Implementation In regard to fact finding. By identifying and researching as much background information as practical within the time available. Identify the key people who interact with the process or system being analysed. deal with uncooperative people. the person conducting the analysis of the business process:      Will be sure of the information he/she requires. will reveal the complexity of the new (or possible alternative) system and. Similarly. an effective and comprehensive chart of the process is the way in which the analyst will know and understand the existing process.2 Charting Charting is the principle documentation approach within business analysis. Personal conversations Be aware of the person who may have been closely involved with the process/processes under review in the past. in the context of the chart of the existing system. 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. charting of the design of the new (or possible alternative) process. who may now be in another department. It is important to chart at the highest level first. if and when the need for such becomes apparent (as it inevitably will in the context of proposed automation of business processes). school or faculty. Page 17 of 94 . then to “drill down” to more detailed levels as. the extent to which it varies from the existing system. and from whom it can be obtained Can anticipate likely opposition and obstruction Can prepare well for interviews. particularly.

2.2. Types of Charts 9.1. etc. 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. bottlenecks. audit ability. 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. maintainability.1      9. The interdependencies and interfaces of the business process being analysed. 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.1 Information Flow Charts Operational/procedural flow process charts/maps Schematic flow charts. 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”). diagrams or maps Form flow chart Forms routing charts Computer logic charts Page 18 of 94 . reliability.Charts are very effective presentation tools (“a picture is worth a thousand words”). 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. timeliness.

The following chart provides an example of an entity-relationship diagram in which the relationship between student and course is many. is a visual display to represent scheduling which is based on time. but each course will have only one tutor (in this example): Students Enrols in Courses Taught by Tutor 1 The Gantt chart. because each tutor will teach many courses. used for displaying project schedules depicting tasks and the dependencies between tasks. because each student may attend many courses and each course will have many students.2.9. volume or weight.2. rather than quantity. The relationship between tutor and course is one to many. devised as a charting method by Henry Gantt. 2 PERT charts: (sometimes called Network Charts or Logic Diagrams) are widely used project management diagrams.1.1 This is a diagram used to show how various entities (elements of the process) are related to each other.2 Special Purpose Charts     GANTT1 or BAR charts (Project Planning) PERT2 network charts (Project Planning) FAST3 diagrams DFD (data flow diagram) Entity Relationship Diagram 9. 3 Function Analysis System Technique Page 19 of 94 .

Where two forms are linked vertically through several operations. A new form or record is created  Information is being added. mission. the process map should include a notation as to the computer application to which the information is submitted. and is especially useful in defining the functional requirements of an information technology application. Movement. A decision. A Process Flow Chart shows the information and/or activity flow represented by separate forms. No information changes. strategies and operational plans.2. indicates transfer of a form physically from one point to another. check or review point. or from which the information <data> is obtained. 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.9. and other media. or handled The vertical lines indicate the relationship between different forms or records.3 Process Flow Chart Process Flow Charts are used at ACU National to map the business activities that support the University‟s vision. MO Page 20 of 94 . the destination or origin of the move should be notated below the arrow. indicating the source from which the information being added is obtained. inspection. 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). It may be presented in either a horizontal or vertical flow. The nature of the activity being performed needs to be explained on the chart. it indicates that the same forms are used in multiple operations Information or activity flow is from left to right. This is usually associated with a vertical connection. Indicates a sorting or distribution of copies S Indicates a machine operation (most usually a computer system. records.

constraints and operational guidance. often.9. 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. teams/individuals etc • Job roles: logical grouping of tasks. performance measures and career paths • Training and development • Terms and conditions of employment. more efficiently. There are five key questions that need to be answered to perform an effective analysis: 1. 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. or in another department? Will a change to where and when it is being done save steps. 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. What is being done and why should it be done there? Can it be done more easily in some other step of the process. is it really slowing down or holding up another business operation? 5.2. These can be analysed and changes recommended without reference to external authority. Page 21 of 94 . how these fit together. which include changes in: • Organisational structures: options: specialist/generalist. Operational guidance is the University‟s determination of how activities should be done. skills. • Reward systems. In the University environment these are determined primarily by Legislation and statistical reporting requirements and cannot be changed by the University unilaterally.3 Analysis of Process Charts The business process chart provides the most effective means of eliminating unnecessary work and streamlining business processes. 4. time and effort? 3. and delegate tasks to lesser-paid employees wherever feasible. Rules are of two types . Never overlook the people aspects and cultural issues that will need to be addressed. because it provides a detailed description of a particular task or piece of work. 2. with less cost? For many activities there are explicit rules for how activities are done. it will be found to be unnecessary. management roles. Constraints define conditions under which an activity cannot be done or conditions under which an activity must be done. 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. capabilities etc.

whether IT&T based or not: User Acceptance testing Integration testing Implement Maintain. Support enhance Identify business need Unit testing Establish Framework  Strategies  Policies  Procedures Program coding Analyse and specify requirements Program design Technical specification Functional specification Page 22 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 other processes apply to all projects. The processes shown in green shaded arrows related specifically to projects that are initiated to implement an Information Technology & Telecommunications (IT&T) solution.

projects. as well as developing project charters and high-level plans for each individual project. 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. The business case provides a consistent message to many different audiences. approach and controls of the project Estimate the project effort. Retrospective documentation of a business case. part of an ongoing strategy for business improvement. documenting work already done. If the business program consists of a number of sequential. 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. Option 1 in every evaluation of alternative solutions is “do nothing”. and identify where the business would be without the BPR project. justification for continuing funding. a master project plan will need to be prepared to identify project interdependencies. Formulation of the business case is a response to an identified business need. it is easy to link the issues to the solution and the benefit. By documenting everything together in one document. or consequent upon a seemingly good idea to test the merit of that idea. and will usually identify holes or problems with the solution.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. as opposed to concurrent. is unacceptable. Initiation of a project must be supported by a business case. Moreover. It is designed to gain approval at the appropriate levels of the University to proceed with the project. The business case constitutes the justification for the project. Refer Appendix G for a sample Business Case. post implementation review of benefits derived can only be effected when there was an initial projection of such benefits. a request for increased funding. Any flaws in the understanding of the business need or the proposed solution should become apparent during writing of the business case. problem or issue. signed off by the appropriately authorised officers of the University. 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. The development of the overall business case simplifies the development of the financial justification. 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. in that it requires concepts to be detailed and fully considered. it may be enough to create the master project plan and a detailed project charter for the first project only. Page 23 of 94 .

the better the monetary returns are on an investment. DCF includes Internal Rate of Return (IRR) and Net Present Value (NPV): 11. minus the present value of the cost of the investment. Cash flows in the future are discounted. discounted at the cost of capital*.1.2 Cost and Benefit Analysis (CBA) Every project competes for limited funds and finite resources. Effective and comprehensive functional analysis is essential at the outset and relies on appropriate business process analysis. 11. 11.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.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 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 higher the NPV. Refer to Appendix L for details and examples of how to calculate NPV.1. 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. It is important to specify exclusions from scope. Page 24 of 94 .1. There are numerous ways to approach a CBA.2. *Cost of capital is the discount rate used for project investments evaluations and capital budgeting. some of which are: 11.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.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. where misunderstandings are probable.2 Project objectives A project‟s objectives are synonymous with “goals”. as opposed to compounded. Refer to Appendix J for details and examples of how to calculate IRR. by a specific discount rate. 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.1 Discounted cash flow (DCF) This is a method that considers the time value of money. to convert them to present value. DCF assumes that the value of any given amount of money will be less in the future than in the present or the past. It is the opportunity cost of an investment. 11. As a rule. The opportunity cost is the value of the next best purpose that the money available could have been used for. 11. It is therefore essential to analyse the costs versus the benefits of every project so that they can be prioritised and allocated budgets.11.2. That is.

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).3.3. Allocate the anticipated costs and benefits monthly across the timeframe. computer time usage.4 Return on Investment (ROI) ROI is the yield that will manifest as a “profit” from expenditure. etc. Tangible benefits. 11. Cost and benefit categories Treatment of intangible (qualitative) benefits Treatment of taxes.1 Identify benefits Work with the project‟s sponsor to identify benefits that will result from implementation of the project. It is not always clear whether a benefit is tangible. 11. Always ensure that it is possible to track and audit tangible benefits. Always start with the expected tangible (quantitative) benefits and document assumptions clearly. 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.2. Consider both direct and indirect costs. Ethereal intangible benefits such as “better decision making support” cannot be quantified. 11. depreciation and consumer price index (CPI) Full absorption cost of labour. 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. such as reduced staff (which can be recruitment avoided. by level and skill set.3       Developing a cost/benefit analysis The cost of capital (discount rate) to be used The recommended investment analysis time line applicable to each of capital and operating expenditure respectively. including the temporary reduction in productivity while users are familiarised with the new system and while they are seconded to the actual project team.2 Identify costs Determine the costs and the intervals at which those costs will be incurred over the life of the project. Operating leases will vary the scheduling of capital costs compared to outright purchase. The following standards and guidelines need to be determined before a realistic CBA can be developed: 11. as opposed to redundancies) and avoidance of rental of extra office space are easy to quantify. Page 25 of 94 . ascertained from Finance.3. An indirect cost will inevitably be the organisational change impacts. Costs will vary depending on the staffing approaches and the supporting technology (if applicable). 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.

Similarly. Page 26 of 94 . When planning a project. Generally. ACU uses Microsoft‟s Project Plan software to create and maintain project plans. will show skill types needed. Project plans must be reviewed regularly to identify any slippage from original delivery dates. Resource constraints. quality issues and project risks need to be factored into the milestone plan. on which the budget is based. Milestones will usually be the completion of project stages. Project plans should include:         task schedules. to implement corrective measures and to evaluate the flow on effect on the project schedule overall. The completion criteria of each deliverable. a risk management plan. a scope management plan. Detailed plans must be revised as necessary throughout the life of the project. The detailed project plan is used to document deliverables and to achieve the project objectives detailed in the project charter. Maintaining and tracking a detailed project plan is impractical if done manually.12 Project Planning Project planning is an iterative and ongoing process. and a detailed budget addressing all aspects of the project and its management When preparing the detailed work plans. whereas the actual detailed plans will be at a task level. being project specific detailed work plans. 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 steps involved in achieving the deliverable. whereas the detailed plans will show particular staff‟s names. The master project plan and all subsidiary plans must include milestones. 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). The high level project schedule in the project charter will be to an activity level. There is some overlap between initiation. The project manager is responsible to create the project plan. the high level plan. created during project initiation. an issue management plan. establishment and planning of a project. 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. resource schedules. quality management and review plans. a communications plan. Each task within a project plan has a narrative description sufficient to communicate:    What is to be achieved/delivered. details from the business case.

Determine the type and duration of training required and include that training in the detailed project plan. then consideration should be given to assigning team leaders for identifiable modules of the project. Page 27 of 94 .1 Change Management Plan A change management plan must be prepared in conjunction with the project plan. not only as a schedule to manage the timeliness. 13 Project organisation A project team is brought together for a pre-determined period of time to achieve a specific set of objectives. The most common time based techniques for displaying project plans are shown below. 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. will need training. sequence and interdependency of tasks. through whom other team members will report. so is used most often at ACU National. the Gantt Chart is the default display option within Microsoft Project. 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. If more than six people need to report to the project manager. Change management is the mechanism through which a change to a process or system in the University is initiated.    CPA – critical path analysis (refer Appendix C) PERT – program evaluation and review technique (refer Appendix D) Gantt Chart . The project organisation chart must be augmented by role definitions and assignment of responsibilities for each member of the team. it is essential to recognise that some or all of the project team.A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt. assessed and implemented. 12. but as a tool to assure clear communications.During the planning process. and potentially some of the extended stakeholder team. to ensure that user training and procedural documentation are available at appropriate junctures. It is essential that the project team be given sufficient authority to achieve the project‟s objectives. an American engineer and social scientist (refer Appendix E) A project plan has many uses. 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.

Sometimes. incorporating the Gateway review process if required. The Project Sponsor is responsible for:               Ensuring an appropriate project or programme management framework is in place. Project Initiation Document (or equivalent) and business case Appraising options and submitting for approval Securing resources and expertise from the client organisation as required. experience and has the available time and resources. Often. expertise.  approves changes to project scope. subject to the proviso that the person taking on the combined responsibilities possesses the requisite competencies. They may be known as the Project Sponsor. 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 executive sponsor:  has control of the budget. 13.Roles in the overall project organisation will typically include: 13. This role description assumes that the roles of Project Sponsor and Project Manager are separate. The Project Sponsor is responsible for ongoing management on behalf of the project owner to ensure that the desired project objectives are delivered. For smaller/straightforward projects the roles of Project Sponsor and Project Manager may be combined. the executive sponsor and the project sponsor will be the same person. 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. the executive sponsor will delegate routine participation in the project to the project sponsor. The person in this role must have adequate knowledge and information about the business and the project to be able to make informed decisions. including their time and budget impacts.  provides high level direction.2 Project Sponsor The Project Sponsor provides the interface between project ownership and delivery.  resolves otherwise irreconcilable conflicts in the course of the project. 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 . Preparing the project brief. sometimes referred to as the Project Director.1 Executive Sponsor This is the person who has ultimate authority over the project and is ultimately accountable for its success. it is essential that delegations and responsibilities are clearly understood and do not overlap with other roles. Where roles are combined. for example.

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.3 Project Manager The Project Manager. 13. negotiate well and influence people. 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. 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. 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.     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. Page 29 of 94 . 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. broker relationships with stakeholders within and outside the project Be aware of the broader perspective and how it affects the project. operating within agreed reporting structures. initiating corrective action where necessary Change control and any required configuration management Reporting through agreed reporting lines on project progress through status reports. 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.

deleted functionality. would marginally enhance the implemented solution. Change requests need to be categorised. or changes to the legislation or government reporting requirements. scheduled into a revision of the project plan. They should not arise. Such changes must always be included into the original implementation schedule. Almost without exception. evaluated. They will always be deferred from initial scope. and post-implementation. Again. modification of deliverables. rejected. Most often. They will arise as the result of internal oversight.14 Scope Management Any additional functionality. Many projects fail to meet their schedules and their budgets because of “scope creep”. if approved. Desirable (D) changes are changes that stakeholders advise would facilitate and optimise operations. N2H are “in our dreams. constitutes a change in the project‟s scope. Acceptance of any change will require that the project charter. to assist in determining how to deal with them. be scheduled as post-implementation production enhancements. will always stand behind desirable changes. It is essential that any and all changes to scope be managed closely. these should be deferred from the initial implementation scope and. project budget and resource requirements be amended. 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. or deferred until post-implementation of the original scope. project plan. 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. as all such requirements should have been identified during preparation of the project charter. tabled and. etc. infinite funds and infinite time. if the University had infinite resources.. but not in our lifetimes”. Mandatory (M) changes are those which are mandated by legislation or statutory reporting requirements. Nice to Have (N2H) changes are changes that. Such management requires that any request for change be documented. as detailed in the project charter. manifestation of such will be as the result of a failure during the analysis and design leading to the functional specification. instead. Page 30 of 94 . Essential (E) changes are changes that the University stakeholders consider it impossible to do business without. as follows.

deferred to post-implementation. the cost of including additional functionality within the project scope will be outside the original project budget. depending on the duration of the project overall and the deliverables/milestones impacted by the change request.Any stakeholder of the project may submit a change request. so the change request process is ongoing throughout the life of the project. it is the responsibility of the project sponsor to decide whether the change will be included in the initial implementation. Change analysis hours should be included as scheduled and assigned tasks of selected project team members in the original project plan. A good scope management process is essential to delivering the commitments documented in the project charter.2 Cost analysis Inevitably. After this preliminary analysis. 14. The project manager will then assign one of his/her team members to analyse each request. no-one likes to be told “no”. sufficient funds should be provided in the original project budget for resources to spend the time assessing the change requests themselves. However. All change requests are to be assigned to the project manager in the first instance. When mandatory changes are identified. Page 31 of 94 .1. 14. and possibly weekly.3 Mandatory changes Consistent with the category. 14. the fact that it/they have been identified must be communicated throughout the immediate and extended project team.1. When changes are rejected. The request for a change may arise at any time. the stakeholder who requested such change is going to need to understand the reasons for that rejection.1. at least once a month. including a high level cost/benefit analysis.1 Impact analysis Short term and long term consequences of implementing VS not implementing the requested change need to be considered.1 Scope creep considerations: 14. It is best to establish a clear schedule for consideration of change requests. mandatory changes must be accepted and included in the project scope. or rejected.

project organisation and project schedules. this is counter productive for the project overall. The overall time spent on the project may appear to be “spot on” to estimates. 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. The Project Status Report is also a key mechanism to control the project. user relationships. when and as necessary The purpose of a Status Report is to keep stakeholders informed. Project Status Reports are distributed to the project sponsor. Page 32 of 94 . A Project Status Report must be produced no less frequently than monthly. In times of difficulty. who will then be kept fully informed and be able to ensure that the overall Project Status Report reflects the project as a whole. but involves more uncertainty. Refer to Appendix H for the format of a Project Status Report. user community and other interested stakeholders. on an agreed date that enables reporting of budget VS actual expenditure for the month to which the Status Report relates. The reports must be concise and honest. as measured against the success criteria detailed in the project charter report issues to the appropriate stakeholders and seek assistance through escalation. Formal control involves procedure. Inevitably. the version provided to the immediate project team. as measured against the project plan evaluate progress. Every team leader within a project team should submit a formal Project Status Report to the project manager. The report submitted to executive management/steering committee will be derived from. the project manager may need to take critical decisions on matters such as individual or team performance. while others that should have begun have not. Informal control allows quicker response. technical and management issues. But.15 Project Status Reporting The project status report communicates project progress against project plans. During the project. project team. 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. and for members of the project team to conceal problems from the project manager. The level of detail in a report should be consistent with the audience to whom it is sent. Preparation of a Project Status Report is essential to:    report the progress of a project towards its objectives. Effective project control requires that information is timely and true. effort and time. controlling that project becomes even more difficult then when all is proceeding to plan. where applicable. 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. there is a temptation to tell the user community what they want to hear. project steering committee. As work on the project proceeds. but be less detailed than. The project manager must analyse project plans scrupulously to identify problems. this could be caused because excess hours have been spent on one or more tasks. When a project runs into problems.

The best way to do this is to interact with each member of the team daily. whether his/her time is charged out or not. at the same time. Each week. An effective project manager must ensure that his/her involvement is constant and visible. such daily contact with key users is essential too.  Have prepared an individual status report. Each attendee is required to:  Have filtered the project plan for their own assigned tasks. Similarly. while serious issues will arise from lack of attention in the early stages. then urgent issues will overtake genuinely important ones and the “squeaking gates”. Maintenance of such records. not someone else‟s definition of urgency. within either the project team or the broader user community. o explanations of any past due scheduled dates for their assigned tasks. including. will receive all the attention. the to do list must be reviewed at the start of each day and updated at the end of each day. in the context of genuinely meaning “how are things going” is a good discipline to adopt. by time intervals no less frequent than hourly per day. 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. For projects in particular. A good project manager will track and manage use of his/her time very carefully. Outstanding items must be prioritised according to their real importance. the project manager should:  Collect and collate project actual data. needs to be undertaken by the project manager and team leaders. will identify “time wasters” and excessive administrative overheads that distract from the real work of the project. o proposed remedial actions to complete overdue task/s. the format of which is shown at Appendix I.     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. but which are the essence of effective time management in any work environment. in the same venue. To do lists include items that don‟t warrant inclusion on the overall project plan. beyond just the facts as represented in project status reports. If the project manager is not proactive in monitoring the overall project. Page 33 of 94 . Maintenance of an up-to-date “to do list” is never more important than in the context of a time driven project. Any and all issues raised must be documented and carried forward to the formal issue register. regular monitoring. Such a meeting should not exceed one hour. inclusive of: o an issue log. A comprehensive round of good mornings. 16 Issue Management To avoid having to spend time on problem management.The full functionality of Microsoft Project‟s variance analysis tools must be employed to ensure that the project is genuinely on track.

collated and complete Project Status Report. Usually. Alternatively. Review and update the issues log Review and update the change request log When an issue attains amber or red status. prepare the comprehensive. 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. Pursuant to the weekly team meeting. the project plan must be revised accordingly. such action may need to be immediate. it may be considered a problem and requires corrective action. operating expenditure) on the status report. Depending on the impact of a problem. Any problem constitutes a risk to the success of the project. but ensure that the variances are captured to line item before such summary is created. the same person will take the Minutes each week. the role of Minute taker will rotate through the attendees. excluding the project manager. Each month. the project manager should meet with the project sponsor to discuss and update the status of open issues and any outstanding change requests. or scheduled into the project plan for a future date.Where any scheduled deliverable has slipped. Formal Minutes of this weekly meeting must be kept. Page 34 of 94 . if the project has been assigned administrative support.

Risks can be mitigated by reducing either the likelihood or the consequence. assessed. Page 35 of 94 . Likelihood can be reduced by proactive mitigation strategies. ultimately. This assignee will also be responsible. to take appropriate preventative action and to recover from the impact if preventative measures fail. Effective risk management is an ongoing discipline throughout the life of any project. the magnitude of risk is assessed according to the following matrix: Almost Certain (5) Likely (4) Significant N5 High/ major L5 High/ major M5 Severe (V5) Severe (E5) “Unacceptable” Risk Ratings Moderate N4 Significant L4 High/ major M4 High/ major VH4 Severe E4 Likelihood Moderate (3) Low/ trivial N3 Low/ trivial N2 Low/ trivial N1 Negligible (N) Moderate L3 Significant M3 High/ major VH3 High/ major E3 High/ major E2 Unlikely (2) Low/ trivial L2 Low/ trivial L1 Low (L) Moderate M2 Significant V2 Rare (1) Low/ trivial M1 Medium (M) Moderate V1 Very High (VH) Significant E1 Extreme (E) Consequence Risk management requires that risks be determined. All mitigation strategies must be assigned to a specific person/role who will be accountable to implement the resolution. upon implementation. actually meets the end-users requirements. amber or yellow sectors of the matrix above require preventative measures to be put in place. to monitor the risk. the timeliness of deliverables and. upon assessment. as the project manager‟s delegate. are determined to be within the red. Risks which. the implementation date. prioritised and controlled. It will still be necessary to prioritise risks within each of those categories and this requires that the potential consequences be considered. as “High/Major” obviously constitutes a greater risk than “Significant”. Categorisation of risks in accordance with the matrix automatically assists prioritisation. Risks are contingencies that may adversely impact the budget. Regular review of the project plan will manifest uncertainties which may constitute risks. Piloting a project implementation in a small self-contained functional area is a standard risk mitigation measure. or the extent to which the project.17 Risk Management With reference to AS/NZS 4360:1999 “Risk Management”.

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

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. 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. 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. risks and changes to the project‟s scope Page 37 of 94 . Before attempting to develop a communication plan the project manager should conduct a stakeholder analysis. 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. This can be as simple as compiling a list of project participants and customer groups. 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.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. to performing an in-depth analysis producing comprehensive stakeholder profiles. 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. Communication during the project can be by various methods.

By going through the process of developing plans and strategies the project is more likely to succeed. 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. A communication plan template has been included in this handbook (see Appendix K) Page 38 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.

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. Project acceptance needs to be documented. 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. A project may also be completed by virtue of being abandoned. PROJECT COMPLETION APPROVAL AND ACCEPTANCE Project Name: Project Manager: Date: Completion statement: Additional comments: Approvals (position title/name/signature): Page 39 of 94 . the following is an example of an appropriate document for sign-off by the project owner/project sponsor and other identified key stakeholders.

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

for example a sale or a birth.1. as if they were entities. a transport pool handles resources which in a global data model might be all classed as vehicles.1. the domain from which attribute values are taken. 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. 20. however.1.1. but it is doubtful whether it should be a first class citizen of a conceptual data model. Page 41 of 94 . The more abstract the entity. and relate them to one another. the more difficult it is to decide whether it should really be classed as an event or a relationship. what sort of questions are likely to be asked and how future developments may require the initial requirements specification to be extended. 19. Although certain attributes and relationships may be common to all vehicles. etc. whether it is permanent or time-varying. 20. As a piece of paper. it may. In terms of the overall model these are events which trigger off processes.5 Physical boundaries It may be difficult to determine the physical boundaries of entities which are identified primarily by geographical location. there are many more that are more abstract. For example.6 Events So far we have been talking about entities which are fairly tangible objects. we may wish to count them. be necessary to specify points on the motorway. 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.20. At this level we need to know such things as:      attribute name. attach attributes to them. limousines.1. whether the attribute is part of the entity identifier. whether it is required or optional for the entity.7 Messages Similar difficulties occur with entities which exist only as messages within an existing clerical business system. lorries. Attributes are pieces of information ABOUT entities. It is necessary to consider the purpose for which the information is being collected. a motorway is a road which is part of one continuous system. a receipt is a tangible object. For example.1.4 Sub-classification of entities The need for sub-classification of entities arises frequently. The analysis must of course identify those which are actually relevant to the proposed application.1. 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. however. where one section stops and the next begins.2 Attributes. As these examples indicate. they are not inter-changeable and for practical purposes must be subdivided into vans.1.1. each with their own particular characteristics. 20. Nevertheless.

address and date of birth for a person. and identify where the same piece of information occurs in different places (e. week or year? 19.) 19. gradings and nationalities. They should enable users of the data model to see what is being recorded.2.1. consider a model built around vehicle Page 42 of 94 . Vehicle Registration Number) so as to have quicker and easier means of identification. through a DATA DICTIONARY.2.2.1 Domains A DOMAIN is a set of values from which attribute values may be taken. coding and/or abbreviations should be postponed until the implementation level.g.they are distinguished by a combination e. 2 roads intersecting) role names are arbitrarily assigned. colours. Important information to be recorded is: 19. driver etc. 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.1.g. In natural discourse very few things have one unique name or identifying attribute .1. On the other hand it will be useful to know the kind of accuracy which may be expected for this attribute . This happens with very general entities such as vehicle more often than with those more narrowly defined. Where a relationship is symmetrical (e. it is convenient to give unique but arbitrary labels to persons or objects (e.3. For example.1 Attribute names. Entities may have attributes whose values will sometimes be unknown or irrelevant. owner. requiring the setting of LINKS from one part of the database to another. 19. 19. National Insurance Number.2.19. 19. An important point about a relationship is how many entities participate in it. The same applies to the role names within the relationship. We must distinguish between attributes which just describe an entity (and perhaps change over time). It is important to know which attributes may change their values over time. 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. a relationship should be named by a word or phrase which explains its function. sums of money. the same role may be played by different entities. Role names are different from the names of entities forming the relationship: one entity may take on many roles.1 Number and type of roles Like an attribute.but precise formatting specifications are not required. temperatures.2 Identifier attributes. name. In one way the more definite we can be here the better . and those which help to identify it uniquely. however it is by no means the case that all relationships must necessarily be binary in this sense. A date is a date.4 Optional attributes. A record of which attributes are OPTIONAL or MANDATORY will help when defining general consistency constraints for the data base at lower levels.g. In formal business systems. e.g.is the measurement to the nearest day.1.1. But some care is required.1. and there is an understandable process for getting from the entity itself to its identifying attribute. grid references.g. It may also be necessary to hold previous values somewhere for AUDITING or the production of HISTORICAL REPORTS. In practice BINARY RELATIONSHIPS are most convenient for data modelling. Examples are: dates.3 Time-varying attributes.1. as they will have to be updated when the system is implemented.it is more helpful to know that an attribute is a linear measurement than that it is a number .2. This will certainly influence the lower level design. Names should be explanatory words or phrases.3 Relationships In many applications one external event or process may affect several related entities.

Book. Building . 19. hospital . To decide the DEGREE of a relationship one must be clear about whether individuals or types are involved. Garage) Vehicle_Manufacturer supplies Vehicle_Type to Garage. Hills is supplied by Ford Relationships (2). One cannot validly infer (1) from (2).manufacturers. e. not cars. in Britain the legal relationship husband-wife is one to one in the first case. In such a model we may wish to represent the information specified by a TERNARY RELATIONSHIP e. Hills sells cars 4. vehicle_type) is one-to-many if we are talking about an individual manufacturer.g. The false inference (2. e. e. vehicle_type) are types. Consider also the time dimension .2 Degree Relationships may be:     ONE-TO-ONE. Ford supplies cars 3. 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.patient. it may be that Hills only sells Ford trucks.3. (3) and (4). Manager . (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. Vehicle_Type. MANY-TO-MANY. RECURSIVE.Location. ONE-TO-MANY. e. 4) => (1) is sometimes called the connection trap.g.1.Employee.g. Ford supplies cars to Hills tells us more than the combination: 2. The relationship (vehicle_manufacturer. Author .whether the relationship is being recorded at a single point in time or over a period of time. e. 3. Page 43 of 94 .   (Vehicle_Manufacturer.g. but many-to-many where (vehicle_manufacturer. For example. types of vehicle and garages. but potentially many to many in the second.g.g.

g. If temporary but required by one of the participants (e.5 Dependencies One relationship may necessarily exclude or imply another.3.3 Optionality A relationship may be required or optional for either participant.1.g. 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. or be excluded or implied by another.1. e. a piece of property must be owned by a person but not all persons need own a piece of property.1. ownership or employment). Page 44 of 94 .3. Many of the above constraints will require consistency checks on incoming data. Membership of the City University Students Union necessarily implies membership of the University itself. 19.19.g.3. ownership) it must be transferable.4 Permanence A relationship may be defined as permanent (e. parenthood) or temporary (e.g. 19.

one convention on which all the different approaches seem to agree is the use of a rectangular box to represent an entity.' 'Employees File Time Sheets.1 Data Modelling Objects The three types of data objects--entities. The most popular approach is called the entity-relationship (ER) approach. Relationships are verbs that describe how entities relate to each other. 19. One reason is that it is often unnecessary to label the relationships if the meaning of the relationship is easily understood. and relationships of data in a business. Attribute examples include Colour. and laziness. attributes. not a technical one. or things about which an organization wishes to save information. Relationships are represented by a line.2. most still have a strong Chen flavour. and Time Sheets are examples of entities. characteristics.' 'Salespeople Place Orders. Orders. each using a host of conventions and tools. for example: 'Customers Buy Products.2 Relationship diagrams The conventional way to show relationships is shown in the following diagram: Page 45 of 94 . Therefore. 'Customers Buy Products' is the same as 'Products are Bought by Customers. States. Its purpose is to describe end-user data to systems and end-user staff. modellers often do not label relationships in both directions." which is a fashionable mechanism for representing relationships. and relationships--are the basic building blocks of modelling:  Entities are persons. with the introduction of CASE tools. technical. the number of diagrammatic conventions that the data modeller must master has increased sharply. including time. Employment Date. Relationship entity pairs are bidirectional.2. (As a convention. and Tax File Number.2 Logical Data Modelling Logical data modelling is a graphic-intensive technique that results in a data model representing the definition. 19.) Attributes are the properties of entities. or conceptual environment. space. Although a number of authors and tool designers have modified and expanded ER concepts. for various reasons.' "Relationship" describes an end-user relationship. Various methods of data modelling exist. Employees.   While a number of graphical conventions represent data objects. places. Name.19. Also. However.' A sentence in this entity-relationship-entity construct is called a "relationship entity pair. developed by Peter Chen in the late 1970s. I capitalize the first letter of entities.

" where 'Man' can represent the set or 'type' of all men (or women). Philosophers have what they call the "type token distinction. 19. an entity may have so many attributes that a diagram becomes unreadable. 19. as shown in the top figure (plumbers prepare pipes/pipes are prepared by plumbers)." and "Ellery Queen" are entity instances.2.1 Type/Occurrence Distinction Before proceeding. Page 46 of 94 . are illustrative. An entity type represents the class of objects that share a distinguishing factor.2. "Detective" is an entity type.Proper procedure is to label all relationships in both directions. Attributes and relationships." "Hercule Poirot. as shown in the bottom figure (seamen sail ships/ships are sailed by seamen). have types and occurrences. like entities. However.3 Attribute diagrams Attributes are diagrammed in several different ways or not diagrammed at all. Simple models. while "Sherlock Holmes.' If this argument sounds familiar to you.3. and 'Socrates' represents a single 'token' or occurrence of that set.). The distinction between type and occurrence is important for understanding the data modelling concepts of cardinality and modality. it is common practice not to place attributes on a diagram at all. For example. Some modellers place attributes in the entity box while others use ovals to hold attribute names: However. such as those above. The distinction between entity type and entity occurrence is the same as the distinction between record type and record occurrence. it might be because you studied a similar issue in your college philosophy class. In real analysis exercises. An occurrence is a single case or instance of a type. A more practical approach is to keep attributes out of the data model and in the data dictionary. 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. the distinction between an entity type and an entity occurrence or instance needs to be understood (“occurrence" and "instance" being interchangeable. many modellers place the relationship in a diamond. which are the two characteristics of relationships.

2. Cardinality is usually expressed as simply "one" or "many.' but an occurrence of 'B' can relate to only one occurrence of 'A. .' For example. tables always have positive-integer cardinality.2 Membership Class (Connectivity Characteristics) If entity 'A' relates to entity 'B. a mother can have many children. 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. 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.000. 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. the cardinality of the set of people in the United States is approximately 270.' For example. Cardinality can be finite (a non-negative integer) or infinite. and a wife can have only one husband (at least here in New Jersey). 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 .000. even though both sets are infinite.. while a parent can have many children. In theory. an uncle can have many nephews. The cardinality of the set of real numbers is greater than the cardinality of the set of integers. In tables. Thus." For example. For example. and a nephew can have many uncles. In practice. .. the cardinality of the set of integers is infinite. the cardinality of the set of real numbers is called aleph-one. tables with infinite cardinality can exist.' and an occurrence of 'B' can relate to only one occurrence of 'A.' knowing more about how the occurrences of 'A' relate to the occurrences of 'B' is important..' For example. One-to-many (1:N)--One occurrence of entity 'A' can relate to one or many occurrences of entity 'B. the number of rows is called the cardinality. One concern is the cardinality of the relationship. but a child can have only one mother. 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. however. a husband can have only one wife. The reason for this is simple: tables with no rows. . or with a negative number of rows.. a husband can have only one wife (in most cultures).' while an occurrence of 'B' can relate to one or more occurrences of 'A.19.  Many-to-many (M:N)--An occurrence of entity 'A' can relate to one or more occurrences of 'B. Page 47 of 94 . cannot exist.3. The cardinality of the set of integers is called aleph-null or aleph-nought.

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

a more accurate. an entity type is related to itself . When an entity type is related to itself. that is. Modality is a term from modal logic. nor do some allow.3 Degree Relationships can have any number of entity types associated with them. a bar for a cardinality of one. There may also be optional-optional relationships. The most common relationship is the binary relationship that links two entity types. Modality is. such as 'Customer Buys a Car from a Dealer. By now you have probably noticed that the bar specifying a cardinality of one can usually be inferred. the best practice is to specify the nature of the relationship in the relationship description.': This is a unary. While an optional optionality appears redundant. the relationship degree is called unary or recursive. or recursive relationship. This is an awkward and unfortunate use of the term because the optionality of a relationship could be either optional or mandatory. 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). a child can be related to another child through the relationship 'Sibling. because a cardinality of zero is impossible. then. the cardinality bar does serve a purpose. For example. Most data modellers use the term "optionality" instead of modality. is mandatory-optional. However. Note that many tool vendors do not require. This relationship. Because modellers do not always know the cardinality of a relationship. the relationship 'Banks Finance Cars' is optional-optional. they must have a way to distinguish not knowing from one. and there are cars that are not financed. it is not as bad as the seeming contradiction of a mandatory optionality.3. 19. and lessconfusing term than optionality.modellers usually refer to the "one" end of a one-to-many relationship first. in fact.2. because you can have a bank that doesn't finance cars. For example. In that case. N-ary relationships are those involving more than two entity types.': Page 49 of 94 . meaningful.

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

post codes and State names are the most specific types of domains.0). Ranges. The preceding article was written by George Tillmann who is a principal with New York-based Booz-Allen & Hamilton's Information Technology Group. Acceptable Values. and last names beginning A to J. Thus. The following figure shows how the topics discussed in this appendix relate to each other. non-negative values (for example. a domain hierarchy is created with the data type at the highest level and acceptable values at the lowest." In effect. What has been set forth in this article is just a cursory view of some rather complex notions involved in data modelling. suburbs. Page 51 of 94 . indicate which values between two end points are acceptable. such as street names. They specify the only values an attribute can have. real numbers between 0 and 4.  The entity-relationship (ER) approach to logical data modelling does not end here. such as dates between 1/1/1950 and 12/31/1967. the acceptable values for the Gender attribute would be "Male" and "Female.

vilspa.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. the identifier of the non-dependent entity becomes a primary/foreign key in the table generated by the dependent entity. 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. Independent one-to-one relationships In independent one-to-one relationships. 19. as shown below: Object in a CDM Attribute Entity Identifier Relationship Generated object in a PDM Column Table Primary or foreign key depending on independent or dependent relationship Reference Independent one-to-many relationships In independent one-to-many relationships. the identifier of one entity migrates as a foreign key to the table generated by the other. 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.iso.es/ida/pdm/pdmp6. as described by the Infrared Space Observatory (ISO) and should be used to aid further understanding of the detailed descriptions hereinafter.html Page 52 of 94 .19. 6 Source of definition is http://www.1 Overview This section describes the generation of the Data Archive Physical Data Model (PDM). Independent many-to-many relationships In independent many-to-many relationships.esa. the identifiers of both entities migrate to a join table as primary/foreign keys.3. A PDM represents the structure of the data as it will be implemented in the database.3 Physical Data Model6 19.

3.3 ISO Data Archive Physical Data Model – example: Page 53 of 94 .19.

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. 1. as their realisation will determine the outcome of the evaluation of success in the post-implementation review. unlike the project charter. 4. Section Contents I. The business case. expressed in terms of the functional area objectives that need to be met. Objectives should follow the “SMART” approach:  Specific  Measurable  Achievable  Realistic  Time-driven II. 3. PROJECT OBJECTIVES The statement of objectives specifies the outcomes sought to meet the business need described in Section 3. DOCUMENT CONTROL DETAILS  Author  Contributors  Revision Dates and descriptions DISTRIBUTION LIST ENDORSEMENTS AND APPROVALS 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. It is essential to define the objectives clearly. is a static document for reference in the post-implementation review to evaluate the success of the project. III. Ensure that the project‟s objectives are consistent with the objectives of the University as a whole. STATEMENT OF THE BUSINESS REQUIREMENT Explicit definition of the business need being addressed. Page 54 of 94 . 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.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.

If an implementation date is mandated that is not achievable with current resources. It is essential to ensure that the list of key project deliverables is complete. If the project sponsor cannot fund the cost. It is essential to obtain the approval of the project sponsor to the project scope. Each deliverable must be allocated specific completeness and correctness criteria that constitute acceptance criteria for the final product. etc. The project scope needs to be very specific in describing what will be produced. If the project sponsor does not sign-off on any one of time. if the scope seems unachievable within the available time and budget then in all probability it will be and the project will fail. KEY DELIVERABLES A detailed project plan will not be developed until the project manager begins work in earnest. cost or deliverables. but also the time and resources required to convert data from current systems. otherwise the project cannot succeed. cost and deliverables are inextricably interrelated. 6. short of completion. need to be identified as check points to evaluate the progress and quality of the project.5. MILESTONES & DEPENDENCIES Milestones at specific points in the project. doing more analysis of the underlying baseline assumptions and refining those assumptions. It identifies the deliverables required to meet the project objectives. then the project manager will need to work with the project sponsor to reconcile the scope and objectives and change the project charter accordingly. Deliverables need to include not only writing programs or implementing revised procedures and processes. how long it will take to deliver the specific outcomes. This can be achieved by any one of:    making changes to goals. whether manual or computerised. Time. objectives and/or deliverables changing the scope. PROJECT SCOPE The scope of the project specifies the activities and defines the boundaries of the work to be done. and how much it will cost to deliver those outcomes. to avoid waiting until the day before implementation to determine that the project is a failure or success. then deliverables will need to be reduced. This guides the further design of the system and the use of resources in its implementation and operation. but this section of the project charter must include a high level summary of that subsequent detailed plan. Page 55 of 94 . 7. then extra resources will need to be funded. Any omission will adversely impact the project cost estimates.

criticality. is required to do to support the business (i. reports. as interfaces to the new system. When requirements have been defined fully in the mapping and analysis of the business processes. including security needs. 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. which will assist in determining needs: The objective is to define what the system. etc. whether computer based or manual. documents. essential. accuracy. processes. in the form of a gap analysis. that support the project‟s scope and objectives. Document the business processes in a process map that represents the business activities that support the end-to-end process. procedures and business rules that are used to achieve the business objective If the requirement is for a totally new computer application. frequency. End users will insist on describing their wants. 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 . are stated separately from operational information needs. thorough analysis of to what extent the package does not meet the defined business needs.8. 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. identify those which are most appropriately handled by a computer application and those that are more effectively and efficiently kept as. manual systems. Management information requirements. is essential. timeliness.e. the use to which the information is put needs to be determined. in terms of functionality. then analyse the current system to see whether any of its components warrant retention. This will enable identification of data flows relevant to the information system. Based on analysis of the information gathered. desirable and nice to have. INFORMATION AND PERFORMANCE REQUIREMENTS This section details the proposed system‟s requirements. • • • • • • Gather relevant information about the business operations. It is essential to understand the University‟s business processes and business needs.. but it‟s essential to ensure all functions are prioritised. specify its functionality). or created as. including an analysis of the data that will need to be used to give the required information to the end-user.

and.22 APPENDIX C . the contingency margin in non-critical tasks can be determined. If tasks that are on the critical path are delayed and fail to meet their scheduled delivery date. There can be more than one critical path within an overall project. a sequence of tasks. which determines the Early Start (ES) and Early Finish (EF) dates for each task. therefore. Dupont and Remington Rand devised the Critical Path Analysis technique in the 1950‟s. therefore. This is the earliest possible time that the task can start and finish. A-B-C-E-F and A-B-D-E-F: 2 we eks C 3w ee ks A 3 weeks B 4 weeks ks 5 wee E 3 weeks F D The first calculation is the Forward Pass. Calculating the critical path The following example shows a project with two distinct paths. It is sometimes also called “critical path method (CPM). Page 57 of 94 . The contingency margin is the amount of time that a task can slip before it affects the end of the project. then the latest possible finish and start dates for each task (backward pass).Critical Path Analysis (CPA) The critical path is the longest path through the project from start to end. the end of the project will similarly be delayed. The critical path is. An example of a CPA is: Design Packaging Research Market Develop Packaging Package Product Design Product Produce Product Once the CPA calculation is finished. CPA is a mathematical model that calculates the earliest possible start and end dates for each task (forward pass). each of which must finish on schedule for the overall project to finish on time. becomes critical in it. to standardise the presentation of large projects. or just “arrow network”.

The critical path is shown above in the shaded circles (A-B-D-EF). 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 CE ES=5 EF=8 LS=9 3w ee LF=12 ks eks 2 we C A 3 weeks AB ES=0 EF=3 LS=0 LF=3 B 4 weeks BD ES=3 EF=7 LS=3 LF=7 5 wee ks E 3 weeks EF ES=12 EF=15 LS=12 LF=15 F D DE ES=7 EF=12 LS=7 LF=12 Upon completion of the forward and backward passes. the Late Start (LS). can be determined. then the Late Finish (LF) for each task. firstly. which determines. and the contingency margin/s. The contingency margin available is calculated as: Late Finish – Early Finish = Contingency Margin Page 58 of 94 .FORWARD PASS BC ES=3 EF=5 CE ES=5 3 w EF=8 ee ks eks 2 we C A 3 weeks AB ES=0 EF=3 B 4 weeks 5 wee ks E 3 weeks EF ES=12 EF=15 F D BD ES=3 EF=7 DE ES=7 EF=12 The second calculation is the Backward Pass. the critical path. The critical tasks are those where the early and late dates are the same.

The PERT chart is sometimes confused with a Critical Path Analysis (CPA). with lines joining them to show dependencies. The methodology represents project timelines graphically according to the following disciplines: Finish to Start Start to Start Start to Finish Finish to Finish Page 59 of 94 .23 APPENDIX D . for the Special Projects Office of the United States of America‟s navy.Program Evaluation and Review Technique (PERT) The PERT chart graphically displays tasks as boxes. 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. or nodes.

A PERT chart will appear as follows (in this instance specifically in Microsoft Project): Page 60 of 94 .

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

or to a team leader. The WBS is used to develop the work plan/project plan. 24. but it is not in itself a project plan. managing. A task can typically be assigned to one individual. Each phase (Initiation. below the Project itself. Stages are the best points to designate as project milestones for peer/third party quality assurance (QA) reviews. Each phase produces a set of major deliverables that feed into one or more future phases the overall project plan. 24. and should take no more than 40 work hours of effort to produce. There are four levels to WBS. The overall project work plan should be comprised of tasks. is a phase. since it includes only the tasks that are directed related to the output of deliverables. Page 62 of 94 . Planning. an activity produces a draft deliverable.2 Stage A stage is the largest logical unit of work within a phase.25 APPENDIX F . A task generally produces a part of a work product. In general. Generally. such as a knowledge base object. A stage groups a broad category of related work and serves as the primary mechanism for planning. and tracking project activity at the highest level. WBS is a decomposition of the work required to achieve the specific set of deliverables. etc) has its own set of goals and objectives.4 Task The lowest level of the work breakdown structure (WBS) is a task. 24.Work Breakdown Structure (WBS) The WBS is based on the deliverables that the work needs to produce. Activities provide the project manager with formal checkpoints for performing his/her own project quality reviews and other aspects of the project control process. a stage produces one or more final deliverables of the project. each of which produces one or more deliverables or a part of a deliverable: 24. or a part of a deliverable.1 Phase The highest level of WBS.3 Activity An activity groups a logical block of work that is smaller and more easily managed than a stage.

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 5.2.1 5.2.2 5.3 5.3.1 5.3.2 5.4 Advantages Disadvantages Advantages Disadvantages Advantages Disadvantages

Option 2

Option 3

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

premises. 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. training needs or other drivers. or costs avoided. 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. It is important that the benefits link back to the situational assessment and the key business drivers that led to the project being initiated. capital equipment ( both new. Operational savings This section describes all cost savings. consultancy or contract support. skills and resources required in Page 66 of 94 .change management. any pending or proposed system. Section 8 – Implementation timeline Describe the high level project timeline with key milestones and project checkpoints. systems and tools. etc. Section 9 – Project structure Describe the resulting sub-projects that stem from the overall solution. but ensure that adequate specific thought is given to particular risks to the particular project being initiated. 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. but specifies the skills required and the number of such skilled resources estimated to be needed. are taken into the economic justification section. If the project resource requirements cannot be met within current staffing. Benefits This section describes the quantitative benefits associated with the recommended solution. Sub-projects may be separated by process. including back-filling if staff are to be seconded to the project. or on. ensure that any and all estimated incremental staff costs. Functional Risk The impact of. associated with the realisation of the proposed project‟s objectives. The project timeline should reflect key steps in the approach and include major decision making milestones. organisational changes. the project structure does not address individual staff names. At this stage. and “sunk cost” of any capital equipment displaced if not fully depreciated).

Security. degree of complexity. magnitude of effort. Privacy and Audit Considerations Security aspects required. Technical Risk Level of experience.References & Related Documents Document Date Page 67 of 94 . time constraints for implementation. training resources and dependencies on external suppliers. These measures should be addressed in terms of the Standards Association of Australia‟s Business Continuity Management Guideline. ITCS. privacy and confidentiality of information being processed. and recommendations for the next steps. quality of estimating assumptions. Economic Risk Possibility and consequence of not achieving expected benefits. application development teams. Iterate key themes from each major section of the case as part of the executive summary and closing. Section 11 – Conclusions and Recommendations State the conclusions the reader should draw from the business case. 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. ease of measurement of those benefits.faculties. Section 12 . schools. audit requirements of the proposed system. and availability of ongoing funding.

27 APPENDIX H – Project Status Report format Distribution (position titles) ACTIVITIES DURING THIS PERIOD PROPOSED WORK FOR NEXT MONTH Matters Requiring Action Action required by (date) Action required by (person) Status at date Progress against Budget – Month to nn/nn 200x Original Budget Cost to date Revised Budget $ $ # DAYS $ DAILY RATE Budget remaining $ COST CONTRACT RESOURCE Progress against Project milestones Task Scheduled completion date Revised completion date Actual completion date Project completion Page 68 of 94 .

to ensure covered RESOURCE CONSTRAINTS Resource Absence Reason for absence Project Impact Remedial Action Page 69 of 94 .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.

Desirable or Nice to Have (N2H) Member of project team 9 Open. Closed Page 70 of 94 .28 APPENDIX I . Essential. Deferred.Issue Log format Issue No Sub-project element Summary description of issue Priority 7 Assigned 8 To Status 9 Scheduled completion date Actual completion date 7 8 Mandatory. Active.

Ensure that a strategy to support the project team members is in place. Negotiate ability to reject any proposed candidate on the basis of their experience or performance on the project. 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. disparate expectations among user base resulting in dissatisfaction upon implementation. Quality assurance reviews will return unfavourable reports. leading to a potential lack of decision making. Ensure that not quality assurance review delivers any surprises. 10 11 L = Likelihood C= Consequence Page 71 of 94 . Document specific success criteria and have them signed off. Develop the project plan as part of the project charter. The project MUST have a nominated Project Sponsor who is the ultimate decision making authority. Mitigation strategy Clearly document functionality to be delivered. The project should also have a steering committee comprised of the key stakeholders. Be very alert to any attempt to modify the scope of the original functional specification. as well as the project overall. Identify as many of the significant tasks of the project as possible and estimate the resources required. be sure to communicate the acceptance criteria for each deliverable. Ensure that the functional specification is signed off by every key stakeholder. 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 Backfilling of key business users is not planned for 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.29 APPENDIX J – Risk Management Schedule Risk Functional specifications not clearly stated L 10 C 11 Impact No specific success criteria. Project management structure not defined and agreed Confusion in the project as to roles and responsibilities. particularly by the project sponsor. Develop a detailed project plan as part of the project charter and identify any resource constraints.

Environments for development. Ensure that accommodation and support services. training and production need to be set up early in the project and procedures implemented that ensure that all of the environments are robust. Critical decisions are not resolved in a timely manner and impact the implementation date Mitigation strategy Try to avoid any and all part time assignments to the project team. are available for the project team. Ensure that a defined nomenclature is used to categorise documents. Page 72 of 94 . 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. 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. Set up a documentation directory structure that provides for simple shared access. including telephones and desktop computers. . 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. 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. Ensure that the key business users are identified and endorse the project charter.Risk To many part time resources on the project Key business stakeholders not identified L 10 C 11 Critical path through the project needs to be identified and maintained Decision making process is not clear Impact Tasks can not be completed in time due to conflicting priorities The project will have negligible support from the end-users. 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. 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. The register forms part of the overall management structure and options for outstanding issues will be brought before the steering committee meetings for resolution. testing.

parts of the revised business process prior to the implementation of the package. When the application goes into production there is significant user resistance to the package. 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. 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 Design is overly complex Issues are hard to uncover and end-to-end testing is complex putting pressure on achieving the implementation date. 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. Substantial business process re-engineering is adopted without reference to the impact within the business environment The quality of the design suffers. 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. Work with the business users to determine how on-line queries and standard reports can be used in conjunction to run the business. Mitigation strategy Use the application design phase of the project to identify any significant business issues.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. If there are complex workflows to implement then consider the potential of implementing these in phase 2 of the project. Evaluate the implementation of changed business practices to also reduce the reliance on „existing‟ business reports. Get stakeholders commitment to the BPR processes. Implement. Make business processes as easy to understand as possible. Ensure that key business users (and champions of the application within the business) are part of the user acceptance team. Page 73 of 94 . if possible. Existing business practices are not well understood and the capacity to implement changed practices not explored. Identify issues early.

Risk Design does not reflect business requirements L 10 C 11 Project team spends excessive time on non critical business processes Impact Implementation does not support required business processing and alternative systems and procedures are necessary to support the business. Ensure that a walkthrough of the end-to-end business process is undertaken with the specialist staff. Quality of the data is poor Volume of data More data cleansing and decision making is required to ensure project timelines are met May impact the ability to achieve the implementation date Agree on all output formats in the design process. Identify all data sources required to support the new environment. Ensure that the data migration tasks are started as soon as possible in the project plan. Business process design changes the dynamics of data capture and processing Pre-printed stationery not available in time for “golive” Design does not pay sufficient attention to the complete business process but concentrates primarily on the application aspects Size of the task is underestimated Although the business process works in theory it breaks down when it is tested in the field Potential to delay the implementation date if key data can not be transferred in time. Identify data quality issues as soon as possible after the commencement of the project Data loading may have to consider a phased approach. include stationery formats in actual documents produced by the system. 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 Mitigation strategy Ensure that the application design process produces a design that is understandable by the business users. Page 74 of 94 . Map data capture from input to output as part of functional design. It also needs to be signed of by the key business stakeholders Prioritise the functionality to be provided in the application. Identify issues of concern and raise these through the Faculty reference group. Identify those „must have‟ items and ensure the project plan delivers those for the implementation date. Key data to support daily business transactions first followed by historical data. wherever possible. In the case of multiple data sources estimate the degree of data cleansing and consolidation required.

The more problems that are identified in testing. Implement a set of processes to deal with the development and migration of functionality from the development to test and then production. 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. Ensure that a backup strategy is in place that allows the project team to return to a prior development without substantial outage time. 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. Develop and maintain an issue log. Ensure there is adequate support after implementation to deal with errors that arise out of the system interfaces. Poor management control of the various application environments Loss of progress due to having to recover previous environments Vendor experiences package problems Not all interfaces are identified If the problems are severe it may impact the implementation date. Encourage as much end to end and variance testing in the user acceptance testing period as possible. 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. Mitigation strategy Set up the development environment as soon as possible after project commencement. the longer the implementation phase will be. Depending on the degree of difficulty. The loss of an environment due to hardware or software corruption could have a significant impact on the project. Page 75 of 94 . End to end testing of bank tapes etc could involve a number of test runs.Risk Reliability of the development environment is poor L 10 C 11 Impact Delays the project. 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). 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. Functionality will be impaired and systems to which interfaces are required (in or out) will cease to provide correct results. Frustrates the project team.

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

As above. including status reports. Dysfunctional groups and cliques will form. issue log. Closely monitor the usage of external resources and provide regular Project Status Reports to the Steering committee. Also. Ensure each member of the project team has the skills appropriate to perform their assigned role. and when. and that there are sufficient staff to meet the scheduled delivery dates. Implement redundancy features within the hardware and software to support a high availability environment Elicit a variety of sources (software vendor. 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. only what they will need to know. Page 77 of 94 . change log. Ensure that all key participants have timely access to project information. Do not effect training too early. A crisis mentality will hang over the team most of the time and information will not be shared readily between team members. Informal communications are also very important. Wherever possible. or that the scheduled delivery dates are feasible within the available resources. hardware vendor and independent) to provide estimate hardware configuration to support expected volumes. Ensure that uncontrolled scope creep is not causing the overtime. Users lose confidence in the new application Production environment is not stable Capacity is exceeded soon after production User performance suffers and ability to process business transaction load may be questioned More funding is required or functionality reduced Project budget is underestimated Excessive overtime worked by project team Morale will suffer and the quality of work will deteriorate Lack of teamwork within the project team. certainly not “just in time” and do not train all users in all aspects of the system.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. Mitigation strategy Ensure that staff who need to be trained. etc. both core and extended Morale will suffer and the quality of work will deteriorate. in what. align each team member‟s role within the project with their own personal professional goals. do not assume that all team members accept the project‟s objectives and understand their role in delivering those objectives.

Page 78 of 94 . L 10 C 11 Impact The project deliverables will never meet the mercurial expectations of the project sponsor. Mitigation strategy Do not allow personal issues to cloud the project‟s objectives. Versions of the detailed plan will change dramatically and the project team will lose focus.Risk Failure to reach agreement between the project manager and the project sponsor. 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 Contact Details Document Version Control Version Date Details Written by Authorized By Page 79 of 94 .

.... Communications Plan Executive Summary ............................................................ 1 Stakeholder Communications………………………………………………………………..................................... 2.................................2 Training Strategies ........... 3 4...... 1 Marketing and Communication Strategies ........................................................TABLE OF CONTENTS 1......................... 2 Page 80 of 94 ....

Marketing and Communication Strategies a. Communicating Major Risks. Communications Plan Executive Summary 2. Issues and Changes Page 81 of 94 .1.

Training Strategies Stakeholders Stakeholder1 Stakeholder2 Stakeholder3 Training Required Format Timing Frequency Trainer Page 82 of 94 . Stakeholder Communication Stakeholders Method Message Timing Frequency Communicator 4.3.

000. Consider the three scenarios shown below (see table). each involving an initial investment of $1 million. a decent but not spectacular result. the investment's NPV is zero. Like NPV. The IRR is a fraction of a percentage point above 15%. for a net return of $500. 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. computes a break-even rate of return.000. IRR doesn't measure the absolute size of the investment or its return. and at 20% the project's present value is negative. but IRR is not as easy to understand as some measures and not as easy to compute. which may not be realistic. IRR is often used as a hurdle rate. the project has a present value of only $6. IRR is the flip side of net present value (NPV) and is based on the same principles and the same math. It's the break-even discount rate. essentially just breaking even. on the other hand. the rate at which the value of cash outflows equals the value of cash inflows. it assumes that the cash returned from an investment is reinvested at the same percentage rate. often your organisation‟s cost of capital. IRR provides a simple hurdle rate for investment decision-making. at that discount percentage. But if the company evaluates the same investment at 15%. 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). a sort of go/no-go investment threshold.000. A company evaluating this investment using cash flow discounted at 10% would compute an NPV of $137. 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. Page 83 of 94 . as classically defined.31 APPENDIX L – Internal Rate of Return (IRR) The following extract from a Computerworld article is a good summary of IRR. And because of the way the math works. IRR. Avoid a project if the IRR is less than the cost of capital or minimum desired rate of return. 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. The investment returns $300.000 (undiscounted) per year in each of the five years after the initial investment.

000 Discount rate: 20% Factor 1.572 0.000 0.000 +$300.870 0.000 IRR is often used as a hurdle rate.000 $172.000 $145. here a fraction of a percentage point above 15%. In this example.Internal Rate of Return: What It Looks Like12 Discount rate: 10% Year 0 1 2 3 4 5 Total Cash flow -$1 million +$300.000 $227.000 0.000 $205.751 0.000 $208.000 $121.683 0.621 Amount -$1 million $273.000 +$300. The NPV of the $1 million outlay depends on the discount rate. a sort of go/no-go investment threshold.694 0.658 0.000 $197.826 0.756 0.000 $225. with a net (undiscounted) return of $500.000 0.402 Amount -$1 million $250.000 $174.000 IRR = slightly more than 15% NPV = -$102.000 $149. or cost of capital. there is an initial investment of $1 million. The NPV is zero at the IRR.833 0.000 $186.000.000 $248. used to evaluate the investment.000 Factor 1.497 Amount -$1 million $261.000 +$300.000 +$500.000 Discount rate: 15% Factor 1.579 0.000 NPV = +$137.000 +$300. 12 Source: Computerworld Page 84 of 94 .909 0.000 NPV = +$6.482 0.

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

Net Present Value: What It Looks Like14
ATM installation Year 0 1 2 3 4 5 Discount factor (at 10%) 1.000 0.909 0.826 0.751 0.683 0.621 Total Cash flow -$1 million +$500,000 +$500,000 +$500,000 +$500,000 +$500,000 +$1.5 million Present value of cash flow -$1 million +$454,500 +$413,000 +$375,500 +$341,500 +$310,500 +$895,000 +$1.25 million +$904,000 Server consolidation Cash flow -$1 million +$1 million +$750,000 +$500,000 Present value of cash flow -$1 million +$909,000 +$619,500 +$375,500

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  More income-producing days per instructor or other customer facing personnel, such as support staff.

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 Delivering fee-based training and/or certification to students, and the ability to deliver more revenue-generating courses to more students

21.4

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

000-$250.000/$250. As a ratio Divide the return by the investment. $1.5 o o o Calculation of Return on Investment (ROI) Three data points are required: The time period over which the ROI is to be calculated (typically one year). to be gained from the proposed solution. They represent an additional category of soft benefits that should not be ignored in understanding the complete business impact of an eLearning solution.000)]/$250. 21.000)*12 months = (0. This is the total of the cost savings and revenue enhancements known.25)*12 = 3 months or 90 days Page 89 of 94 .Investment ROI = [(Payback . the ROI can be calculated as follows: Return = Payback ."  Individual Values o Individual values are benefits that are experienced at the individual learner level.000 in 12 months on a total investment of $250. Individual values include:  Timeliness of learning. in this example: [($1.000/$1. The return. Increased morale gained from simultaneous training o "We're no longer last on the up here in Malaysia. or reasonably estimated.000*100 = 300% 2.000 = 4:1 3. There are three ways to calculate the ROI: 1. etc.000. The investment.000.000 in the same time period. As a percentage.000. If you gain benefits equal to $1.000. weeks. As a time to break-even Determine the number of days. All costs directly attributable to the proposed solution and allocation of appropriate percentages of indirect costs. Time period to break-even = (Investment/Return)*Time Period ($250.Investment)/Investment)]*100. or months it will take to break even on the investment.

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. 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.g.. Setting investment screening thresholds (e. ROI is particularly effective at:    Facilitating investment prioritisation by making hard number comparisons between investment options.  Page 90 of 94 . allowing decision-makers to focus on the intangible benefits separately. For example.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.21. You may want to complement your ROI financial measures with other methods that address the key limitations of ROI metrics. ROI does not factor in risk and does a poor job accounting for intangible rewards.

Open Open Description Status Scheduled completion date 14/11/99 29/11/99 Actual Completion Date 071099 24 (c) 071099 24 DD CC FF GG HH/ DD CC FF Assigned to (initials) CC CC EE BB Open 29/11/99 Open (d) 29/11/99 CLOSED ACTION ITEMS Meeting (Date) 230999 250999 071099 230999 Item # 1 2 3 4 Description Status Scheduled completion date 07/10/99 07/10/99 24/09/99 01/10/99 Actual Completion Date 07/10/99 07/10/99 24/09/99 01/10/99 Review supplier issues regularly with relevant provider and present findings at weekly meeting Follow-up the status on screen format. Build product releases and upgrades into schedule Follow-up with supplier re keeping the old environment.34 APPENDIX O – Weekly Project Review Meeting Minutes . She cannot until she completes installation of Project Y What caused problems? How can ZZZ prevent recurrences? DD unable to prepare detailed report until she completes installation of Project Y.0 of XXX? Requires DD to participate in this action item. DD cannot participate in this documentation until she completes installation of Project Y. so that it becomes a repeatable and easily manageable procedure.Format Meeting Date Purpose of Meeting Participants Review the Acme Project Plan OUTSTANDING ACTION ITEMS Meeting (Date) 250999 071099 Item # 14 24 (b) Assigned to (initials) AA CC EE FF To develop a training navigation document template What are the environmental problems consequent upon the installation and configuration of the Acme environments and V2. Closed Closed Closed Closed 230999 5 KK Closed 30/09/99 30/09/99 NEW BUSINESS    Item 1 Item 2 Item 3 Page 91 of 94 . BB to discuss with third party provider Identify whether test system needs to be a refresh from backup or a full release. Ensure that installation and configuration process is documented fully.

either a specified class of faults or all possible faults. The hope is that. Software testing based on the knowledge of the types of errors made in the past that are likely for the system under test.  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. typical values. and error values. It has a beneficial side effect in pointing out incompleteness and ambiguities in specifications. just inside/outside boundaries. a test is an activity in which a system or component is executed under specified conditions. A test data selection technique in which values are chosen to lie along data extremes. the results are observed or recorded and an evaluation is made of some aspect of the system or component. in a systematic way. Testing where information about programming style. if a systems works correctly for these special values then it will work correctly for all values in between. a high-yield set of test cases that logically relates causes to effects to produce test cases. Synonymous with "heuristics testing" The application of test data derived from the specified functional requirements without regard to the final program structure. A testing technique that aids in selecting. 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. 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. Synonymous with "black-box testing" and "closed-box testing" Cause effect graphing Closed-box testing Equivalence class partitioning Error based testing Failure directed testing Functional testing 15 Source = IEEE (Institute of Electrical and Electronics Engineers) Page 92 of 94 .35 APPENDIX P – TESTING INFORMATION TECHNOLOGY APPLICATIONS Terminology15 In IT&T projects. Boundary values include maximum. and other programming knowledge is applied to select test data capable of detecting faults. minimum. error-prone language constructs.

test procedure and test report. test log. and any risks requiring contingency planning. Validation Protocol provides the test scripts and specific guidelines to prove the effective functional use of the software. and report test results. The period of time in the software development life cycle (SDLC) in which the components of software (developed or purchased) are evaluated and integrated. See test driver. See also test procedure. A test plan identifies test items. required resources. and the software is evaluated to determine whether or not requirements (functional specifications) have been satisfied. often. Documentation that specifies the details of the test approach for a software feature or combination of software features and identifies the associated tests. sometimes.Heuristics testing Test case See failure directed testing. A software module used to invoke a module under test and. See also failure directed testing. the features to be tested. See also test design and validation protocol. Types include test case specification. A chronological record of all relevant details about the execution of a test. responsibilities. Refer also:  Boundary value analysis  Cause effect graphing  Equivalence class partitioning  Error based testing  Functional testing Documentation that describes plans for. determines expected results. the testing of a system or component. Test case generator Test design Test documentation Test driver Test harness Test incident report Test log Test phase Test plan Validation protocol Page 93 of 94 . or data structure definitions and uses those inputs to generate test input data and. control and monitor executive. the testing tasks. predicted results. Documentation that specifies the scope. specifications. resources and schedule of intended testing activities. See test plan. test criteria. Synonymous with test data generator and test generator. or results of. Synonymous with test harness. A document that reports on any event that occurs during testing that requires further investigation. approach. A software tool that accepts as input source code. test incident report. and a set of execution conditions for a test item. Synonymous with test case specification. provide test inputs. Documentation that specifies inputs. test plan.

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

Sign up to vote on this title
UsefulNot useful