Project Management and Systems Development Life Cycle Methodologies

Information Systems
Fluttert, Pamela E 2/29/2012

Information Systems Project Management & SDLC Methodologies 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 | 1

Information Systems Project Management & SDLC Methodologies

Entity Relationship Diagram (ERD)...................................................................................................... 38 Class Diagram ...................................................................................................................................... 39 Data Dictionary ....................................................................................................................................... 40

Page | 2

Information Systems Project Management & SDLC Methodologies Introduction

What is a Project?
According to PMBOK 1, 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

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

Page | 3

Information Systems Project Management & SDLC Methodologies

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. Charvats 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

Medium A Medium B Small C Medium C Large A Large B Program

Large C

low
Small A Small B

1-2 (months)

2-6

6-12

12-18

> 2yrs

TIME

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 | 4

Information Systems Project Management & SDLC Methodologies

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 softwares 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-andtrue 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 arent 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 | 5

Information Systems Project Management & SDLC Methodologies

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 | 6

Information Systems Project Management & SDLC Methodologies

Information Systems Methodologies for Project Management Life Cycle (PM) & Systems Development Life Cycle (SDLC)

P M

Approved Charter

Project Initiation

High Level Project Planning

Detailed Project Planning

Project Execution and Control

Project Closure

P R O C E S S E S

POSSIBLE DELIVERABLES: q Feasibility Study q Business Case q Project Charter q Project Governance

POSSIBLE DELIVERABLES: q RFI q RFP q Project Management Plan

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

POSSIBLE DELIVERABLES: q Logged issues/requests and changes q Updated Project Management Plan q Updated Project Schedule q Status Reporting and Project Review q Training q Communications q Risk assessments and responses

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

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

Analysis & Requirements

S D L C
POSSIBLE DELIVERABLES: q Requirements Document q Current business processes q Fit/Gap

Design & Development

POSSIBLE DELIVERABLES: q Development Strategy q Standards and Procedures q Design Specifications and sign offs q Development and development testing sign offs

Test

Implementation
POSSIBLE DELIVERABLES: q Cutover Plan/Schedule q Contingency Plan q User Documentation q New business processes (documentation, flow diagrams, etc) q Training documentation q Quality Assurance and migration of development q Go Live Readiness Risk Assessment q System/Software

Maintenance

P H A S E S

POSSIBLE DELIVERABLES: q Test Strategy q Test Scripts/Plans/Scenarios and Sign Offs q User Acceptance Testing (Integration Testing) scripts and sign offs

POSSIBLE DELIVERABLES: q Standards/procedures for reporting/tracking issues and changes q Support Strategy q Fixes and enhancements

Page | 7

Information Systems Project Management & SDLC Methodologies

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 projects 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 | 8

Information Systems Project Management & SDLC Methodologies

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.

Feasibility Study

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 Created by: Reviewed by: Approved by: Requirement: Template Project Manager and/or Business Analyst Sponsor Only required if Available Business Analyst Project Lead (possibly) assessing the Subject Matter Expert (possibly) cost vs value of proposed

Page | 9

Information Systems Project Management & SDLC Methodologies

products and/or services Requirement: Only required if need to capture the reasoning for beginning a project in order to gain approval 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

Business Case

Created by: Reviewed by: Project Manager and/or Business Analyst Business Analyst Project Lead (possibly) Subject Matter Expert (possibly)

Approved by: Sponsor and possibly higher up

Template Available

Project Governance

Created by: Project Manager

Reviewed by: Business Analyst Project Lead (possibly)

Approved by: Sponsor

Examples: HRMS Project Procedures HRMS Project Roles & Responsibilities

Page | 10

Information Systems Project Management & SDLC Methodologies

document project governance within a charter.

High Level Project Planning

Project Management Plan

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 Created by: Reviewed by: Approved by: Requirement: Template Project Manager Business Analyst Sponsor For larger, more Available Project Lead (possibly) complex Subject Matter Expert (possibly) projects this document is a requirement, although some of the sections may not be applicable. Guidelines:

Page | 11

Information Systems Project Management & SDLC Methodologies

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) Created by: Reviewed by: Approved by: Requirement: Template Project Manager Business Analyst Sponsor Required available Project Lead (possibly) Procurement according to Subject Matter Expert (possibly) Policy 17 guidelines (see Policies and Guidelines on Procurement site) 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

Request for Proposal (RFP)

Page | 12

