2008 Mar PMO Handbook Rev 20Mar2008
-
Upload
desenvolvedorricardo -
Category
Documents
-
view
226 -
download
0
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