2008 Mar PMO Handbook Rev 20Mar2008

44
PMO Handbook Processes and Procedures Governing SFBLIC’s Project Management Office Revision Date: March 20, 2008 1

Transcript of 2008 Mar PMO Handbook Rev 20Mar2008

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 144

PMO Handbook

Processes and Procedures GoverningSFBLICrsquos Project Management Office

Revision Date March 20 2008

1

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 244

PMO Handbook

PMO Handbook 2 Introduction 5

About this handbook 5 PMO Promises 5 Document Deliverables 6 Process Overview 8

Preliminary Planning 13 1 Receive project mandate 13

A note regarding project initiation 13 2 Organize project team 13 3 Convene project board 14 4 Organize project tools15

Project Library 15 TestDirector (aka HP QualityCenter) 16 Communications 16

5 Train business analysts and programmers (as needed) 16 6 Convene project team (Pre-Planning Kick-off Retreat) 17

Component 1 Project Introduction 17 Component 2 Stakeholder Analysis 17 Component 3 Direction Statements 18 Component 4 Strategy18 Session 5 Project Charter20

7 Present Project Charter 21 Planning 23

1 Convene project team (Planning Kick-off Retreat) 23 Identify Tasks 23 Task Analysis Workgroups Sign-Up 24

2 Convene workgroups (Functional Kick-off Meetings) (optional) 24 2

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 344

Component 1 Complete task analysis 25 Component 2 Establish functional specification framework (if applicable) 26

3 Complete requirement definitions 26 4 Prepare implementation plan 27

Schedule27 Cost 28 Communications 28 Performance Reporting28 Change Control 28 Roles amp Responsibilities 28

5 Convene project team29 6 Present implementation plan 29

Execution amp Control General Principles 31 Measurement 31

Methodology 31 Hour Tracking 31 Reporting 32

Change Control 32 Execution amp Control In-house Software Model 33

1 Coding 33 2 Procedures 33 3 QA functional and integration testing 33 4 User acceptance testingQA regression testing 33 5 Training 34 6 Go live 34 7 Post-project review 34 Final project report 34

Reflections 34 Administrative closure34 Additional project closure information 34

Execution amp Control Vendor Management Model 35

3

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 444

Basic Steps35 Appendix A Project Initiation Checklist 36 Appendix B PMO Requirements Management Process 38

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process 40

Requirements Planning 40 Requirements Gathering amp Elicitation 40 Requirements Definition 41 Requirements Analysis 41 Requirements Verification 41 Requirements Change Management 41

Guidelines for Requirement Workshops 42 Appendix C Project Closure Checklist 43

4

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 544

Introduction 03202008

Introduction

About this handbook

The PMO Handbook outlines the processes that should be followed for each project handled by the PMO as applicable to that project

It covers all phases of the project from receipt of the project mandate to post-project review The effective management of a project requires a balance between and integration of contentissues (technical deliverables tasks documentation defect correction etc) and context issues(managerial political and social) It is widely believed that project fail due to content issues it islesser known that projects also fail due to context issues

Projects should be totallyfocused on added valueand benefits realization

PMO Promises

1 We will only do work (call meetings request documents etc) that adds value to the processIf it does not add value we will eliminate it

2 We will not attempt to manage any managerrsquos area for him or her We will provide project-related support and structure and be the go-to area for project questions and guidance Onthe other hand the Project Manager is ultimately responsible for the overall project and willdo what is necessary to see that the project team meets its stated goals

3 We will not tell any Team Member how to do his or her job We will provide project-relatedsupport guidance and accountability In return the Project Manager expects TeamMembers to provide accurate and timely communication regarding project activities

4 We will provide regular communication to the project stakeholders and the company at largeas to what is going on with the project

5 We will not mandate schedule dates The team will agree as a group on feasible dates andcommit to making them With every project we will attempt to improve our estimates andplanning methodology Note Exceptions to this rule may be required at times due to legalor compliance reasons or business-critical senior management directives In those cases theProject Manager will work with the team to revise the plan to meet those deadlines

5

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 644

Introduction 03202008

6

Document Deliverables

The following chart outlines some of the documents and deliverables referred to in this

handbook As with most PMO processes these are loosely defined guidelines that are applied asappropriate to the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 744

Introduction 03202008

7

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 844

Introduction 03202008

Process Overview

The following flow chart is a visual overview of the topics covered in the rest of this handbook

8

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 944

Introduction 03202008

9

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 244

PMO Handbook

PMO Handbook 2 Introduction 5

About this handbook 5 PMO Promises 5 Document Deliverables 6 Process Overview 8

Preliminary Planning 13 1 Receive project mandate 13

A note regarding project initiation 13 2 Organize project team 13 3 Convene project board 14 4 Organize project tools15

Project Library 15 TestDirector (aka HP QualityCenter) 16 Communications 16

5 Train business analysts and programmers (as needed) 16 6 Convene project team (Pre-Planning Kick-off Retreat) 17

Component 1 Project Introduction 17 Component 2 Stakeholder Analysis 17 Component 3 Direction Statements 18 Component 4 Strategy18 Session 5 Project Charter20

7 Present Project Charter 21 Planning 23

1 Convene project team (Planning Kick-off Retreat) 23 Identify Tasks 23 Task Analysis Workgroups Sign-Up 24

2 Convene workgroups (Functional Kick-off Meetings) (optional) 24 2

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 344

Component 1 Complete task analysis 25 Component 2 Establish functional specification framework (if applicable) 26

3 Complete requirement definitions 26 4 Prepare implementation plan 27

Schedule27 Cost 28 Communications 28 Performance Reporting28 Change Control 28 Roles amp Responsibilities 28

5 Convene project team29 6 Present implementation plan 29

Execution amp Control General Principles 31 Measurement 31

Methodology 31 Hour Tracking 31 Reporting 32

Change Control 32 Execution amp Control In-house Software Model 33

1 Coding 33 2 Procedures 33 3 QA functional and integration testing 33 4 User acceptance testingQA regression testing 33 5 Training 34 6 Go live 34 7 Post-project review 34 Final project report 34

Reflections 34 Administrative closure34 Additional project closure information 34

Execution amp Control Vendor Management Model 35

3

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 444

Basic Steps35 Appendix A Project Initiation Checklist 36 Appendix B PMO Requirements Management Process 38

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process 40

Requirements Planning 40 Requirements Gathering amp Elicitation 40 Requirements Definition 41 Requirements Analysis 41 Requirements Verification 41 Requirements Change Management 41

Guidelines for Requirement Workshops 42 Appendix C Project Closure Checklist 43

4

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 544

Introduction 03202008

Introduction

About this handbook

The PMO Handbook outlines the processes that should be followed for each project handled by the PMO as applicable to that project

It covers all phases of the project from receipt of the project mandate to post-project review The effective management of a project requires a balance between and integration of contentissues (technical deliverables tasks documentation defect correction etc) and context issues(managerial political and social) It is widely believed that project fail due to content issues it islesser known that projects also fail due to context issues