Information Systems Project Management & SDLC Methodologies

Outline of Process: 1. The RFP should be reviewed and approved by both the projects 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 cant 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 Universitys 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 vendors 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 Created by: Reviewed by: Approved by: Requirement: Template

Request for Page | 13

Information Systems Project Management & SDLC Methodologies

Information (RFI) Project Schedule Project Manager Created by: Project Manager Business Analyst Project Lead (possibly) Subject Matter Expert (possibly) Reviewed by: Business Analyst Project Lead Developer Subject Matter Expert Sponsor Sponsor Procurement Approved by: Usually no formal approval required. If there is an approval, it would be by Sponsor Not always required Requirement: All projects require a schedule. The complexity of the project drives how complex the schedule becomes available

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 dont always benefit. Parkinsons Law advises resources be

Detailed Planning Page | 14

Information Systems Project Management & SDLC Methodologies

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 Created by: Reviewed by: Approved by: Requirement: Meeting Project Manager Subject matter for the kick off No formal This is strongly meeting should be reviewed with approval advised Business Analyst required Project Lead (possibly) 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 Created by: Reviewed by: Approved by: Requirement: Template Plan Project Manager Business Analyst Sponsor Only for large Available Project Lead (possibly) projects with Subject Matter Expert (possibly) significant roll out training and communication impacts Page | 15

Information Systems Project Management & SDLC Methodologies

Risk Register Requirement: Template Yes, for larger Available more complex projects this is required and risks should be assessed on a regular basis, especially right before a go live 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. Client Sign Off Created by: Reviewed by: Approved by: Requirement: Business Analyst Project Manager No formal Yes Subject Matter Expert approval of (possibly) the sign off required Created by: Project Manager Reviewed by: Business Analyst Project Lead (possibly) Subject Matter Expert (possibly) Approved by: Sponsor

Project Closure Page | 16

Project Execution & Control

Information Systems Project Management & SDLC Methodologies

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. Created by: Reviewed by: Approved by: Requirement: Project Manager Business Analyst No formal Yes Subject Matter Expert (possibly) approval Sponsor required Project Lead Developer 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 arent 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

Post-Project Review

Page | 17

Information Systems Project Management & SDLC Methodologies

Maintenance Plan Created by: Project Manager Reviewed by: Subject Matter Expert Business Analyst Developer Project Lead Sponsor (perhaps) Approved by: No formal approval required 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:

Satisfaction Assessment

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 Created by: Reviewed by: Approved by: Requirement: No templates Project Manager Project Lead Sponsor Not required since this can Business Analyst but take different Subject Matter Expert recommended formats Developer (possibly) for highly visible (feedback from projects focus groups, surveys, etc.)

Page | 18

Information Systems Project Management & SDLC Methodologies

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 projects 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.

Requirements Document

Created by: Business Analyst

Reviewed by: Project Manager

Approved by: There may be

Requirement: Required for

Template available

An aly sis Page | 19

Information Systems Project Management & SDLC Methodologies

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 | 20

Information Systems Project Management & SDLC Methodologies

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. Created by: Reviewed by: Approved by: Requirement: Business Analyst Project Manager (possibly) Subject Depends on Subject Matter Expert Matter Expert project Project Lead 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 Created by: Reviewed by: Approved by: Requirement: Template Business Analyst Project Lead No formal Usually Available Project Manager (possibly) approvals required, Subject Matter Expert required especially for vendorpurchased apps

Current Business Processes

Fit/Gap

Page | 21

Information Systems Project Management & SDLC Methodologies

Development Strategy Created by: Project Lead Reviewed by: Project Manager (possibly) Developer Business Analyst (possibly) 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 Reviewed by: Business Analyst Subject Matter Expert (possibly) Approved by: No formal approvals required Approved by: No formal approvals required Requirement: highly recommended Requirement: Yes Examples: HRMS 9.1 Upgrade and HRMS Project Examples: Developers TechZone HRMS Project SISP

Standards & Procedures

Created by: Project Lead

Design & Development

Design Specifications and Sign Offs

Created by: Project Lead and/or Developer

Approved by: Business Analyst

Requirement: Yes for any development

Examples: SISP HRMS Project

Development This is not a document deliverable, but the development and sign off is a deliverable of the product life cycle. All and development development should be thoroughly tested by developers before migrating it to a test database for functional testing sign offs 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 Created by: Reviewed by: Approved by: Requirement: Examples: Project Lead and/or Business Analyst No formal Highly HRMS Project Business Analyst Subject Matter Expert (possibly) approvals recommended and HRMS required upgrade

