Project Management Methodology

Project Management and Systems Development Life Cycle Methodologies Information Systems

Fluttert, Pamela E 2/29/2012

Information Systems Project Management & SDLC Methodologies

Page | 1

Table of Contents Table of Contents .......................................................................................................................................... 1

Introduction .................................................................................................................................................. 3

What is a Project? ..................................................................................................................................... 3

What is Project Management? ................................................................................................................. 3

What is a Methodology? ........................................................................................................................... 3

How does the Systems Development Life Cycle (SDLC) Relate to the PM Life Cycle? ............................. 3

Why do we need a PM and SDLC methodology? ...................................................................................... 3

When should I use the formal PM methodology? .................................................................................... 4

Information Systems Methodologies ............................................................................................................ 4

PM and SDLC Life Cycle Methodologies Diagram ..................................................................................... 6

Information Systems PM Methodology Chart .......................................................................................... 8

Information Systems SDLC Methodology Chart ..................................................................................... 19

Appendix A: PM and SDLC Tool Kit ............................................................................................................ 26

Affinity Chart ........................................................................................................................................... 26

RACI: Identifying Roles and Responsibilities ........................................................................................... 27

Work Breakdown Structure (WBS) ......................................................................................................... 28

Prioritization Techniques ........................................................................................................................ 29

MoSCoW Analysis ............................................................................................................................... 29

Priority Scale ....................................................................................................................................... 29

Voting .................................................................................................................................................. 29

Priority Matrix ..................................................................................................................................... 30

Context Diagram ..................................................................................................................................... 30

Use Cases ................................................................................................................................................ 31

Fishbone Diagrams .................................................................................................................................. 32

Activity Diagram ...................................................................................................................................... 33

Process Flow Diagrams ........................................................................................................................... 34

Data Flow Diagram .................................................................................................................................. 36

State Diagram.......................................................................................................................................... 37

Data Model ............................................................................................................................................. 38


Page | 2

Entity Relationship Diagram (ERD) ...................................................................................................... 38

Class Diagram ...................................................................................................................................... 39

Data Dictionary ....................................................................................................................................... 40


Page | 3

Introduction

What is a Project? According to PMBOK1, “A project is a temporary endeavor undertaken to create a unique product, service or result. The temporary nature of projects indicates a definite beginning and end.”

What is Project Management? Project management (PM) is the application of knowledge, skills, tools and techniques to meet project requirements. Best practices within PMBOK list the 5 Process Groups within project management to be Initiating, Planning, Executing, Monitoring & Controlling, and Closing. The management of a project includes identification of requirements, balancing stakeholder needs/expectations/concerns, and balancing competing constraints (scope, quality, schedule, budget, resources, and risk).

What is a Methodology? A methodology is a collection of processes, methods, and tools for accomplishing an objective. It provides a checklist of key deliverables and activities to avoid missing key tasks. A Project Management Methodology is a roadmap for managing projects (the project life cycle). A Systems Development Life Cycle (SDLC) methodology is a roadmap for managing the life cycle of an IS implementation/upgrade (the product life cycle).

How does the Systems Development Life Cycle (SDLC) Relate to the PM Life Cycle? The SDLC is a product (information systems) life cycle that defines phases and specific activities to deliver the product. Project life cycles occur in one or more phases of a product life cycle (SDLC). Alternatively, one project life cycle may encompass multiple product life cycles. An example would be a major systems application, hardware and infrastructure upgrade that also includes an implementation of new functionality. Within the phases of this SDLC, there could be multiple projects: one for the hardware team, one for the infrastructure team and there could be separate ones for the upgrade and the new functionality. Alternatively, instead of multiple projects these could also be identified phases of one overall project with separate SDLCs to account for the new functionality and the upgrade.

Care should always be taken to distinguish the project life cycle from the product life cycle (SDLC) and to manage the integration between the two.

Why do we need a PM and SDLC methodology? The purpose of these methodologies are to provide a set of tools and templates to assist the Project Manager/Leader and Business Analysts or Functional Leads in reducing common risks associated with

1 A Guide to the Project Management Body of Knowledge (PMBOK Guide), published by the Project Management Institute


Page | 4

projects, and ensuring projects are executed more consistently. The information contained within the methodology should be adapted to individual projects, since each project is unique.

Charvat’s Matrix of selecting light or heavy methodology (based on time and complexity) is a recommended guideline for determining how much structure should be used for a project.

COMPLEXITY

Very high

high

medium

low

1-2 2-6 6-12 12-18 > 2yrs TIME(months)

Program

Small A Small B Small C

Medium A Medium B Medium C

Large A Large B Large C

As projects become more complex and span longer than 6 months, heavier methodology is warranted.

When should I use the formal PM methodology? A more formal project management process, as outlined in the methodology, should be followed when any of the following scenarios are met:

• Project funding is required • Resource commitment is greater than 30 person days • Significant impact at departmental and/or institutional level • Significant visibility at departments and/or institutional level • Significant risk is associated with the project

Information Systems Methodologies The University of Waterloo Project Management (PM) Life Cycle Methodology adopted for managing Information Systems projects consists of 5 process groups. These process groups serve as guidelines for appropriate project management, but inputs and deliverables will vary depending upon project size, complexity, timeline, and if it is in conjunction with an external vendor.

1. Initiation: processes that define the project and obtain authorization to begin 2. High Level Project Planning: processes that establish scope, and objectives, and perhaps course

of action 3. Detailed Project Planning: processes that focus on course of action – may be combined with

high level project planning process group for small projects


Page | 5

4. Execution and Control: processes to complete the work, track & regulate progress/performance, identify required changes and initiation of required changes

5. Closure: processes to finalize all activities across all process groups and formally close the project

Within the Planning Process Group management of time, scope, procurement, risk, communications, human resources, and quality are essential.

These processes can be iterative throughout the project. The output of one process is typically an input to the next process, or is a project deliverable.

The University of Waterloo Systems Development Life Cycle SDLC methodology adopted for implementing Information Systems products consists of 5 phases:

1. Analysis & Requirements: define project goals into defined functions and operations by determining requirements and analyzing end-user information needs. Project initiation processes have already been put into place, or are in progress (business cases, feasibility studies, cost/benefit analysis, risk management, high level planning)

2. Design & Development: Translate requirements and business needs into a design of desired/required features and operations and code/develop the design(s)

3. Test: test the development pieces and test the integration of all of the development pieces together to check for errors, bugs, missing requirements and interoperability

4. Implementation : the software is put into production (deployed) and runs the actual business process(es)

5. Maintenance: handles what happens during the rest of the software’s life (changes, corrections, additions, enhancements, infrastructure enhancements, etc)