Projects should be totallyfocused on added valueand benefits realization

PMO Promises

1 We will only do work (call meetings request documents etc) that adds value to the processIf it does not add value we will eliminate it

2 We will not attempt to manage any managerrsquos area for him or her We will provide project-related support and structure and be the go-to area for project questions and guidance Onthe other hand the Project Manager is ultimately responsible for the overall project and willdo what is necessary to see that the project team meets its stated goals

3 We will not tell any Team Member how to do his or her job We will provide project-relatedsupport guidance and accountability In return the Project Manager expects TeamMembers to provide accurate and timely communication regarding project activities

4 We will provide regular communication to the project stakeholders and the company at largeas to what is going on with the project

5 We will not mandate schedule dates The team will agree as a group on feasible dates andcommit to making them With every project we will attempt to improve our estimates andplanning methodology Note Exceptions to this rule may be required at times due to legalor compliance reasons or business-critical senior management directives In those cases theProject Manager will work with the team to revise the plan to meet those deadlines

5

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 644

Introduction 03202008

6

Document Deliverables

The following chart outlines some of the documents and deliverables referred to in this

handbook As with most PMO processes these are loosely defined guidelines that are applied asappropriate to the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 744

Introduction 03202008

7

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 844

Introduction 03202008

Process Overview

The following flow chart is a visual overview of the topics covered in the rest of this handbook

8

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 944

Introduction 03202008

9

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 344

Component 1 Complete task analysis 25 Component 2 Establish functional specification framework (if applicable) 26

3 Complete requirement definitions 26 4 Prepare implementation plan 27

Schedule27 Cost 28 Communications 28 Performance Reporting28 Change Control 28 Roles amp Responsibilities 28

5 Convene project team29 6 Present implementation plan 29

Execution amp Control General Principles 31 Measurement 31

Methodology 31 Hour Tracking 31 Reporting 32

Change Control 32 Execution amp Control In-house Software Model 33

1 Coding 33 2 Procedures 33 3 QA functional and integration testing 33 4 User acceptance testingQA regression testing 33 5 Training 34 6 Go live 34 7 Post-project review 34 Final project report 34

Reflections 34 Administrative closure34 Additional project closure information 34

Execution amp Control Vendor Management Model 35

3

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 444

Basic Steps35 Appendix A Project Initiation Checklist 36 Appendix B PMO Requirements Management Process 38

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process 40

Requirements Planning 40 Requirements Gathering amp Elicitation 40 Requirements Definition 41 Requirements Analysis 41 Requirements Verification 41 Requirements Change Management 41

Guidelines for Requirement Workshops 42 Appendix C Project Closure Checklist 43

4

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 544

Introduction 03202008

Introduction

About this handbook

The PMO Handbook outlines the processes that should be followed for each project handled by the PMO as applicable to that project

It covers all phases of the project from receipt of the project mandate to post-project review The effective management of a project requires a balance between and integration of contentissues (technical deliverables tasks documentation defect correction etc) and context issues(managerial political and social) It is widely believed that project fail due to content issues it islesser known that projects also fail due to context issues

Projects should be totallyfocused on added valueand benefits realization

PMO Promises

1 We will only do work (call meetings request documents etc) that adds value to the processIf it does not add value we will eliminate it

2 We will not attempt to manage any managerrsquos area for him or her We will provide project-related support and structure and be the go-to area for project questions and guidance Onthe other hand the Project Manager is ultimately responsible for the overall project and willdo what is necessary to see that the project team meets its stated goals

3 We will not tell any Team Member how to do his or her job We will provide project-relatedsupport guidance and accountability In return the Project Manager expects TeamMembers to provide accurate and timely communication regarding project activities

4 We will provide regular communication to the project stakeholders and the company at largeas to what is going on with the project

5 We will not mandate schedule dates The team will agree as a group on feasible dates andcommit to making them With every project we will attempt to improve our estimates andplanning methodology Note Exceptions to this rule may be required at times due to legalor compliance reasons or business-critical senior management directives In those cases theProject Manager will work with the team to revise the plan to meet those deadlines

5

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 644

Introduction 03202008

6

Document Deliverables

The following chart outlines some of the documents and deliverables referred to in this

handbook As with most PMO processes these are loosely defined guidelines that are applied asappropriate to the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 744

Introduction 03202008

7

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 844

Introduction 03202008

Process Overview

The following flow chart is a visual overview of the topics covered in the rest of this handbook

8

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 944

Introduction 03202008

9

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 444

Basic Steps35 Appendix A Project Initiation Checklist 36 Appendix B PMO Requirements Management Process 38

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process 40

Requirements Planning 40 Requirements Gathering amp Elicitation 40 Requirements Definition 41 Requirements Analysis 41 Requirements Verification 41 Requirements Change Management 41

Guidelines for Requirement Workshops 42 Appendix C Project Closure Checklist 43

4

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 544

Introduction 03202008

Introduction

About this handbook

The PMO Handbook outlines the processes that should be followed for each project handled by the PMO as applicable to that project

It covers all phases of the project from receipt of the project mandate to post-project review The effective management of a project requires a balance between and integration of contentissues (technical deliverables tasks documentation defect correction etc) and context issues(managerial political and social) It is widely believed that project fail due to content issues it islesser known that projects also fail due to context issues

Projects should be totallyfocused on added valueand benefits realization

PMO Promises

1 We will only do work (call meetings request documents etc) that adds value to the processIf it does not add value we will eliminate it

2 We will not attempt to manage any managerrsquos area for him or her We will provide project-related support and structure and be the go-to area for project questions and guidance Onthe other hand the Project Manager is ultimately responsible for the overall project and willdo what is necessary to see that the project team meets its stated goals

3 We will not tell any Team Member how to do his or her job We will provide project-relatedsupport guidance and accountability In return the Project Manager expects TeamMembers to provide accurate and timely communication regarding project activities

4 We will provide regular communication to the project stakeholders and the company at largeas to what is going on with the project

5 We will not mandate schedule dates The team will agree as a group on feasible dates andcommit to making them With every project we will attempt to improve our estimates andplanning methodology Note Exceptions to this rule may be required at times due to legalor compliance reasons or business-critical senior management directives In those cases theProject Manager will work with the team to revise the plan to meet those deadlines

5

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 644

Introduction 03202008

6

Document Deliverables

The following chart outlines some of the documents and deliverables referred to in this

handbook As with most PMO processes these are loosely defined guidelines that are applied asappropriate to the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 744

Introduction 03202008

7

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 844

Introduction 03202008

Process Overview

The following flow chart is a visual overview of the topics covered in the rest of this handbook

8

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 944

Introduction 03202008

9

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 544

Introduction 03202008

Introduction

About this handbook

The PMO Handbook outlines the processes that should be followed for each project handled by the PMO as applicable to that project