Test

Test Strategy/ Procedures

Page | 22

Information Systems Project Management & SDLC Methodologies

Test Scripts/ Plans/ Scenarios and Sign Offs Created by: Business Analyst Reviewed by: Subject Matter Expert Project Lead (possibly) Approved by: Business Analyst and/or Subject Matter Expert Approved by: Business Analyst and/or Subject Matter Expert Approved by: Sponsor Requirement: Yes Examples: HRMS Project SISP Requirement: Yes Examples: HRMS Project SISP Requirement: Yes, for any project large enough to warrant formal project management Requirement: Yes, for any large implementation with any significant risk where implementation requires many people and activities Template Available

User Acceptance (Integration) Testing Scripts

Created by: Business Analyst

Reviewed by: Subject Matter Expert

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

Created by: Project Manager

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

Cutover Created by: (Implementation) Project Lead or Project Plan/Schedule Manager Implementation

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

Approved by: No formal approvals required

Page | 23

Information Systems Project Management & SDLC Methodologies

Contingency Plan Created by: Project Lead or Project Manager Reviewed by: Business Analyst Subject Matter Expert (possibly) Sponsor (possibly) Reviewed by: Varies by project Approved by: No formal approval required Approved by: No formal approvals required. Requirement: Yes, for any large implementation with significant risk Requirement: Yes for any large implementation that will be used by multiple people

User Documentation

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

New Business Processes

System documentation (Entity Relationship Diagrams (see Appendix A: PM & SDLC Tool Kit), for example) could also be created by Developer 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

Approved by: No formal approvals required

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

Page | 24

Information Systems Project Management & SDLC Methodologies

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: Developers TechZone HRMS Project This is not a document deliverable, but the final product is a deliverable of the life cycle.

System/ Software

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)

Approved by: No formal approvals required

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

Examples: HRMS Project SISP Change Request Template Available for a Change Request Examples: Support & Relationship Governance with Pension vendor

Maintenance

Support Strategy

Created by: Project Lead

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

Approved by: No formal approvals required

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

Page | 25

Information Systems Project Management & SDLC Methodologies

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 People Concepts Rules Events Processes Data Models State Transition Diagrams Use Cases

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. 2. 3. 4. 5. 6. Post issue or scenario in the room Brainstorm Post output for all to see Group ideas into natural groupings Label each group Document finished chart/diagram

Page | 26

Information Systems Project Management & SDLC Methodologies

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 | 27

Information Systems Project Management & SDLC Methodologies

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. 2. 3. 4. Define the major deliverables and milestones Decompose the major deliverables to a level of detail appropriate to define discrete units of work Continue to decompose until appropriate details is captured Review and refine until stakeholders agree

A sample WBS:

Page | 28

Information Systems Project Management & SDLC Methodologies

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 Wont. 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 | 29

Information Systems Project Management & SDLC Methodologies

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. 2. 3. 4. Label the system/process in the centre name of system/process usually contains a verb Identify entities that interact directly with the system/process entities are usually a noun Group like entities 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 | 30

Information Systems Project Management & SDLC Methodologies

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 goaloriented 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 | 31

Information Systems Project Management & SDLC Methodologies

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 | 32

Information Systems Project Management & SDLC Methodologies

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 | 33

Information Systems Project Management & SDLC Methodologies

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 | 34

Information Systems Project Management & SDLC Methodologies

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 | 35

Information Systems Project Management & SDLC Methodologies

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 | 36

Information Systems Project Management & SDLC Methodologies

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 | 37

Information Systems Project Management & SDLC Methodologies

Data Model
A data model shows the clients 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 Page | 38 1 and only 1 (exactly 1)

Information Systems Project Management & SDLC Methodologies

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 systems 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 | 39

Information Systems Project Management & SDLC Methodologies

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 | 40

Information Systems Project Management & SDLC Methodologies 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 projects 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
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
2

Page | 41

Information Systems Project Management & SDLC Methodologies

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 cant finish until the completion of work of activity/task A Page | 42

Information Systems Project Management & SDLC Methodologies

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 | 43

Information Systems Project Management & SDLC Methodologies

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 organizations 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 | 44

Information Systems Project Management & SDLC Methodologies

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 projects 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 | 45

Information Systems Project Management & SDLC Methodologies

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

Page | 46