Traditionally, the SDLC has followed a waterfall or gated approach. Depending upon the project, this may be somewhat adapted into an iterative or incremental approach. These adaptations will occur if the project is broken into its own phases, or if prototyping is introduced. A description of these approaches is below.

Waterfall/gated: This approach is typically used when the project has a well-defined scope, small risk, and minimal feedback cycles are required throughout the life cycle. This approach requires sign off for the entire project scope at each phase of the life cycle. This approach may work for small, tried-and-true projects such as applying a bundle, but it does not typically work for larger projects.

Iterative: This approach is typically used when the scope is somewhat fuzzy and clear requirements aren’t available, or there is a high risk of requirements changing. It is waterfall-based but captures user feedback earlier with modeling techniques (eg screen mock ups) appropriate for the project. It is still a “big bang” approach where everything goes live at once.


Page | 6

Incremental: This approach prioritizes solution features and builds the solution in order of priority. It allows for a phased approach to implementation where the highest priority features are implemented first (although the option still exists to go live with all phases at once, if desired), reducing project risk and increasing quality while still accommodating significant changes throughout the project.

Agile: This approach incorporates both iterative and incremental. More information about Agile will be available in the future.

To determine the approach that should be used, one should ask whether the process is driven by frequent feedback, if the delivery should be “big bang” or phased, if a lot of change is expected, and if the project will invest heavily in quality. Regardless of the approach, the phases of the systems life cycle still include analysis/requirements, design/development, testing, implementation and maintenance.

PM and SDLC Life Cycle Methodologies Diagram The following diagram illustrates the methodologies and provides a list of potential deliverables within each process group (PM) and phase (SDLC). The deliverables will ultimately depend upon the characteristics of the project.


Page | 7

POSSIBLE DELIVERABLES:q Requirements Documentq Current business processes q Fit/Gap

POSSIBLE DELIVERABLES:q Development Strategyq Standards and Proceduresq Design Specifications and

sign offsq Development and

development testing sign offs

POSSIBLE DELIVERABLES:q Test Strategyq Test Scripts/Plans/Scenarios

and Sign Offsq User Acceptance Testing

(Integration Testing) scripts and sign offs

POSSIBLE DELIVERABLES:q Cutover Plan/Scheduleq Contingency Planq User Documentationq New business processes

(documentation, flow diagrams, etc)

q Training documentationq Quality Assurance and

migration of developmentq Go Live Readiness Risk

Assessmentq System/Software

POSSIBLE DELIVERABLES:q Standards/procedures for

reporting/tracking issues and changes

q Support Strategyq Fixes and enhancements

Analysis & Requirements

Design & Development Test Implementation Maintenance

POSSIBLE DELIVERABLES:q Feasibility Study q Business Caseq Project Charterq Project Governance

POSSIBLE DELIVERABLES:q RFIq RFPq Project Management Plan

POSSIBLE DELIVERABLES:q Project Kick-Off Meeting q Project Scheduleq Risk Register/Chart q Implementation Plan

POSSIBLE DELIVERABLES:q Logged issues/requests and

changes q Updated Project Management

Planq Updated Project Scheduleq Status Reporting and Project

Reviewq Trainingq Communicationsq Risk assessments and

responses

POSSIBLE DELIVERABLES:q Client Sign-off q Post-Project Review q Maintenance plan q Satisfaction Assessment

Project Initiation High Level Project Planning

Detailed Project Planning

Project Execution and Control Project Closure

Information Systems Methodologies forProject Management Life Cycle (PM)

& Systems Development Life Cycle (SDLC)

Approved CharterP

M

PROCESSES

SDLC

PHASES

The project (PM) life cycle manages one or more product (SDLC) cycles


Page | 8

Information Systems PM Methodology Chart Please refer to the chart below for further information concerning the deliverables and guidelines within each process group of the PM Methodology. The chart will also include links to the deliverable templates.

In addition to the deliverables on the chart, please refer Appendix A: PM & SDLC Tool Kit for a list of tools that can be used to produce the deliverables.

Chart Roles:

A number of “roles” have been identified for the chart. These roles are not meant to provide an exact match to University position titles, job descriptions or career path descriptions. These roles summarize a set of responsibilities that may fall under a particular role for an IS project. One person may be responsible for more than one role on the project, or the responsibilities within a role may be performed by more than one person on the project.

1. Project Manager role: overall responsibility for the successful planning, execution, monitoring, control and closure of a project. 2. Sponsor role: responsible to the University for the success of the project by providing the authority and credibility for the change (ie: the

project’s “champion”). This may be a person or a project Management Team or a project Steering Committee 3. Project Lead role: provide task and technical leadership towards executing the tasks on the project schedule and plan 4. Developer role: responsible for code design, documentation and development for the project 5. Business Analyst role: liaisons between stakeholders to assess business models and their integration with information systems by

gathering business requirements, assisting in Integration and Acceptance Testing, supporting the development of training and implementation material, participating in the implementation, and providing post-implementation support to the customer community

6. Subject Matter Experts role: members of the customer community who are identified and made available to the project for their subject matter expertise. These experts may be on the project due to their expertise in a particular business process or policy, or they may be on the project for other areas of expertise such as training, user documentation or communications.

Init

iati on

Project Charter Created by: Project Manager

Reviewed by: Business Analyst

Approved by: Sponsor

Requirement: If formal project

Template available


Page | 9

Project Lead (possibly) Subject Matter Experts (possibly)

management is to be used, a charter should always be created since it formally authorizes a project or phase. Some sections of the charter may not be necessary for smaller projects.

Guidelines: 1. The charter should clearly identify a technical or business problem/need for the project 2. Is the timeline reasonable? Are the milestone dates reasonable? 3. Ensure the risk, assumptions and constraints are complete with what is known at the current time 4. Inputs for the charter can include: statement of work, business case, feasibility study, contract, enterprise

environmental factors, and organizational project assets 5. Have business impacts to other departments been identified and their roles included? 6. Ensure you have identified all stakeholders (external and internal) before completing the charter and their

wants/needs are clearly understood 7. IS has made the decision that formal signatures will not be required on charters. However, approval of the

charter should be clearly documented and referred to within the approval section. 8. High level requirements (identify in simple terms what is needed) are usually available when the charter is

created Feasibility Study

Created by: Project Manager and/or Business Analyst

Reviewed by: Business Analyst Project Lead (possibly) Subject Matter Expert (possibly)


Requirement: Only required if assessing the cost vs value of proposed

Template Available


Page | 10

products and/or services

Business Case Created by: Project Manager and/or Business Analyst