It covers all phases of the project from receipt of the project mandate to post-project review The effective management of a project requires a balance between and integration of contentissues (technical deliverables tasks documentation defect correction etc) and context issues(managerial political and social) It is widely believed that project fail due to content issues it islesser known that projects also fail due to context issues

Projects should be totallyfocused on added valueand benefits realization

PMO Promises

1 We will only do work (call meetings request documents etc) that adds value to the processIf it does not add value we will eliminate it

2 We will not attempt to manage any managerrsquos area for him or her We will provide project-related support and structure and be the go-to area for project questions and guidance Onthe other hand the Project Manager is ultimately responsible for the overall project and willdo what is necessary to see that the project team meets its stated goals

3 We will not tell any Team Member how to do his or her job We will provide project-relatedsupport guidance and accountability In return the Project Manager expects TeamMembers to provide accurate and timely communication regarding project activities

4 We will provide regular communication to the project stakeholders and the company at largeas to what is going on with the project

5 We will not mandate schedule dates The team will agree as a group on feasible dates andcommit to making them With every project we will attempt to improve our estimates andplanning methodology Note Exceptions to this rule may be required at times due to legalor compliance reasons or business-critical senior management directives In those cases theProject Manager will work with the team to revise the plan to meet those deadlines

5

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 644

Introduction 03202008

6

Document Deliverables

The following chart outlines some of the documents and deliverables referred to in this

handbook As with most PMO processes these are loosely defined guidelines that are applied asappropriate to the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 744

Introduction 03202008

7

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 844

Introduction 03202008

Process Overview

The following flow chart is a visual overview of the topics covered in the rest of this handbook

8

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 944

Introduction 03202008

9

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 644

Introduction 03202008

6

Document Deliverables

The following chart outlines some of the documents and deliverables referred to in this

handbook As with most PMO processes these are loosely defined guidelines that are applied asappropriate to the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 744

Introduction 03202008

7

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 844

Introduction 03202008

Process Overview

The following flow chart is a visual overview of the topics covered in the rest of this handbook

8

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 944

Introduction 03202008

9

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 744

Introduction 03202008

7

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 844

Introduction 03202008

Process Overview

The following flow chart is a visual overview of the topics covered in the rest of this handbook

8

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 944

Introduction 03202008

9

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 844

Introduction 03202008

Process Overview

The following flow chart is a visual overview of the topics covered in the rest of this handbook

8

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 944

Introduction 03202008

9

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 944

Introduction 03202008

9

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1044

Introduction 03202008

10

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1144

Introduction 03202008

Decision

03202008p 4 PMO

Planning Methodology

Doesproject board

approve

Plan is executed

Modify planProject cancelled

and closed

Planning work continues

Planproject

Yes

No

Yes

No

11

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1344

Pre-Planning 04032006

13

Preliminary Planning

1 Receive project mandate

The PMO will receive project mandates from the Executive Vice President CEO The PMO willreview the mandate determine when planning can begin and begin doing any necessary preparation to start the project

During that research phase the PMO will become familiar with the area and its basic processes We will examine the business case and benefits to determine if there is any reason to think theproject will not provide benefits greater than the effort required

A note regarding project initiation

A sample Project Initiation Checklist is shown in Appendix A It is a condensedoverview of suggested steps to initiate a new project The sections below are a more detailed outline of early project processes and are more geared to new projects (whereas a checklist may work just as wellfor repeatable processes) The Checklist may be tailored to suit the Project Managerrsquos or projectrsquosspecific needs

2 Organize project team

In order to avoid large unwieldy teams and unnecessary levels of bureaucracy we willminimize the number of team members and request only the necessary resources

The PMO will determine the major players in the project which will usually include

1 Primary Client ndash A business analyst from the requesting area

2 Suppliers Programming ndash A programming representative from the group responsible for

the project area (typically the supervisor) QA Representative ndash A QA business analyst (or supervisor or manager) with

expertise in the project area

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1444

Pre-Planning 04032006

14

Other ndash anyone from another area who will provide resources to produce thefinal product (eg Financial Reporting Legal etc)

3 Customer ndash A representative for the agent force when affected by the project (could besomeone from a marketing area)

4 Affected Areas ndash A representative from any area such as accounting or another servicedepartment that will be impacted by the project

5 PMO ndash A representative (or two) from the Project Management Office (who will serve asteam leader)

6 Auditing ndash The Internal Audit Manager will be notified of meetings documents etc and willsend auditing representatives when needed

After identifying the major players a representative from the PMO will meet with the appropriatedepartment managers to outline the level of time effort and commitment needed from thatperson and to obtain permission for himher to be on the team For teams that are being re-convened this allocation may be handled via email rather than meeting In either case the

approval for the team memberrsquos appointment should be stated in writing

We will discuss resource allocations with the manager but not mandate them We will ask themanager to have a discussion with the employee about how much of hisher time can be devotedto the project and ask them to come to an agreement about it The project manager shouldclearly outline the responsibilities the resource is expected to fulfill eg making decisions onbehalf of the department keeping the department informed of project matters etc

Note After approval each member of the Project Team will need to upgrade to MS Office2003 in order to use the SharePoint Project Library

3 Convene project board

Based on a recommendation from the PMO director the project board is assigned by theExecutive Vice President CEO The project board members must be a VP or higher andtypically consists of

1 Project Sponsor usually the Senior VP over the area with the greatest business interest in theproject ndash This person chairs the project board commits resources and support from the areaand resolves any conflict that arises at the project board level

2 Senior Client usually the VP over the area that owns the project ndash This person represents the

business needs to be fulfilled by the project

Note If it is determined that a full project board is not needed the Senior Client (VP) may serve as the board chair amp sponsor

3 Senior Supplier usually the VP over Information Systems ndash This person represents QA andProgramming as the major suppliers on any software development projects

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1544

Pre-Planning 04032006

15

The PMO Director will convene the initial meeting The Director will discuss what is expectedfrom the project board and from the affected areas and obtain approval to begin the project If the members have served as project board members before an informal notificationdiscussionmay take place in lieu of a formal meeting

We will also promise to keep the board and other senior management informed about project

updates so that they will have information to communicate to the field including dates (as we feelconfidant that the team will meet them)

Deliverables Approved Project Mandate Proposed Team Members and Team MemberBill of Rights

4 Organize project tools

Project Library

The PMO will set up a SharePoint Project Library for the project All members of the team willbe given authority to check documents in and out of the site and the PMO staff will periodically review the Library to do any ldquoclean-uprdquo work needed

Note The PMO will establish naming conventions that will apply to each document in theproject

Documents that will be housed in the Library include but are not limited to

1 Approved Project Mandate

2 Team Member Bill of Rights

3 Project Charter

4 Gap Analysis Task Analysis or Work Breakdown Structure Documents

5 Requirements Plans and Requirements Definition Documents andor Traceability Matrix

6 FunctionalDesign Specifications (including fleshed out business and technical specifications)

