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

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 Cy cle (SDLC) Relate to the PM Life L ife 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


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

Page | 2


Introduction What is a Project? 1

According to PMBOK , “A project is a temporary endeavor undertaken to create a unique product, service or result. The temporary nature of projects projects indicates a definite beginning 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 list the 5 Process Groups within project management to be Initiating, Planning, Executing, Monitoring & Controlling, 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 accomplishing an objective. It provides a checklist of key deliverables and activities to avoid missing missing key tasks. A Project Management Methodology is a roadmap roadmap for managing projects (the project project life cycle). A Systems Development Life 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. functionality. Within the phases 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 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 | 3


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

Program

high

Large A

Large B

Large C

medium Medium A

lo w Small A

1-2 (months)

Small B

Medium B

Medium C

Small C

2-6

6-12

12-18

> 2yrs

TIME

As projects become more complex and span longer than 6 months, heavier met hodology 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 e xternal 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 o f action – may be combined with high level project planning process group for small projects

Page | 4


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 proce ss 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, fe asibility 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 de sign(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-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 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 | 5


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 proj ect 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 drive n 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 Methodologies for Project Management Life Cycle (PM) & Systems Development Life Cycle (SDLC)

Approved Charter

P M

P R O C E S S E S

High Level Project Planning

Project Initiation

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

POSSIBLE DELIVERABLES: RFI q RFP q Project M anagement Plan q

Detailed Project Planning

Project E xecution and Control

POSSIBLE DELIVERABLES: 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

q

Project Closure

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

POSSIBLEDELIVERABLES: Requirements Document q Current business processes q Fit/Gap q

P H A S E S

Page | 7

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

Test

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

and Sign Offs User Acc eptance Testing (Integration Testing) s cripts and sign offs

Implementation POSSIBLEDELIVERABLES: 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

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


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.

t i i t n Project Charter n i o I a

Page | 8

Created by: Project Manager

Reviewed by: Business Analyst

Approved by: Sponsor

Requirement: If formal project

Template available


Project Lead (possibly) Subject Matter Experts (possibly)

Feasibility Study

Page | 9

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 t he 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 | 10

Business Case

Created by: Project Manager and/or Business Analyst

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

Approved by: Sponsor and possibly higher up

Project Governance


Reviewed by: Business Analyst Project Lead (possibly)


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

Template Available

Examples: HRMS Project Procedures HRMS Project Roles & Responsibilities


document project governance within a charter.

g n i n n a l P t c e j o r P l e v e L h g i H

Page | 11

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:


Request for Proposal (RFP)

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) 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”


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.

Request for Page | 13

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 Created by: Reviewed by: Approved by: Requirement: Template


g n i n n a l P d e l i a t e D

Page | 14

Information (RFI)

Project Manager

Project Schedule


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

Sponsor Procurement

Not always required

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

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 don’t always benefit. Parkinson’s Law advises resources be


Project Kick-Off Meeting

Implementation Plan

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. Created by: Reviewed by: Approved by: Requirement: 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 Created by: Reviewed by: Approved by: Requirement: Template 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


Risk Register

l o r t n o C & n o i t u c e x E t c e j o r P

t e c r e j u s o o r l P C

Page | 16


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


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 a ccessible 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


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.

Post-Project Review

Page | 17

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


Maintenance Plan


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

Page | 18

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


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.

y i s Requirements n l A a s Document

Page | 19

Created by: Business Analyst

Reviewed by: Project Manager

Approved by: There may be

Requirement: Required for

Template available


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 t he 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 t he desired • Page | 20


Current Business Processes

Fit/Gap

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. 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 f or 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


t n e m p o l e v e D & n g i s e D

Development Strategy

Created by: Project Lead

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

Approved by: No formal approvals required

Requirement: highly recommended

Examples: HRMS 9.1 Upgrade and HRMS Project

Standards & Procedures


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


Requirement: Yes

Examples: Developer’s TechZone HRMS Project

Design Specifications and Sign Offs

Created by: Project Lead and/or Developer

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)

SISP

Approved by: Business Analyst

Requirement: Yes for any development

Examples: SISP HRMS Project

t s e T

Page | 22

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.

Test Strategy/ Procedures

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 Scripts/ Plans/ Scenarios and Sign Offs

User Acceptance (Integration) Testing Scripts

n o i t a t n e m e l p m I

Page | 23



Reviewed by: Subject Matter Expert Project Lead (possibly)

Reviewed by: Subject Matter Expert

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


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

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

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


Contingency Plan

Created by: Project Lead or Project Manager

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

Approved by: No formal approval required

User Documentation

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

Reviewed by: Varies by project

Approved by: No formal approvals required.

New Business Processes

Training Documentation

Page | 24

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.

Created by: Business Analyst Subject Matter Expert (possibly)

Reviewed by: Project Lead (possibly) Subject Matter Expert


Requirement: Yes, for any large implementation with significant risk Requirement: Yes for any large implementation that will be used by multiple people

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


Quality Assurance and development migration

System/ Software

Standards/ Procedures for Reporting & Tracking Issues and Changes

e c n a n e t n i a M

Page | 25

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

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


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



Examples: Support & Relationship Governance with Pension vendor


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


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 t he 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 e xisting role is responsible or what new role is required A sample RACI chart:

Page | 27


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


Prioritization Techniques For most projects, prioritization will have to be done to determine which requirements w ill 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 t o 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 eve rybody 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


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, e tc. 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 m easurement 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 fact ors) 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 ro unded corners

•

External entities are shown as squares

•

data stores are shown as elongated, flat rectangles

Page | 30


•

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 betwee n 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


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, ste ps (interactions between actors and system to ac hieve 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


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 ther e 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 t he 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 nec essarily 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


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


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


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 c ontext 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


State Diagram State diagrams describe the differe nt 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


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 t hat 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 e ntity.

zero or more

Page | 38

1 and only 1 (exactly 1)


1 or more

zero or more

zero or more

A sample ERD:

Class Diagram A class diagram describes the structure o f a system by showing the system’s classes (re present main objects and/or interactions in the application), their attributes, oper ations (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


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


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 e xtensive Implementation Strategy document.

Constraint: a restriction or limitation to a course of action that may be internal or e xternal 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 | 41


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 proje ct 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 co sts, 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 act ivity/task B can’t finish until the completion of work of activity/task A

Page | 42


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


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


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 aft er 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 proje ct 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 re sults to be supplied Page | 45

Project Management Methodology

Recommend Documents