Approved by: Sponsor and possibly higher up

Requirement: Only required if need to capture the reasoning for beginning a project in order to gain approval

Template Available

Project Governance

Created by: Project Manager

Reviewed by: Business Analyst Project Lead (possibly)


Requirement: Project Governance should be documented somewhere for every project. This may be documented in a central location for Project Teams that work on a number of projects, or it could be contained within a Project Management Plan for large projects or the project may be small enough to

Examples: HRMS Project Procedures HRMS Project Roles & Responsibilities

https://info.uwaterloo.ca/infohrms/TeamArea/Administration/index.html


https://info.uwaterloo.ca/infohrms/contacts.html




Page | 11

document project governance within a charter.

Guidelines: 1. Project governance provides a comprehensive, consistent method of controlling the project and ensuring

its success (PMBOK) 2. Governance must include decisions on who will be involved (who are the members of the project team),

what resources are necessary (roles and responsibilities) and the general approach to completing the work. 3. Governance should provide structure around how often project team meets, who chairs the meetings, the

purpose of the regular meetings. The same should be established for any other teams required for the project (management/steering committees, focus groups, etc).

4. Governance should include how communications are handled amongst team members 5. Procedures to be followed amongst team members (eg. How change requests are documented, migration

of development projects to production, how testing is documented, how sign offs are recorded, etc) 6. Any templates that are used for the project should be identified within the project governance 7. Where project information and documentation will be stored and how it will be communicated beyond the

project team and to who 8. If the project is to be broken into phases, the phase structure should be documented and how each phase

will be reviewed and signed off

High

Lev

el P

roje

ct P

lann

ing

Project Management Plan




Requirement: For larger, more complex projects this document is a requirement, although some of the sections may not be applicable.

Template Available

Guidelines:


Page | 12

1. This document is the high level document summarizing project governance. 2. A project management plan is not a schedule/timeline. Best practices in the project management field

advise separate plans for project procurement management, project risk management, project communication management, project human resource management, project quality management, project cost management, project time management, project scope management, project integration management which comprise the 9 project management knowledge areas in PMBOK. For some of our projects, it is sufficient to include this information within one comprehensive Project Management Plan, although there will be projects where specific knowledge areas require expansion into their own plan.

3. Use the information in the project charter as input into the Project Management Plan. Feasibility studies and Business Cases may also be used, if applicable.

4. This document is a living document and should be updated as things change through the project. Changes should be documented in a revision history section.

5. Analysis of the stakeholders is important during this process to determine their authority over project activities, their influence on project and deliverables, and their attitude towards the project (see Appendix A: PM & SDLC Tool Kit for a sample affinity chart that can be used to analyze stakeholders)

Request for Proposal (RFP)



Approved by: Sponsor Procurement

Requirement: Required according to Policy 17 guidelines (see Policies and Guidelines on Procurement site)

Template available

Guidelines: 1. Verify with Procurement whether it is up to date in terms of legal language 2. Ensure all technical feedback is acquired (eg. App Admin group, DBA, Windows, Networking, Security, etc) 3. Ensure requirements are stated precisely and use terms such as “must” and “should” correctly 4. Allow for RFP to be posted for at least 10 business days for responses 5. Include specific criteria for evaluating responses 6. Specify the form of response bidders are to submit 7. Avoid the use of vague terms such as “reasonable time”, “quickly”, “easily”


Page | 13

Outline of Process:

1. The RFP should be reviewed and approved by both the project’s Management/Steering Committee, and Procurement

2. Procurement will then assume ownership of the process and will post the RFP for responses. All responses will be collected by Procurement

3. An Evaluation Committee will be struck. It will be comprised of individuals responsible for evaluating responses according to the specified criteria in the RFP. Each member will be responsible for filling out a scoresheet, signing the scoresheet and returning it to Procurement.

4. Short list the vendors based on their evaluations. Procurement will contact these vendors and invite them for a demo

5. Choose the vendor. Procurement will notify the selected bidder, and the ones who are not selected. Guidelines for Contracts:

1. Look for escrow clauses to ensure that the source code is available to the University if the vendor should become bankrupt, etc.

2. Ensure there is a clause indicating that the vendor can’t hire University project staff during or for a duration following the project, and vice versa

3. Ensure there are clauses for how the agreement can be terminated, if required 4. For consulting agreements, the University does not pay for services that have not been performed so

ensure the payment schedule reflects this. 5. Look at what was stated in the RFP and ensure it is included in the contract 6. If the vendor must spend time on site, reference to the University’s travel guidelines/policies should be

included in the contract 7. Negotiation on any caps on fee increases at the expiration of the contract if there is potential renewal is

recommended 8. If a hosted solution is within the contract, there should be a statement about vendor’s disaster recovery

and business continuity plans in the case of a disaster or pandemic. Recovery time objectives (RTO) and recovery point objectives (RPO) should also be included

9. There should be wording for any conditions or warranties, if applicable, and what happens if not met 10. Wording concerning breach of contract should be included

Request for Created by: Reviewed by: Approved by: Requirement: Template


Page | 14

Information (RFI)

Project Manager Business Analyst Project Lead (possibly) Subject Matter Expert (possibly)

Sponsor Procurement

Not always required

available

Deta

iled

Plan

ning

Project Schedule


Reviewed by: Business Analyst Project Lead Developer Subject Matter Expert Sponsor

Approved by: Usually no formal approval required. If there is an approval, it would be by Sponsor

Requirement: All projects require a schedule. The complexity of the project drives how complex the schedule becomes

Guidelines: 1. An initial schedule should be stored as a baseline and should not change for the duration of the project.

For larger projects, this could be included in the Project Management Plan. 2. Many different tools have been used to create schedules (MS Project, Excel, etc) 3. The schedule will change through the duration of the project and must be kept up to date (changes can be

due to resources, risk triggers, scope changes, etc) 4. The tool and schedule must account for:

a. Resource availability on the project b. Task dependencies c. Non-flexible, fixed dates d. Clearly identified milestones e. Clearly identified critical path (the longest chain of tasks based upon task dependencies) f. Realistic dates g. Priority of tasks in relation to other tasks h. Optimization around the least available resources i. Eliminate concurrent multi-tasking as much as possible for maximum resource productivity (ie:

allow the resources to finish one task before starting another as much as possible). j. Use caution when padding task durations – this increases overall project lead times and when

tasks do finish early, subsequent tasks don’t always benefit. Parkinson’s Law advises resources be


Page | 15

provided with the least possible time because they will use all of the possible time and still do their work at the last minute.