7 Test Plans

8 General ProductProject Documents

9 Links to Related Information

10 Programming Documents as applicable Project-level Technology DescriptionStrategy Project-level StandardsInterface Style Guide Task-level Technical Strategy

Modules Affected Plain English Code Functionality

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1644

Pre-Planning 04032006

16

Completed Data Specifications

Deliverable SharePoint Project Library

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirectorfor handling tasks and defects and that the project has all needed elements and users The PMO will review the procedures for reporting items and request updates as needed then relay theinstructions to the Team Members

We may choose to reserve the granting of project permissions until the testing phase so thatproject tasks and requirements do not get submitted as defects

Deliverable TestDirector Project

Communications

The PMO will set up any needed channels of communications including email distribution listsany additional project information to be housed in SharePoint and any newsletters to be used

One item that we will specifically address is who the PMO should contact for status updates (ormissed targets) during the Execution and Control phase ndash the assigned person or thesupervisormanager Each supervisor will be given the option to be the contact or have thePMO work directly with the assigned person

Deliverable Communications Plan (may be part of Project Plan)

5 Train business analysts and programmers (as needed)

Depending on the needs of the team members assigned to the project the PMO will hold atraining session with the QA or business area analysts andor programmers to give them anoverview of the project (including the methodology for developing product specificationstask analysis meetings) We will clearly explain what is expected of them throughout the process sothat they are fully prepared for the kick-off meeting

We will discuss the importance of time tracking ndash not for us to evaluate how quickly each personis performing ndash but as a measure of project costs and schedule and as a resource to improvefuture estimations Team members will be trained on Project Web Access for reporting time worked and remaining

Note It is suggested that effective hour tracking is done on a daily basis in half-hourincrements It should take no more than about five minutes a day

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1744

Pre-Planning 04032006

17

We will also discuss the importance of estimating good percentages in task statuses ndash not as a wayto keep tabs on people but as a way of measuring project progress The members shouldimmediately begin tracking time for meetings and research as of the first meeting

If any further training or follow-up is needed with project resources the Project Manager willhandle that one-on-one with the resource or the resourcersquos supervisor

6 Convene project team (Pre-Planning Kick-off Retreat)

Convene the project team for a Pre-Planning Kick-off As with most PMO processes whatfollows is a general idea The process may be scaled up or down as suits the project

Note Depending on the project this meeting can be expected to last a while When possibledesignate a retreat format to gain undivided attention

Component 1 Project Introduction

The PMO staff will make introductions of team members as needed and give a brief overview of the project mandate Below are some documents that may be distributed at this meeting

1 Project MandateOverviewBackground

2 Project Board Roster

3 Team Member Roster

4 Team Member Bill of Rights

5 Any procedures to be followed such as Using the SharePoint project library Reporting TestDirector Items

6 ProblemVisionMission Statement Worksheet

7 Strategy Introduction Worksheet

8 Project Charter draft (for repeat projects)

Component 2 Stakeholder Analysis

As a team identify the stakeholders (and indicate the key ones) and talk briefly about what thestakeholders want from the project and how best to communicate important project informationto them

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1844

Pre-Planning 04032006

18

Component 3 Direction Statements

Note For repeat projects this step may be skipped It should still be included in the ProjectCharter

As applicable PMO staff will guide the team through the process of developing problem visionand mission statements

1 The Problem Statement will usually be formulated via a sticky note brainstorming method The members will be asked to indicate any limitations of the current system or frustrations with the current workflowprocessing The group will then combine these items andcategorize them to determine the main problem(s) that need to be addressed

Note Once we have a complete problem statement we can go ahead and address whetherthere is a ldquoquick fixrdquo option ndash a non-system modification (eg procedure changetemplate worksheet etc) that can be easily implemented to ameliorate the problem whilea total solution is completed

2 The Vision Statement will turn those problems into positives Our vision of the endproduct of the project will be a solution that addresses the major problems outlined

Note We are aware that not all problems can be solved in the project These problems will beisolated and left to the area to handle accordingly

3 The Mission Statement will indicate that our mission is to achieve the vision outlinedabove

Deliverables Problem Vision and Mission Statements

Component 4 Strategy

The last step in the kick-off meeting will be determining the overall ldquogame planrdquo or strategy onhow the team plans to accomplish the project mission During this process the team will indicate(and when feasible resolve) any key strategic issues that need to be handled in order to proceed with planning

Note The strategy discussion will take place at the discretion of the Project Manager according

to what is needed in the particular project Below are some possible suggestionshowever this will not fit all projects

This process and the strategies discussed should be determined based on the individual needs of the project At a basic level they should indicate some of the big decisions to be made and wherethe committee is leaning in terms of those decisions Consider it a general projectaspectapproach

These ldquobigrdquo decisions should include

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 1944

Pre-Planning 04032006

19

How will the project mission be accomplished Development options that the project teamshould consider include

1 Fix It ndash Make modifications to an existing system

2 Build It ndash Build a new system from scratch

3 Buy It ndash Buy a new system and use it As-Is

4 Customize It ndash Buy a new system and modify it or our systems as needed

5 Outsource It ndash Contract the entire system (or any modifications) to a 3rd party or

6 Some mixture of the above options

The team should also specify the release strategy for projects Potential release strategiesinclude

1 Monolithic or Waterfall

This strategy involves developing the system or product as a whole with each projectphase as a stand-alone activity Subsequent phases are not started until the prior phase iscompleted

This strategy is only recommended for small low risk projects since it generally takesmuch longer to see a completed product and because it is totally inadequate for handlingrequirement changes If a change is necessary the team would have to either ignore thechange or loop back into an analysis stage thus greatly prolonging the project

2 Sequential Release

This involves breaking the system into independent subsystems or sub-products and thenproducing and implementing an operating subsystem or product as Version 1 or Release1 then a second subsystem as Version 2 or Release 2 and so on For example release 1may consist of a stand-alone product that does not have all of the desire features Release2 would add additional features to the product

The interfaces between the releases must be carefully managed to avoid seriousproblems

3 Concurrent Release

This strategy involves multiple teams working on different pieces of a system andproduct at the same time in order rapidly produce the entire system or product Team 1 would work on Release 1 while a Team 2 works on Release 2

When considering this strategy the project manager and team must keep in mind thateach release team works independently of the other release teams Given that fact thereleases may be in different development phases This will significantly increase themanagerial complexity of the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2044

Pre-Planning 04032006

20

4 Fast Track or Production Prototyping

This strategy involves producing a working production prototype as quickly as possible The whole requirement is developed as quickly as possible with careful and planneddegradation of quality The initial version of the system or product is then redevelopedthrough a series of reengineering projects that include additional functionality

This release strategy should be considered for high risk projects - it is less exposed tochanges since the product is usually delivered before the requirements can change Thedownside of this strategy is that support costs are significantly higher than for the otherstrategies due to the typically low quality of the initial delivery Very sophisticated andprofessional project management is required to execute this strategy

5 Hybrid

A variation of the concurrent release strategy that involves a series of concurrent releasesthat use different release strategies

If the team is making a strategy decision use the following methods as applicable

1 Perform a Risk Assessment ( See sfbfp4PMOPublicDownloadsLewis Institute FormsRiskProbability Analysisdoc

The relationship between project risk and project strategy should be considered by the teamIn general the higher the risk of the project the more risky your project strategy should be Aclassic example is do you walk or run over a bed of hot coals

During the risk assessment process the project team should identify strategies that minimizeor reduce the risk factors All high risk factors that cannot be constrained or eliminatedduring the risk assessment evaluation should have a risk memorandum developed for them This memorandum should document the risk the potential impact on the project actions

that can be taken to reduce the risks and a contingency plan to use if the risk becomes reality( See sfbfp4PMOPrivatePMO DocumentsHigh Risk Memorandumdoc ) (As an alternative therisk may be recorded on the project SharePoint sitersquos Risk Log)

2 Will the selected strategy satisfy performance cost scope and time requirements (as weunderstand them at the current time) Eliminate any strategies deemed to not be feasible atthis time

3 Perform SWOT analysis ( See sfbfp4PMOPublicDownloadsLewis Institute FormsSWOT Analysisdoc )

Deliverables Strategy Recommendations Risk Assessment and Contingency Plans

Session 5 Project Charter

Review the factors and decisions discussed in the meeting Verify that everyone is in agreementfor presentation to the project board The Project Charter generally consists of the sections listedbelow however the Project Manager will tailor it to fit the project

1 Project Overview

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2144

Pre-Planning 04032006

21

2 Background

3 ProblemVisionMission Statements

4 Scope Statement

5 Exclusions (if applicable)

6 Scope (and Project Stages)

7 Benefits (to Business to Customer and to Company)

8 Success Factors (how to measure success and factors that affect it)

9 Project Board and Team Members

10 Stakeholder Communication Plans

11 GovernanceIssue Resolution

12 Strategy Proposal (with Known Assumptions and Dependencies)

13 Strategy Risks and Contingency Plans

Deliverable Complete Project Charter

7 Present Project Charter

Present the completed Project Charter to the project board for approval to proceed with planning

phase

Deliverable Project board decision to proceed (or cancel)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2244

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2344

Planning 04032006

23

Planning

1 Convene project team (Planning Kick-off Retreat)

After the project board has given approval to begin the project the PMO will convene the projectteam again The team will brainstorm to identify all the deliverable tasks that need to be handled(or specrsquod) for the project For repeat projects the team may review and update an existing WorkBreakdown Structure or task list in lieu of a full-fledged planning retreat

Note The length of this meeting will vary with the complexity of the projects We canprobably expect it to last anywhere from an hour to a couple of days Participants shouldbe asked to clear their schedules

Identify Tasks

Identifying the deliverable tasks may take the form of Gap Analysis or Work BreakdownStructure The goal will be to identify what should be done not how it should be done Theproduct of this meeting will be a master listindex of tasks that will need to be completed or that will need specifications written and perhaps some high-level guidelines for those specifications

These tasks will be grouped as appropriate and assigned a number that will be used as a referenceto that function in all associated documents

This number is a nine-position code The first three digits identify the project the next threedigits identify the task category and the last three digits identify the actual task (assigned in a one-up fashion) For instance CN1-001-001 would translate to conversion project (first round)category 001 task 001 So for example assume that ldquopolicy changesrdquo is category 001 The tasksmight be ldquochange of name (CN1-001-001)rdquo ldquochange of beneficiary (CN1-001-002)rdquo ldquochange of owner (CN1-001-003)rdquo and so on These identifiers are automatically assigned when the tasks areentered in MS Project

The group will prioritize the list especially to identify any that need to be handled in order forGap Analysis to proceed (such as product setup) We will plan to address those first and allow the necessary work to be completed as soon as it is determined

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2444

Planning 04032006

24

Deliverable Final Approved List of Tasks

Task Analysis Workgroups Sign-Up

The team members will be given the option to sign up for task analysis workgroups Possibledecisions include

1 Sign up as a responsible party This option is selected when the team memberrsquos area issignificantly impacted by the task and the team member is the arearsquos expert on the task Theteam member will be expected to give sign-off approval on the completed specification

2 Sign up as an interested party This option is selected when the member is interested in thetask but does not have a major stake in the process The member would be notified whenspecifications are complete and given the opportunity to have feedback but would not beexpected to give sign-off approval on the completed specification

3 Sign up a responsible or interested delegate This option is selected when the member is notthe arearsquos only expert on the task and the member wants to substitute another person for the workgroup

Each workgroup should have at least one responsible party from the affected area oneprogramming representative and one QA business analyst

As homework each workgroup will be asked to research that task including any currentprocessing legislation or other legal requirements prior decisions output etc

The PMO will review the sign-ups for the following issues

1 If PMO staff sees that one person is over-represented on workgroups it may be a sign thatthe person could eventually be overloaded and hold up the project The PMO will work withthe area managers to avoid this situation and obtain delegates as appropriate

2 If the team doesnrsquot include at least one responsible party from the business area QA andprogramming the PMO will ask the area manager to appoint a subject matter expert torepresent the area

3 If the workgroup is too large we will re-evaluate the task to see if it is too broad or determine whether fewer people can handle it

Deliverable WorkgroupTask Assignments Research Homework

2 Convene workgroups (Functional Kick-off Meetings) (optional)

If task workgroups will be working independently the Project Manager may schedule meetings with resources beginning tasks The goal of the meetings is to review the task complete task analysis (including any Gap Analysis if we are dealing with an existing system or process)reviewfinalize the complexity and priority and if system changes are required decide on aframework for the change (ie identify all the sub-tasks within the task)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2544

Planning 04032006

25

Component 1 Complete task analysis

The task analysis document should clearly outline the process the objective and the businessneed

The group should decide whether a functional specification is needed to outline any changes

required If no functional is required but tasks need to be completed the PMO will staff will ask for an estimate on how long it will take to complete the task If testing will be required we willalso ask for estimates to complete testing

When possible ldquotime-to-completionrdquo estimates should be given based on a range of best-caselikely and worst-case scenarios One of these ranges should be selected as a base for scheduling The projectrsquos risk assessment should be used as the determining factor in the selection processLow risk projects should use the best case or realistic estimates For riskier projects the realisticor worst case estimates should be used However all three sets of figures should be included inthe project estimates so that the project board is fully informed regarding potential projectschedules

The following technique should be used when estimating the length of time that will be requiredfor a particular task

1 All team members must be provided with relevant information

2 The project risk assessment should be reviewed

3 The work breakdown structure should be reviewed

4 Each team member should individually estimate the time required to complete the task and provide a best case likely case and worst-case estimate

5 The team should review ldquofirst cutrdquo estimates

6 Each team member should discuss the assumptions and issues they considered whendeveloping their estimates

7 The estimates should be adjusted if a team member decides that the information learnedduring the assumption discussion warrants a time estimate change

8 Estimate outliers should be discarded in each range

9 An average for each range should be computed after the outliers have been discarded

10 The applicable range should be selected based on the project risk

11 The team should conduct a reality check before the estimates are adopted

Project managers should ask team members to not include ldquolagrdquo time in their estimates forindividual tasks These individual task completion buffers heavily distort a projectrsquos critical pathIn order to account for unexpected delays etc a time buffer for critical path delays will be addedto the estimated end of the critical path by the project manager

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2644

Planning 04032006

26

The group should also decide whether there is a ldquoquick fixrdquo option for the task ndash a non-systemmodification (eg procedure change template worksheet etc) that can be easily implemented toameliorate the problem while a total solution is completed)