k. Once the schedule has been optimized around critical resources, buffers can be added for resource, capacity and project phases. This can be accomplished by using buffers at the end of a series of tasks – allows emphasis to be placed on managing the buffer instead of individual task start and end times

l. Strategically place “buffers” to minimize the domino effect of minor schedule fluctuations on scheduled activities and least available resources

m. Make it your business to determine if resources are working on other projects and if timelines conflict with your project. Build in buffers to account for this.

Project Kick-Off Meeting


Reviewed by: Subject matter for the kick off meeting should be reviewed with Business Analyst Project Lead (possibly)

Approved by: No formal approval required

Requirement: This is strongly advised

Guidelines: 1. Introduce the project team members and the project. Review project objectives and project management

approach 2. Emphasize milestones and dates 3. Depending on the size of the project and the team, some of the project governance items may be covered

during the kick-off 4. Roles and responsibilities should be stated clearly 5. If possible, the Sponsor should attend 6. Project stakeholders should be assessed to determine which ones should attend 7. Minutes should be clearly documented and available. If there is a presentation, it should be published

Implementation Plan




Requirement: Only for large projects with significant roll out training and communication impacts

Template Available


Page | 16

Risk Register Created by: Project Manager



Requirement: Yes, for larger more complex projects this is required and risks should be assessed on a regular basis, especially right before a go live

Template Available

Proj

ect E

xecu

tion

& C

ontr

ol

The processes within this process group would not result in new deliverables. However, constant monitoring and updates to previous deliverables will be required during this time. It is strongly recommended that projects have templates for status update meetings that clearly identify status, issues, and action items. The action items should have somebody assigned to them. Attendees for each meeting should be listed and the date of the meeting. These minutes should be posted so they are accessible by all attendees and other possible stakeholders as well. A suggested template for a status update meeting is available. If the project is large enough to warrant a Project Management Plan, changes to scope, etc. can be documented in that plan and logged in the Revision History section during the execution of the project. Otherwise, changes to scope, etc. should be clearly documented in meeting minutes, etc. and accessible by Project Team members.

Proj

ect

Clos

ure

Client Sign Off Created by: Business Analyst Subject Matter Expert (possibly)

Reviewed by: Project Manager

Approved by: No formal approval of the sign off required

Requirement: Yes


Page | 17

Guidelines: A project requires sign off by the Functional Lead(s). This should be recorded where it can be accessed at any point in time. ACE Project is an example of a tool that can be used to record sign off. Sign off at the end of all testing should be recorded (before cutover), as well as sign off after cutover where it is stated that cutover was successful and everything works as it should.

Post-Project Review


Reviewed by: Business Analyst Subject Matter Expert (possibly) Sponsor Project Lead Developer


Requirement: Yes

Guidelines: 1. A post project review (sometimes referred to as a post mortem, project closure or lessons learned) should

be completed and documented. 2. Lessons learned should be documented – these should include both positive and negative items 3. For larger projects, a lessons learned review may be scheduled at the end of each phase so that items

aren’t missed by the end of the project 4. Every lesson learned should include impact and recommendation for future projects 5. Items for discussion: project management and scheduling evaluation, resourcing evaluation, testing

evaluation, communications evaluation, team/organization evaluation and cutover evaluation 6. This review can and should be used for future projects


Page | 18

Maintenance Plan


Reviewed by: Subject Matter Expert Business Analyst Developer Project Lead Sponsor (perhaps)


Requirement: For projects that result in an implemented IS, some type of documentation on how this system will be maintained should be prepared

Optional Template available or Some other examples: (HRMS Project Procedures HRMS Project Roles & Responsibilities)

Guidelines: A Maintenance Plan should:

1. Define the support environment infrastructure 2. Define the support environment roles & responsibilities, and maintenance activities 3. Describe how the system will be monitored for performance and how modifications will be made 4. Identify the support environment development & migration procedures 5. Identify any standards that are to be followed

Satisfaction Assessment


Reviewed by: Project Lead Business Analyst Subject Matter Expert Developer (possibly)


Requirement: Not required but recommended for highly visible projects

No templates since this can take different formats (feedback from focus groups, surveys, etc.)







Page | 19

Information Systems SDLC Methodology Chart Please refer to the chart below for further information concerning the deliverables and guidelines within each phase of the SDLC Methodology. The chart will also include links to the deliverable templates.

In addition to the deliverables on the chart, please refer Appendix A: PM & SDLC Tool Kit for a list of tools that can be used to produce the deliverables.

Chart Roles:

A number of “roles” have been identified for the chart. These roles are not meant to provide an exact match to University position titles, job descriptions or career path descriptions. These roles summarize a set of responsibilities that may fall under a particular role for an IS project. One person may be responsible for more than one role on the project, or the responsibilities within a role may be performed by more than one person on the project.

1. Project Manager role: overall responsibility for the successful planning, execution, monitoring, control and closure of a project. 2. Sponsor role: responsible to the University for the success of the project by providing the authority and credibility for the change (ie: the

project’s “champion”). This may be a person or a project Management Team or a project Steering Committee 3. Project Lead role: provide task and technical leadership towards executing the tasks on the project schedule and plan 4. Developer role: responsible for code design, documentation and development for the project 5. Business Analyst role: liaisons between stakeholders to assess business models and their integration with information systems by

gathering business requirements, assisting in Integration and Acceptance Testing, supporting the development of training and implementation material, participating in the implementation, and providing post-implementation support to the customer community

6. Subject Matter Experts role: members of the customer community who are identified and made available to the project for their subject matter expertise. These experts may be on the project due to their expertise in a particular business process or policy, or they may be on the project for other areas of expertise such as training, user documentation or communications.

An aly

sis Requirements

Document Created by: Business Analyst

Reviewed by: Project Manager

Approved by: There may be

Requirement: Required for

Template available


Page | 20

Subject Matter Expert Project Lead

a formal approval by Sponsor

any IS project

Guidelines: 1. Requirements can stem from market demands, business needs, customer requests, technological

advances, legal/regulatory changes and social needs 2. Detailed requirements remove uncertainty as to how the system will accomplish the task 3. Proper requirements are:

• Cohesive (specifies only one thing at a time) • Complete (self-contained, defining all situations that can be encountered and the appropriate

response for each) • Consistent (should not contradict other requirements and should not be repeated elsewhere • Correct (mistakes in a requirement definition will result in a defective solution) • Feasible (must be possible given system and project constraints) • Mandatory (although requirements can have relative priority, they must all be “required”) • Modifiable (if a change to a requirement is necessary, it should be expressed such that it is

traceable) • Unambiguous (avoid words like “more”, “less”, “fast”, “slow”) • Testable (should be possible to design a test to determine if requirement has been met)

4. Types of requirements include: • Business requirements (high level, measurable statements of goals, objectives or needs of

the University) • Stakeholder requirements (statements of the needs or particular stakeholder or class of

stakeholders • Solution Requirements (describe characteristics of a solution)

i. Functional Requirements (describe behavior and information the solution will manage)

ii. Non-Functional Requirements (describe environmental conditions under which the solution must remain effective or qualities system must have – speed, security, availability, etc)

• Transition requirements (capabilities to facilitate transition from current state to the desired


Page | 21

future state – data conversion, skill gaps, training, etc) 5. Business rules are the foundation for most requirements (policies, guidelines, legislation, etc) 6. Documenting requirements can be very complex. It may be appropriate to use a variety of tools such

as Use Cases, flow diagrams, etc. Current Business Processes

Created by: Business Analyst

Reviewed by: Project Manager (possibly) Subject Matter Expert Project Lead

Approved by: Subject Matter Expert

Requirement: Depends on project

Guidelines: 1. Business processes are a collection of interrelated tasks which accomplish a particular goal. These are

typically represented with a diagram (process flow (see Appendix A: PM & SDLC Tool Kit) is the most typical)

2. A business process can be decomposed into sub-process(es) 3. Business processes are designed to add value for the customer and should not include unnecessary

activities. 4. Documentation should include the process flow diagram, a description of parent business activity/process

(if applicable), a text description of the process, triggers, inputs, outputs, and particpants 5. The current business processes model becomes the baseline model and is the starting point for

documenting changes to the business process(es). The following information is required to document the baseline:

• Desired outcome of the process • Start and end points (customer need and customer need fulfillment) • Activities to be performed • Order of activities • People who perform the activities • Documents and forms used and exchanged between functions and from customers and suppliers

Fit/Gap Created by: Business Analyst

Reviewed by: Project Lead Project Manager (possibly) Subject Matter Expert

Approved by: No formal approvals required

Requirement: Usually required, especially for vendor-purchased apps

Template Available


Page | 22

Desi

gn &

Dev

elop

men

t

Development Strategy

Created by: Project Lead

Reviewed by: Project Manager (possibly) Developer Business Analyst (possibly)


Requirement: highly recommended

Examples: HRMS 9.1 Upgrade and HRMS Project

Standards & Procedures

Created by: Project Lead

Reviewed by: Project Manager (possibly) Developer Business Analyst (possibly) These standards and procedures may involve other groups such as Application Administrators, Database Administrators, Network Administrators, Hardware Administrators, and Security Administrators


Requirement: Yes

Examples: Developer’s TechZone HRMS Project SISP

Design Specifications and Sign Offs

Created by: Project Lead and/or Developer

Reviewed by: Business Analyst Subject Matter Expert (possibly)

Approved by: Business Analyst

Requirement: Yes for any development

Examples: SISP HRMS Project

Development and development testing sign offs

This is not a document deliverable, but the development and sign off is a deliverable of the product life cycle. All development should be thoroughly tested by developers before migrating it to a test database for functional users to test. Some projects use task tracking such as ACE Project to record sign offs with status updates. Examples of project development testing guidelines and use of software to track status and sign offs:

• HRMS development testing guidelines and HRMS ACE Project process flow

Test

Test Strategy/ Procedures

Created by: Project Lead and/or Business Analyst

Reviewed by: Business Analyst Subject Matter Expert (possibly)


Requirement: Highly recommended

Examples: HRMS Project and HRMS upgrade

https://info.uwaterloo.ca/infohrms/TeamArea/Application/ReferenceDocs/HRMS9.1/HCM9.1%20Test%20Strategy.pdf


https://info.uwaterloo.ca/infohrms/TeamArea/Administration/Procedures/DevelopmentTesting.html#Development

https://ist.uwaterloo.ca/internal/at/index.html



https://sharepoint.uwaterloo.ca/sites/SISP/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2Fsites%2FSISP%2FShared%20Documents%2FSISP%20Project%20Templates&FolderCTID=0x0120006D2C32DE785F6641BA27D102B3F1E342&View=%7bB3A28CF7-DEDC-46F9-8788-1EA07B153827%7d


https://info.uwaterloo.ca/infohrms/TeamArea/Specifications/index.html

https://info.uwaterloo.ca/infohrms/TeamArea/Application/ReferenceDocs/TechSupport/DeveloperTestingGuidelines.html

https://info.uwaterloo.ca/infohrms/TeamArea/Administration/Procedures/ACE%20Project%20flow.pdf

https://info.uwaterloo.ca/infohrms/TeamArea/Administration/Procedures/DevelopmentTesting.html#TestProcedures




Page | 23

Test Scripts/ Plans/ Scenarios and Sign Offs


Reviewed by: Subject Matter Expert Project Lead (possibly)

Approved by: Business Analyst and/or Subject Matter Expert

Requirement: Yes

Examples: HRMS Project SISP

User Acceptance (Integration) Testing Scripts


Reviewed by: Subject Matter Expert

Approved by: Business Analyst and/or Subject Matter Expert

Requirement: Yes

Examples: HRMS Project SISP

Go Live Readiness Risk Assessment (Go/No Go risk assessment chart)


Reviewed by: Business Analyst Project Lead Subject Matter Expert (possibly)


Requirement: Yes, for any project large enough to warrant formal project management

Template Available

Impl

emen

tatio

n

Cutover (Implementation) Plan/Schedule

Created by: Project Lead or Project Manager

Reviewed by: Business Analyst Subject Matter Expert (possibly) Developer (possibly) Sponsor (possibly) This may involve other groups such as Application Administrators, Database Administrators, Network Administrators, Hardware Administrators, and Security Administrators


Requirement: Yes, for any large implementation with any significant risk where implementation requires many people and activities






Page | 24

Contingency Plan Created by: Project Lead or Project Manager

Reviewed by: Business Analyst Subject Matter Expert (possibly) Sponsor (possibly)


Requirement: Yes, for any large implementation with significant risk

User Documentation

Created by: Business Analyst Subject Matter Expert (possibly) Project Lead (possibly) System documentation (Entity Relationship Diagrams (see Appendix A: PM & SDLC Tool Kit), for example) could also be created by Developer

Reviewed by: Varies by project

Approved by: No formal approvals required.

Requirement: Yes for any large implementation that will be used by multiple people

New Business Processes

See Current Business Processes Section under Analysis & Requirements phase.

Training Documentation

Created by: Business Analyst Subject Matter Expert (possibly)

Reviewed by: Project Lead (possibly) Subject Matter Expert




Page | 25

Quality Assurance and development migration

Quality assurance and migration of development procedures will vary by project and product. Quality assurance standards and measures should be documented, QA sign offs should be documented and migration of the development should be documented. Examples:

• Developer’s TechZone • HRMS Project

System/ Software

This is not a document deliverable, but the final product is a deliverable of the life cycle.

Mai

nten

ance

Standards/ Procedures for Reporting & Tracking Issues and Changes

Created by: Project Lead Project Manager (possibly)

Reviewed by: Business Analyst Subject Matter Expert (possibly) Developer (possibly)



Examples: HRMS Project SISP Change Request Template Available for a Change Request

Support Strategy Created by: Project Lead

Reviewed by: Business Analyst Subject Matter Expert (possibly) Developer (possibly)



Examples: Support & Relationship Governance with Pension vendor


https://info.uwaterloo.ca/infohrms/TeamArea/Administration/Procedures/DevelopmentTesting.html#QA

https://info.uwaterloo.ca/infohrms/TeamArea/Administration/Procedures/SubmittingRequests.html







Page | 26

Appendix A: PM and SDLC Tool Kit There are many different modeling techniques that can be used during the Project Management and Systems Development Life Cycles. This appendix briefly describes some of the more widely used modeling techniques. More information can be acquired through the web, through the Business Analysis Body of Knowledge (BABOK), and from the Project Management Body of Knowledge (PMBOK).

The following chart may assist with identifying suitable modeling techniques for different types of information:

Process Models Data Models State Transition Diagrams

Use Cases

People Concepts Rules Events Processes

In addition to the modeling techniques listed in the chart, this appendix also includes additional tools that can be used by the Project Manager.

Affinity Chart An Affinity Chart/Diagram helps to synthesize large amounts of data by finding relationships between ideas. The information is structured from the bottom up into meaningful groups. They can be used to draw out common themes from a large amount of information, discover previously unseen connections between various ideas or information, or to brainstorm root causes and solutions to a problem. The power of the affinity chart/diagram is its ability to find common threads that link groups of ideas together.

Steps to create an Affinity Chart/Diagram:

1. Post issue or scenario in the room 2. Brainstorm 3. Post output for all to see 4. Group ideas into natural groupings 5. Label each group 6. Document finished chart/diagram


Page | 27

RACI: Identifying Roles and Responsibilities RACI is a straightforward charting tool that can be used to identify roles and responsibilities within a project, often used for risk management. Sometimes RASCI is also used. This abbreviation stands for:

• R = Responsible: owns the problem/project • A = Accountable: who whom ‘R’ is accountable (ie: must sign off/approve on work) • (S = Supportive: can provide resources or play a supporting role in implementation – OPTIONAL) • C = Consulted: has information and/or capability necessary to complete the work • I = Informed: must be notified of results, but need not be consulted

Typical steps in a RACI (RASCI) process include:

1. Identify all of the processes/activities involved and list them down the left side of the chart 2. Identify all the roles and list them along the top of the chart 3. Complete the intersections of the chart by identifying what roles have the R, A, (S), C, and I for each

process 4. Every process should have one and only one ‘R’ as a general principle. A gap occurs when a process

exists with no ‘R’, an overlap occurs when multiple roles exist that have an ‘R’ for a given process 5. Resolve overlaps: in the case of multiple ‘R’ for a process, zoom in and further detail the sub

processes associated to separate the role responsibilities 6. Resolve gaps: the individual with the authority for role definition must determine which existing role

is responsible or what new role is required

A sample RACI chart:


Page | 28

Work Breakdown Structure (WBS) A work breakdown structure (WBS) outlines the work that must be accomplished in the project, decomposes the work into smaller pieces of work and becomes the skeleton of the schedule. It must include activity name, activity number and individual accountable.

Steps:

1. Define the major deliverables and milestones 2. Decompose the major deliverables to a level of detail appropriate to define discrete units of work 3. Continue to decompose until appropriate details is captured 4. Review and refine until stakeholders agree

A sample WBS:


Page | 29

Prioritization Techniques For most projects, prioritization will have to be done to determine which requirements will be implemented within the time available. It balances time and budget constraints against scope. The information included in the Change Request template should be used to determine priorities, when available. If a Change Request is not filled out, refer to it for the questions that should be asked when prioritizing.

Prioritization should include Project Managers and Business Analysts. Developers, Subject Matter Experts, and Sponsors may also be included.

MoSCoW Analysis This analysis divides requirements into four categories: Must, Should, Could, and Won’t. To categorize at the most basic level, impact and effort should be analyzed.

Priority Scale Very similar to MoSCoW analysis, but the priorities are categorized according to a scale of High (the user needs the capability and/or there are regulatory/legal obligations), medium (the requirement is important but not urgent), and low (the user can live without the capability).

Voting Participants who set priorities can be put into a room together to vote on the priorities. The most effective voting technique is to have everybody show their vote at once so that nobody succumbs to peer pressure. This can be done with tokens, or it can be done by everyone displaying a number


Page | 30

between 1 and 10. Outliers should be asked for their explanations for their votes and a subsequent vote can be taken until there is some consensus.

Priority Matrix A priority matrix considers different criteria such as business value, risk, complexity to implement, compliance, dependencies on other requirements, urgency, etc. and assigns weights/points to assist with determining priorities. The information included in the Change Request template would be useful to put into a priority matrix as measurement items.

A sample template (excel) for a priority matrix is available and looks like the following:

Context Diagram Context diagrams show the interactions between a system and other actors (external factors) with which the system is designed to interface. System context diagrams can be helpful in understanding the context which the system will be part of. They are used early in a project to get agreement on the scope and can be included in a requirements document. A context diagram shows the entire system as a single process.

Steps:

1. Label the system/process in the centre – name of system/process usually contains a verb 2. Identify entities that interact directly with the system/process – entities are usually a noun 3. Group like entities 4. Identify major flows of data between the entity and system/process

Notation:

• Systems/Processes are shown as squares with rounded corners

• External entities are shown as squares

• data stores are shown as elongated, flat rectangles


Page | 31

• data flows are shown as arrows

A sample context diagram:

Use Cases Use Cases are another tool for capturing functional requirements of the system. They define a goal-oriented set of interactions between external actors (parties outside of the system that interact with the system) and the system. A use case is initiated by the user, with a particular goal in mind, and completes successfully when that goal is satisfied. The system itself is treated as a “black box” and the interactions with the system are perceived as being outside the system to allow the use case to capture who does what with the system and for what goal without dealing with system internals.

A complete set of use cases defines the behavior required of the system (bounding the scope) by specifying all the ways to use the system.

To create a use case:

1. Identify all the different users of the system 2. Create a user profile for each category of user (including all the roles the users play that are

relevant to the system) 3. For each role, identify the significant goals the users have that the system will support

Create a use case for each goal. Steps in higher level use cases may be treated as goals for lower level sub-use cases where more detail is collected


Page | 32

Use Cases can be illustrated in diagrams or through written documentation. A use case document should include information such as Use Case identifier, description, list of actors, assumptions for successful termination of the use case, steps (interactions between actors and system to achieve the goal), any variations in the steps of the use case, non-functional requirements the use case must meet (optional) and issues that remain to be resolved for the use case.

A sample use case diagram:

Fishbone Diagrams A fishbone diagram illustrates the cause of a specific event, typically used for quality control. The causes are typically grouped into the following categories: people, methods, machines, materials, measurements and environment. These categories can vary, depending on what the fishbone is being used for.

A fishbone diagram looks like the following:


Page | 33

Activity Diagram A process model is a formal way of representing how a business operates. An activity diagram is one method of representing a process model. It describes the behavior of a system by depicting the sequencing of events through workflow. They illustrate what happens in workflow, what activities can be done in parallel and whether there are alternative paths through the workflow.

Before drawing an activity diagram, the following elements should be identified:

• Activities • Association • Conditions • Constraints

The advantage of activity diagrams over some of the other diagram tools is that they can be used to capture flow from one system to another and include capabilities such as branding, parallel flow and guards (conditions that must be true). These diagrams are high level and model the activities (business requirements) so they are beneficial towards understanding the business but not necessarily implementation details.

The notation can be found on the web for an activity diagram. The symbols include initial node, final node, activity, note, decision, merge, guard, fork, join and repeated activity.

A sample activity diagram:


Page | 34

Process Flow Diagrams A process model is a formal way of representing how a business operates. A process flow diagram is one method of representing a process model. The flow diagram/chart includes the following elements:

• Activity: a step in the process • Decision: where there are 2 or more options • Flow: direction of the steps • Terminator: beginning and end of process


Page | 35

There are a number of symbols that can be used in the diagram to represent output, documents, processes, connectors, decisions, etc. These can easily be found on the web or within Visio.

A sample process flow diagram:

A cross functional process flow diagram emphasizes handoffs and links between steps in the process:


Page | 36

Data Flow Diagram A Data Flow Diagram (DFD) is a graphical representation of the flow of data through an information system (ie: shows business processes and the data that flows between them). It illustrates what kinds of data will be input and output from the system, where the data will come from and go to, and where the data will be stored. A DFD is often an elaboration of a context diagram to show some of the detail of the system that was first illustrated through the context diagram.

Notation:

• A function or process is a circle

• External entities are shown as squares

• Inputs/outputs are a rectangle

• data flows are shown as arrows

• data store/files/databases are double lines

Sample data flow diagram:


Page | 37

State Diagram State diagrams describe the different statuses that an object moves through or provide an abstract description of the behavior of a system. They can be used to cross reference business rules to ensure consistency and identify gaps, detect gaps in use cases and process flows, and find requirements on how states of an object change.

The elements of a state diagram include:

• State (wait state, ongoing state, finite state) • Transition (what causes movement to the next state) • Activities (process that occurs when an object is in a certain state) • Composite states (contains more than one sub-state) • Concurrent states (can be in more than one state at the same time)

A sample state diagram:


Page | 38

Data Model A data model shows the client’s information needs and business processes through entities, relationships and data required within the system. It complements the data flow diagram which shows how the data is processed. Data models can be conceptual (high level entities and relationships to document business concepts or high level requirements), logical (more detailed information on entities, attributes and relationships by often expanding the conceptual model to include attributes, columns, fields and keys) or physical (how data is stored and managed in an application).

Data models are diagrams supported by textual descriptions. They can include people, places, things, concepts, attributes and relationships. Textual descriptions are usually included in a data dictionary.

Examples of data models are Entity Relationship Diagrams (ERD) and Class Diagrams.

Entity Relationship Diagram (ERD) The ERD is a data model diagram that includes entities (a noun, event or concept that describes an important concept to the business that can be uniquely identified), relationships (associations between entities, usually a verb) and attributes (information about the entities that typically end up as data fields in the database). The diagram is an abstract, conceptual representation of data.

Cardinality within an ERD refers to the maximum number of times an instance in one entity can be associated with instances in the related entity. Modality refers to the minimum number of times an instance in one entity can be associated with an instance in the related entity.

zero or more 1 and only 1 (exactly 1)


Page | 39

1 or more zero or more zero or more

A sample ERD:

Class Diagram A class diagram describes the structure of a system by showing the system’s classes (represent main objects and/or interactions in the application), their attributes, operations (methods), and the relationships (include association, inheritance and aggregation) among the classes. These diagrams are mainly used for object oriented modeling.

A sample class diagram:


Page | 40

Data Dictionary A data dictionary is often referred to as a metadata repository. It is a repository of information about the data included in the system. This information includes meaning, relationships to other data, origin, usage and format. It can also include characteristics such as edits and defaults. The data dictionary defines the basic organization of the database.


Page | 41

Glossary2

Acceptance Criteria: criteria which must be met before project deliverables are accepted

Application Area: Application areas are categorized by common components such as product (eg. PeopleSoft, Oracle), or type of customer (eg. Academic department, academic support unit, etc)

Assumptions: factors that are considered to be true, real or certain without proof or demonstration

Backwards Pass: calculation of late finish dates and late start dates for the uncompleted activities/tasks within a project schedule. These dates are determined by working backwards from the project’s end date.

Baseline: an approved plan for a project, plus or minus approved changes. The baseline is always compared to the actual performance of the project. The baseline can be a current baseline, or the original.

Budget: the approved, estimated costs associated with the work associated with the project

Buffer: a provision added to the project management plan to mitigate costs and/or schedule risk.

Change Control: identifying, documenting, approving/rejecting and controlling changes to the project baselines.

Change Request: requests to modify the project scope, governance, processes, plans, procedures, costs, schedules or work item

Collect Requirements: process of defining and documenting stakeholders’ needs and business rules

Communication Management Plan: describes communications and expectations for the project: how information will be communicated, what format it will be presented in, how often it will be communicated, and who is responsible for the communication. This is contained within the Project Management Plan and may require a more extensive Implementation Strategy document.

Constraint: a restriction or limitation to a course of action that may be internal or external to the project that could affect the performance.

Contingency: See Buffer

Contract: mutually binding agreement between a seller to provide a product/service and a buyer who will pay for it

2 The glossary definitions included in this section have been taken from the dictionary, Wikipedia, and A Guide to the Project Management Body of Knowledge (PMBOK Guide), published by the Project Management Institute


Page | 42

Cost Management Plan: establishes the activities and criteria for planning, structuring, and controlling the projects costs. This is contained within the Project Management Plan.

Crashing: a technique to compress the project schedule duration by determining the least costly alternative. Typical approaches for crashing a schedule include reducing schedule activities and increasing resource assignments.

Criteria: standards, rules or tests used to base a judgment or decision upon, or to evaluate a product against

Critical Activity: an activity/task on a critical path of a project schedule

Critical Path: generally the sequence of scheduled activities/tasks that determines the maximum duration of the project (ie: the longest path through the project).

Critical Path Methodology: a technique to determine scheduling flexibility (float) and to determine minimum project duration. Early start and finish dates are calculated with a forward pass using the project start date. Late start and finish dates are calculated with a backwards pass, starting with a project completion date.

Define Activities/Tasks: process of identifying actions required to produce project deliverables. These activities/tasks are then put into the project schedule.

Deliverable: a unique product, result or capability to perform a service within a process, phase or project

Early Finish Date: the earliest possible date an activity/task on the project schedule can finish. Note that this date can change as the project progresses.

Early Start Date: the earliest possible date an activity/task on the project can start. Note that this date can change as the project progresses.

Effort: number of work periods required to complete a scheduled activity/task

Estimate: quantitative assessment of likely amount or outcome applied to project costs, resources, effort and durations

Fast Tracking: project schedule compression technique that overlaps phases that would normally be done in sequence.

Finish Date: date associated with activity/task completion

Finish-to-Finish: relationship where the completion of work of activity/task B can’t finish until the completion of work of activity/task A


Page | 43

Finish-to-Start: relationship where initiation of work of activity/task B depends on completion of work of activity/task A

Forward Pass: calculation of early start and early finish dates for uncompleted portion of activities/tasks in a project schedule

Free Float: amount of time an activity/task can be delayed without affecting the early start date of subsequent activities/tasks

Human Resource Plan: describes projects roles & responsibilities, associated skills and reporting relationships. This is contained within the Project Management Plan.

Lag: a scheduled delay for a successor activity/task.

Late Finish Date: latest possible point in time in a schedule that an activity/task may complete. These are determined during the backward pass calculation.

Late Start Date: latest possible point in time in a schedule that an activity/task may begin. These are determined during the backward pass calculation.

Lessons Learned: the learning gained during the project

Milestone: significant event in the project

Objective: a strategic position to direct work towards, or a purpose to achieve

Opportunity: a favorable situation/possibility, or a risk that could have a positive impact on the project

Procurement Management Plan: describes how procurement processes will be managed. This is contained within the Project Management Plan.

Product: a quantifiable material or good or information system that is produced as an end item or as a component of an end item

Product Life Cycle: sequential product phases that are followed to deliver the product, according to the needs of the organization.

Product Scope: features and functions to characterize a product, service or result

Program: group of related projects managed in a coordinated way

Project: temporary endeavor undertaken to create a unique product, service, or result

Project Charter: document that formally authorizes the existence of a project. It provides the authority to the project manager to apply resources to activities/tasks.


Page | 44

Project Initiation: launching a process that can result in the authorization of a new project

Project Life Cycle: sequential project phases that are followed to execute a project, according to the needs of the organization.

Project Management Plan: document that defines how the project will be executed, monitored and controlled (project governance).

Project Management Process Groups: grouping of project management inputs, tools, techniques and outputs. These are not project phases.

Project Phase: collection of related project activities that typically result in a deliverable. It is a component of a project life cycle.

Project Schedule: planned dates for meeting project activities/tasks and milestones

Quality: degree to which characteristics meet requirements

Quality Management Plan: describes how organization’s quality policy will be implemented for the project. This is contained within the Project Management Plan.

Regulation: requirements imposed by government legislation.

Request for Information (RFI): procurement document soliciting information related to a product or service

Request for Proposal (RFP): procurement document soliciting proposals from prospective vendors interested in selling products or services.

Request for Quotation (RFQ): procurement document soliciting price quotations from prospective vendors interested in selling products or services.

Requirement: condition/capability that must be met by the system, product, service or result. Requirements are quantified needs, wants and expectations of sponsor, customer and stakeholders.

Resource: skilled human resource, equipment, service, supply, commodity, material, budget, or fund

Resource Leveling: a technique used to schedule start and finish dates based upon resource constraints

Risk: uncertain event that would have a positive or negative effect on the project if it should occur

Risk Acceptance: a risk response indicating that no changes will be made to the project management plan to deal with a risk

Risk Avoidance: a risk response that changes the project management plan to either eliminate or reduce the impact of a risk


Page | 45

Risk Management Plan: describes how project risks will be identified and managed on the project. This is contained within the Project Management Plan, and usually includes a reference to a Risk Register within the plan or as a separate document.

Risk Register: contains risk identification, risk analysis (quantitative and qualitative) and risk response planning

Risk Tolerance: the degree of risk that an organization can withstand

Risk Transference: a risk response that shifts the impact and response ownership of the risk to a third party

Role: defined function of a project team resource

Schedule Management Plan: establishes activities, criteria and responsibility for managing the project schedule. This is contained within the Project Management Plan.

Scope: sum of products, services and results to be provided as a project

Scope Change: a change to the project scope which usually requires a modification to the project cost and/or schedule

Scope Creep: additional features and/or functionality that are added to the scope after the project has started, without approval and consideration to how this will affect the project

Scope Management Plan: describes how the scope will be defined, verified and managed. It is contained within the Project Management Plan.

Secondary Risk: a risk that arises due to the implementation of a risk response

Specification: complete, precise document describing characteristics of a system, product, result or service

Sponsor: person or group providing financial resource for the project

Staffing Management Plan: describes management of project’s human resources. This is contained within the Project Management Plan.

Stakeholder: person or organization directly or indirectly involved in the project. The stakeholder may be positively or negatively affected by the project and may or may not influence the project.

Start-to-Finish: completion of activity/task B is dependent upon initiation of activity/task A

Start-to-Start: initiation of activity/task B dependent upon initiation of activity/task A

Statement of Work (SOW): detailed description of products, services or results to be supplied


Page | 46

Triggers: indications or warning signs that a risk has occurred, or about to

Work Breakdown Structure (WBS): decomposition of the work to be executed by the project into a hierarchical structure to organize and define the project scope.

Workaround: an unplanned response to a risk that has occurred