Component 2 Establish functional specification framework (if applicable)

If it is determined that a functional specification is required the group will discuss a direction thefunctional should take When it is clear what information the team needs to decide on the PMOstaff will ask for an estimate on how long it will take for the workgroup to finish the specification

In most cases the QA business analyst will drive the functional process and be responsible for writing the specification The PMO staff will assist as needed and the QA business analyst willhave the option to add a technical writer to the team

Note Workgroups are free to go ahead and begin their specifications as soon as they are readyrather than to wait on a completed Planning Schedule The Planning Schedule will likely be ldquobackdatedrdquo to include the workgroup kick-offs as the first stage of planning

Deliverables Complete Task Analysis documents Functional Specification Framework (if needed) and Planning Schedule

3 Complete requirement definitions

If the requirements management process is being used the Project Manager will work with aBusiness Analyst or someone filling the role of a Requirements Analyst to create and implement aRequirements Management plan The Project Manager may also consider a distributed approachto requirements definition where resources work more independently The plan will be tailoredto fit the project

For details on the established PM processes for Requirements Management refer to Appendix B These processes are loose guidelines that are applied as makes sense for the Project Manager theproject team and the project itself

The Requirements Definition Document will be written using a template provided and it willinclude procedures system specifications data specifications prototypes reportletter samplespre-requisitesconstraints and any other needed information

Note As prototypes are completed we will consider doing some basic usability testing on thedesign

When the group completes a draft the requirements analyst or business analyst should submit itfor the following reviews indicating that the specifications are subject to change until final sign-off

1 Programming should review the specification for technical feasibility and indicate anestimated programming time (hours and duration)

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2744

Planning 04032006

27

2 QA should review the specification for testing strategy and indicate an estimated testing time(hours and duration)

3 Any interested parties should review the specification for commentsquestions

4 The PMO staff should review the specification for integration with other tasks and as a

neutral 3rd

party

5 When the above reviews have taken place all responsible parties should perform a final review and sign off These areas should also provide estimated user acceptance testing and training times (hours and duration)

Note Official sign-offs will be done with pen amp paper scanned signature or in SharePoint versioning as directed by the Project Manager

When sign-off is complete the QA business analyst will update the specification indicating whosigned off and when post the specification in the SharePoint Project Library notify the PMOthat the specification is complete and forward the signed specification to the PMO for filing

All team members will be informed as to the next steps (such as technical strategy or detailed testplans) and ask them to be thinking about them (keeping in mind that there is a chance that theproject could be cancelled)

The Project Manager will oversee this phase to make sure the project stays on chart with thePlanning Schedule If a requirements analyst or business analyst is managing the requirementsprocess he or she is expected to keep the Project Manager fully informed of all requirementsactivities

Deliverable Completed signed-off RDDs or Specifications for applicable tasks and stages of the project including programming testing and training estimates (hours and

duration)

4 Prepare implementation plan

Based on the estimates included in the Functional Specification as well as any pre-requisites thePMO staff will prepare an Implementation Plan or Software Project Plan A sample SoftwareProject Plan is available in the PMO Documents library This document consists generally of thesections below but may have more or less information as suitable for the project

The Implementation or Software Project Plan may include alternate scope models if applicable

such as an ldquoinitialrdquo or ldquopilotrdquo rollout before the final rollout at the end of the project

Schedule

A schedule will be developed based on the estimates (hours and duration) given in thespecifications Stages deliverables key decision points and exit criteria for each item will beestablished Even if a project is broken into stages the project is not considered completeuntil the last stage is implemented unless the project board makes a formal decision tocancel or close the project

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2844

Planning 04032006

28

Each task in the schedule is assigned to team or workgroup members as appropriate

A schedule contingency period will be built in probably at the end of each testing phase Thelength of this period will be based on a sigma level as determined by the PMO based on thecomplexity of the project and our previous experiences This will allow for any unforeseenproblems to be handled without affecting the overall schedule (and ultimately the Go Live date)

but any problems will still be reflected in the project costs (because no costs are budgeted for thatperiod) so that we know to address these problems in the future

Cost

Based on the schedule estimated and labor costs a total project cost will be estimated

Communications

A communications plan will be established it will describe the PMOrsquos plans for communications

about the project what points in the process will trigger those communications what will becommunicated and to whom

We will also determine the format of those communications

Possible recipients of such communications include the project board the project team the workgroups SFBLI management key employees and the agency force

Performance Reporting

The PMO will apply performance reporting methodology to the implementation plan This

methodology will measure whether each phase of the project is on track to meet establishedperformance scope cost and time estimates A critical ratio will be used to determine whether atask is within allowable limits of being on time and on budget (the cost and schedule indicators inMS Project will measure these performance items)

Change Control

A formal plan for managing change control (changes requested after sign-off of specifications) will be established Any changes requested after sign-off will be reviewed to determine whetherthey impact scope necessary communications will take place and if appropriate the request willbe provided to the project board for approval See also the Change Management section of the

PMO Requirements Management Process document in Appendix B

Roles amp Responsibilities

A list of the roles and responsibilities of project team members may be formally outlined

Deliverable Software Project Plan document or Project Plan document

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 2944

Planning 04032006

29

Note If any change in scope arises during planning or implementation it should bedocumented in the Project Charter and sent back through the Project Board for review (and approval if necessary)

5 Convene project team

The PMO will re-convene the project team to review the proposed implementation plan We willexplain the process if the project goes forward and iron out any concerns or differences (ThePMO may opt to distribute the proposed plan for review prior to the actual meeting with thecaveat that the implementation plan is subject to change until a final draft is prepared forthe project board )

The group will perform Risk Analysis to determine any risks or threats to the plan (such aspending legislative changes interest rate changes seasonal schedules such as contest etc) Thismay be an informal discussion process or a more formal process (resulting in an RPN calculationrisk register andor contingency plans (including a modification to the schedule when

appropriate) etc)

As part of the analysis the team should consider any risks that were identified during preliminary planning as well as any that have come to light as a result of planning As more is known aboutthe project work itself additional risks may be identified See sfbfp4PMOPrivatePMODocumentsRisk Assessment Worksheetxls

Definitions A risk is something that can go wrong and interfere with the completion of project work A threat is something that is imposed by an outside force and isbeyond our control

When the project team is finished reviewing the plan including risks and contingencies a finalimplementation plan will be distributed to each project team member for approval The ProjectManager may institute a Risk Register to monitor risks throughout the life of the project as therisks come into play at different times over the life of a project Seehttpsfbprojectsitesprojectserver_120ListsRisksAllItemsaspx

6 Present implementation plan

The project manager will present the final Implementation Plan to the project board for approvalto proceed In addition to the plan present PMO plans for Performance Reporting for theimplementation phase

If the decision is to cancel the project board should provide a formal decision and direction whether to re-work the plan and re-submit or to close the project

If approved the project will then proceed using either the In-house Model or the Vendor Model

Vendor selection coding or testing should not begin until the project board hasapproved the plan to proceed

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3044

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3144

Execution amp Control General Principles 04032006

31

Execution amp ControlGeneral Principles

Measurement

The PMO will monitor the plan during the execution phase to verify whether the project is oncourse as decided in the projectrsquos communication plan

Measurement will be a matter of informal status discussions as well as formal measurementmethodology (the Schedule Performance Index)

Methodology

For each task the amount of work actually performed (EV) will be monitored at key points andcompared to the amount of work that was planned (PV) to that point (this will be somecombination of percent complete and hours worked) If there is a significant deviance (+- 20)in a particular task ndash either in work completed or in hours worked ndash the PMO staff will address it The Earned Value calculations can be automatically performed in MS Project and the ProjectManager can monitor progress from there as befits the project

When there is a deviation from the plan the PMO will want to know what caused it and whatshould be done to correct it The PMO will then determine if the deviation is negligible willrequire steps to get back on track or will require a change to the plan

If the deviations in the overall project become significant as defined by the PMO we willdetermine if the project should be presented to the project board for further guidance

Hour Tracking

For proper measurement we will need accurate hour tracking from everyone involved in theproject including PMO staff programming business analysts test analysts and any support staff At a minimum we expect hours tracked daily and reported weekly

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3244

Execution amp Control General Principles 04032006

32

Reporting

Reports spreadsheets or charts will be generated as needed to give project status information

Change Control

Any changes requested after sign-off will go through a formal change control process

Any requested changes should be formally submitted to the PMO The PMO will work with therequesterworkgroupsteam members to perform an impact analysis and determine whether thechange impacts scope Based on input from the project team the PMO will determine whetherthe change should be approved

If the change represents a major impact to the project or its scope it will be presented to theproject board for approval

1 If the decision is to approve the change notify all team members Any related

documentation (functional specifications technical strategy test plans procedures etc) willbe updated and the change will be implemented

2 If the decision is to postpone the change for a later phase or project we will document therequest in the project library for follow-up at the appropriate time

3 If the decision is to decline the change we will document the request and the reason it wasdeclined in the project library

For additional information on controlling changes (specifically deviations from establishedrequirements refer to the Change Management section of the Requirements Management processoutlined in Appendix B

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3344

Execution amp Control In-house Software Model 04032006

33

Execution amp ControlIn-house Software Model

1 Coding

Coding will be scheduled according to the resources and estimates given during the planning stage This phase includes development of a technical strategy document coding and unittestingstandards review

Hours should be logged according to project task

Note During this phase business analysts should be researching and outlining what they willneed to do during the upcoming testing phases (test plans)

2 Procedures

In conjunction with coding technical writers should work with area business analysts anddocumented specifications to write area procedures for use during QA testing UAT and training

3 QA functional and integration testing

As milestone deliverables are completed in programming they will be sent to QA for testing asoutlined in the project plan

4 User acceptance testingQA regression testing

This testing takes place when the entire system is ready for review It is done in combination withQA and the user areas as outlined in the project plan

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3444

Execution amp Control In-house Software Model 04032006

34

5 Training

Note This phase can take place in conjunction with UAT and regression

This includes user training help desk training andor agency force training (or notification asapplicable)

6 Go live

On this date we will go live A project could have an initial rollout date or dates in addition to afinal go live date

For repeatable processes Project Managers are encouraged to develop and implement Go Liveplans or checklists These plans are reviewed during the ldquoReflectionsrdquo portion of projectcloseout and modified if needed for the subsequent related projects

7 Post-project review

Final project report

The PMO will prepare a final report (such as whether targets for performance cost scope andtime were met) The report will be distributed to the project team project board and Executive Vice President CEO It will also be stored in the project library for general access

Reflections

The PMO will call a meeting for final post-project review and to review the final report Thegroup will also discuss what went well and what should be improved for the next project

Administrative closure

All final project documents should be collected and archived in the project library

Note This is also a good time to send commendations to the supervisors or managers of teammembers who performed exceptionally during the project

Additional project closure information

As with other repeatable PM processes the Project Manager is encouraged to develop andimplement a Project Closure plan or checklist A sample is included in Appendix C

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3544

Execution amp Control Vendor Management Model 04032006

35

Execution amp ControlVendor Management Model

Basic Steps

The basic steps for implementing a vendor model are outlined below These processes arecustomized to fit the project at the Project Managerrsquos Discretion Steps 6 and following typically mimic other in-house projects

bull 1 Prepare RFP

bull 2 Solicit bids

bull 3 Grade bids

bull 4 Select vendor

bull 5 Complete contract

bull 6 Receive product

bull 7 QA testing

bull 8 User acceptance testing

bull 9 Training

bull 10 Go live

bull 11 Post-project review

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3644

PMO Process Requirements Management July 2007

36

Establish Project Board

Establish Project Team Obtain written approval from supervisormanager for each project teammember for each new project or project phase

Appendix AProject Initiation Checklist

Receive or write project mandate Submit to project board for approval

Add any new resources to the Enterprise Resource Pool Remember the following custom fields Alternate TD Assignment (Enterprise Text27) - the programming manager

TD Login (Enterprise Text30)

Set up MS Project file with enterprise fields resources and any placeholder tasks Remember thefollowing custom fields TestDirector Id (Enterprise Number19) - populate this field when programming identifies a task

that should be copied to TestDirector - after the TD item is created Set up the code mask for the WBS column and populate it Set up the WBS and TestDirector Id fields to publish to Project Web Access (See related

procedures) Publish the MS Project file to create a new SharePoint site

Notify Polly Davis about the new site so she can add it to the list of back-ups Modify the permissions for the SharePoint site to allow anonymous access Add a link to the PMO department home page and the Project Web Access home page to the

new SharePoint site

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3744

PMO Process Requirements Management July 2007

37

Review access for team members (including suppliers if applicable) Review TestDirector procedures for any changes needed Post them on the SharePoint

Set up appropriate SharePoint libraries (eg Task Deliverables General Project Documentsetc)

Modify permissions on libraries as needed to lock down any libraries you donrsquot want teammembers to write to

Modify library settings to version all documents Set up any library alerts you need Set up any issue logs change control logs etc necessary for the project Illustrations Set up links library with descriptions of regions Update link from PMO home page

Post the approved Project Mandate Review TestDirector for any set-up needed

Request that the new Project be added

Call project team for Project Charter WBS task assignment etc using established PMOprocesses

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3844

PMO Process Requirements Management July 2007

Appendix BPMO Requirements Management Process

Version 04

Date August 1 2007

Author Amanda Orgeron

Document History Table

Version Release Date Description of Changes

01 7242007 Initial draft of PMO process governing RequirementsManagement

02 7252007 Added section regarding Requirements Workshops

03 7272007 Added ldquovalidationrdquo as part of Requirements Analysis addedprocedure drafts as analysis technique

04 08012007 Added process regarding vendor resource availabilityvendorestimate cost prior to approval hen the change order and work order approval

05 9182007 Updated Requirements Analysis section with additional bulletpoints

38

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 3944

PMO Process Requirements Management July 2007

Purpose of This Document 40 Glossary 40 Components of the Requirements Management Process40

Requirements Planning40 Requirements Gathering amp Elicitation 40 Requirements Definition41 Requirements Analysis41 Requirements Verification 41 Requirements Change Management41

Guidelines for Requirement Workshops42

39

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4044

PMO Process Requirements Management July 2007

Purpose of This Document

This document is an overview of the requirements management process as currently appliedin the SFBLIC PMO These processes will be applied as applicable to the project in

question and are to be considered a guideline more than a rulebook

Glossary

bull Requirements Analyst - the person assigned the role of overseeing and managementrequirements definition activities This may be a Business Analyst Technical Writer or otherproject team member

bull Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst andor Requirements Analyst assigned to the project outlining the requirements for thesolution

Components of the Requirements Management Process

Requirements Planning

A project team Requirements Analyst (RA) will be requested or assigned to the project at theproject managerrsquos (PM) discretion The PM will meet with the assigned RA andor key BAsto form a Requirements plan for the project

Refer to the Requirements Plan Template for components of this process The

Requirements Plan will also cover the areas below

Requirements Gathering amp Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirementsBelow are some activities the RA may implement The PM and RA will select appropriateactivities and define them in the Requirements Plan for the project

bull Review WBS

bull Conduct SMEStakeholder interviews

bull Hold requirements workshops

bull Review historical project or requirement Information

bull Review legal or compliance documentation

bull Review existing or ldquogaprdquo system

40

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4144

PMO Process Requirements Management July 2007

bull Develop process flow charts (esp for new processes or functionality)

bull Review existing Production or Help Desk issues

bull Obtain feedback from Surveys Agent Focus Group etc

bull Observe users interacting with the system

Requirements Definition

Based on the requirements collected during gathering amp elicitation as well as the items in thetask list or WBS the RA will draft a Requirements Definition Document (RDD) The RAmay be a technical writer or may choose to partner with one or may work without atechnical writer The RDD will be written according to the guidelines in the RequirementsDefinition Document template

Requirements Analysis

The RA will hold a review of the RDD with other responsible parties in the project(including team members resources or other stakeholders as applicable to the project) toanalyze the requirements that have been defined The purpose is to uncover any missing requirements reconcile any conflicting requirements and make sure all parties fully understand of the document

Techniques may include

bull Have the document reviewed by stakeholders outside of Requirements Team

bull Perform system gap analysis

bull Draft end use procedures to uncover missing details

bull Review against similar functionality in same or related systems

bull Compare to prior issuedefectCM history

Requirements Verification

Requirements verification is an ongoing process of ensuring that the developing productmeets the defined requirements The PM may use a Traceability Matrix to oversee thisprocess It is also a part of quality testing

Requirements Change Management

Items that were not defined (or incorrectly defined) in the Requirements DefinitionDocument will be handled via a Change Management processes

41

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4244

PMO Process Requirements Management July 2007

1 The person discovering the deficiency will report it in TestDirector

2 The reporter the PM or the developer involved may flag the TD item as a ChangeManagement issue by selecting ldquoChange Managementrdquo in the PMO Request Type field

3 The PM will then ask for a review of the item according to the Change Management

processes for that project - but it should generally include a description of the changethe justification and severity and any other piecesoutputfunctionality that may beaffected by the proposed change

4 The item will be forwarded to the developer (in some cases an outside supplier) forevaluation (For instance for a new work order)

5 The affected resources will determine whether to approve the item or defer it to a futureproject The decision must be logged in the TD item

6 A change control log may be kept (for example on the SharePoint site) to track thestatus and keep a log of all change management items

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather elicit and definerequirements

Workshops should always have facilitator who assists the group by leading the process The facilitator

o ensures that the necessary requirements are delivered at the right level of detail and

with the necessary degree of quality

o designs a sequence of activities that follows a logical progression with regard to timerestraints promotes participation and keeps participants energized and engagedand

o helps participants build relationships exploits the strengths of different styles of thinking and helps participants become a high-performing group

The facilitator should be neutral to the outcome experienced with group process andknowledgeable about the deliverables that need to be created

Workshops should always have a recorder who captures the grouprsquos work in real time

The facilitator and recorder should not be the same person These roles can be filled by theappointed Requirements Analyst a Business Analyst or a Technical Writer

The workshop becomes less effective if too many people attend The number of participants should not exceed 16 typically between 7 and 12 can complete the deliverable

42

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4344

PMO Process Requirements Management July 2007

Appendix CProject Closure Checklist

Verify that all tasks are complete

Verify that all pertinent documents (eg project board approvals go-live approvals finalTestDirector reports etc) are posted on the SharePoint site

Verify that signed paper copies of pertinent documents are stored in the filing cabinet

Conduct a Project Closure review and write up a final project report including overall projectevaluation (against the Charter and PCST targets) improvements seen during the project andimprovements to make in future projects

Circulate the report among the project team for approval

Add final costs and metrics to the Project Closure report Have it reviewed by the PMODirector

Prepare a cover memo to the project board for the final report and ask formal permission toclose the project

For any outstanding performers send Thank You notes as appropriate

Save a final copy of the MS Project file on the SharePoint site

Add a Project Note indicating that the project has been closed

Change the project SharePoint site permissions to read-only for everyone exceptadministrators

Delete the MS Project file from Project Web Access

Notify Polly that the back-ups for the SharePoint site can be changed to an ldquoarchived projectsrdquoschedule

43

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate

832019 2008 Mar PMO Handbook Rev 20Mar2008

httpslidepdfcomreaderfull2008-mar-pmo-handbook-rev-20mar2008 4444

PMO Process Requirements Management July 2007

On the PMO home page move the project SharePoint site link from the list of active projects tothe library for archived projects Remove any other links as needed (eg Link libraries forIllustrations)

On the PWA home page remove the link to the project SharePoint site

Celebrate