PMO Handbook

Processes and Procedures Governing SFBLICs Project Management Office

Revision Date: March 20, 2008

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 tools........................................................................................................................................................ 15 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: Strategy..................................................................................................................................................... 18 Session 5: Project Charter................................................................................................................................................ 20 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

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 Schedule.............................................................................................................................................................................. 27 Cost ..................................................................................................................................................................................... 28 Communications ............................................................................................................................................................... 28 Performance Reporting.................................................................................................................................................... 28 Change Control ................................................................................................................................................................. 28 Roles & Responsibilities .................................................................................................................................................. 28 5: Convene project team ........................................................................................................................................................ 29 6: Present implementation plan ............................................................................................................................................ 29

Execution & Control: General Principles ...................................................................31

Measurement ........................................................................................................................................................................... 31 Methodology...................................................................................................................................................................... 31 Hour Tracking ................................................................................................................................................................... 31 Reporting............................................................................................................................................................................ 32 Change Control ....................................................................................................................................................................... 32

Execution & Control: In-house Software Model ....................................................... 33

1: Coding .................................................................................................................................................................................. 33 2: Procedures ........................................................................................................................................................................... 33 3: QA functional and integration testing............................................................................................................................. 33 4: User acceptance testing/QA regression testing............................................................................................................. 33 5: Training ................................................................................................................................................................................ 34 6: Go live .................................................................................................................................................................................. 34 7: Post-project review............................................................................................................................................................. 34 Final project report ........................................................................................................................................................... 34 Reflections.......................................................................................................................................................................... 34 Administrative closure...................................................................................................................................................... 34 Additional project closure information ......................................................................................................................... 34

Execution & Control: Vendor Management Model .................................................. 35

3

Basic Steps................................................................................................................................................................................ 35

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

Introduction

03/20/2008

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 content Projects should be totally issues (technical deliverables, tasks, documentation, defect correction, etc.) and context issues focused on added value (managerial, political, and social). It is widely believed that project fail due to content issues; it is and benefits realization. lesser known that projects also fail due to context issues.

PMO Promises
1. We will only do work (call meetings, request documents, etc.) that adds value to the process. If it does not add value, we will eliminate it. 2. We will not attempt to manage any managers area for him or her. We will provide projectrelated support and structure, and be the go-to area for project questions and guidance. On the other hand, the Project Manager is ultimately responsible for the overall project, and will do 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-related support, guidance, and accountability. In return, the Project Manager expects Team Members to provide accurate and timely communication regarding project activities. 4. We will provide regular communication to the project stakeholders and the company at large as 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 and commit to making them. With every project we will attempt to improve our estimates and planning methodology. Note: Exceptions to this rule may be required at times, due to legal or compliance reasons, or business-critical senior management directives. In those cases, the Project Manager will work with the team to revise the plan to meet those deadlines.

Introduction

03/20/2008

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 as appropriate to the project.

Introduction

03/20/2008

Introduction

03/20/2008

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

Introduction

03/20/2008

Introduction

03/20/2008

10

Introduction

03/20/2008

Planning Methodology
p. 4 03/20/2008 PMO

Decision

Does project board approve?

No

Modify plan?

No

Project cancelled and closed.

Yes

Yes

Plan is executed.

Planning work continues

Plan project.

11

Pre-Planning

04/03/2006

Preliminary Planning

1: Receive project mandate

The PMO will receive project mandates from the Executive Vice President, CEO. The PMO will review 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 the project 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 condensed/overview 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 well for repeatable processes). The Checklist may be tailored to suit the Project Managers or projects specific needs.

2: Organize project team

In order to avoid large, unwieldy teams and unnecessary levels of bureaucracy, we will minimize 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 A business analyst from the requesting area 2. Suppliers Programming A programming representative from the group responsible for the project area (typically the supervisor) QA Representative A QA business analyst (or supervisor or manager) with expertise in the project area
13

Pre-Planning

04/03/2006 Other anyone from another area who will provide resources to produce the final product (e.g. Financial Reporting, Legal, etc.) 3. Customer A representative for the agent force, when affected by the project (could be someone from a marketing area) 4. Affected Areas A representative from any area, such as accounting or another service department, that will be impacted by the project 5. PMO A representative (or two) from the Project Management Office (who will serve as team leader) 6. Auditing The Internal Audit Manager will be notified of meetings, documents, etc., and will send auditing representatives when needed After identifying the major players, a representative from the PMO will meet with the appropriate department managers to outline the level of time, effort, and commitment needed from that person and to obtain permission for him/her to be on the team. For teams that are being reconvened, this allocation may be handled via email rather than meeting. In either case, the approval for the team members appointment should be stated in writing. We will discuss resource allocations with the manager, but not mandate them. We will ask the manager to have a discussion with the employee about how much of his/her time can be devoted to the project and ask them to come to an agreement about it. The project manager should clearly outline the responsibilities the resource is expected to fulfill: e.g. making decisions on behalf 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 Office 2003 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 the Executive Vice President, CEO. The project board members must be a VP or higher., and typically consists of: 1. Project Sponsor, usually the Senior VP over the area with the greatest business interest in the project This person chairs the project board, commits resources and support from the area, and resolves any conflict that arises at the project board level. 2. Senior Client, usually the VP over the area that owns the project 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 & sponsor.

3. Senior Supplier, usually the VP over Information Systems This person represents QA and Programming, as the major suppliers on any software development projects.

14

Pre-Planning

04/03/2006 The PMO Director will convene the initial meeting. The Director will discuss what is expected from 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 notification/discussion may 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 feel confidant that the team will meet them). Deliverables: Approved Project Mandate, Proposed Team Members, and Team Member Bill 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 will be given authority to check documents in and out of the site, and the PMO staff will periodically review the Library to do any clean-up work needed. Note: The PMO will establish naming conventions that will apply to each document in the project.

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, and/or Traceability Matrix 6. Functional/Design Specifications (including fleshed out business and technical specifications) 7. Test Plans 8. General Product/Project Documents 9. Links to Related Information 10. Programming Documents, as applicable Project-level: Technology Description/Strategy Project-level: Standards/Interface Style Guide Task-level: Technical Strategy Modules Affected Plain English Code Functionality
15

Pre-Planning Completed Data Specifications Deliverable: SharePoint Project Library

04/03/2006

TestDirector (aka HP QualityCenter)

The PMO will work with an assigned QA contact to make sure a project is set up in TestDirector for 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 the instructions to the Team Members. We may choose to reserve the granting of project permissions until the testing phase, so that project 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 lists, any 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 (or missed targets) during the Execution and Control phase the assigned person or the supervisor/manager. Each supervisor will be given the option to be the contact or have the PMO 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 a training session with the QA or business area analysts and/or programmers to give them an overview of the project (including the methodology for developing product specifications/task analysis meetings). We will clearly explain what is expected of them throughout the process, so that they are fully prepared for the kick-off meeting. We will discuss the importance of time tracking not for us to evaluate how quickly each person is performing but as a measure of project costs and schedule, and as a resource to improve future 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-hour increments. It should take no more than about five minutes a day.

16

Pre-Planning

04/03/2006 We will also discuss the importance of estimating good percentages in task statuses not as a way to keep tabs on people, but as a way of measuring project progress. The members should immediately 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 will handle that one-on-one with the resource or the resources 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, what follows 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 possible, designate 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 Mandate/Overview/Background 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. Problem/Vision/Mission 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 the stakeholders want from the project, and how best to communicate important project information to them.

17

Pre-Planning

04/03/2006

Component 3: Direction Statements

Note: For repeat projects, this step may be skipped. It should still be included in the Project Charter.

As applicable, PMO staff will guide the team through the process of developing problem, vision, and 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 workflow/processing. The group will then combine these items and categorize 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 whether there is a quick fix option a non-system modification (e.g. procedure change, template, worksheet, etc.) that can be easily implemented to ameliorate the problem while a total solution is completed.

2. The Vision Statement will turn those problems into positives. Our vision of the end product 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 be isolated and left to the area to handle accordingly.

3. The Mission Statement will indicate that our mission is to achieve the vision outlined above. Deliverables: Problem, Vision, and Mission Statements

Component 4: Strategy
The last step in the kick-off meeting will be determining the overall game plan or strategy on how 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 suggestions; however, 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 where the committee is leaning in terms of those decisions. Consider it a general project/aspect approach. These big decisions should include:
18

Pre-Planning

04/03/2006

How will the project mission be accomplished? Development options that the project team should consider include: 1. Fix It Make modifications to an existing system. 2. Build It Build a new system from scratch. 3. Buy It Buy a new system and use it As-Is. 4. Customize It Buy a new system and modify it or our systems as needed. 5. Outsource It 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 strategies include: 1. Monolithic or Waterfall This strategy involves developing the system or product as a whole with each project phase as a stand-alone activity. Subsequent phases are not started until the prior phase is completed. This strategy is only recommended for small, low risk projects since it generally takes much longer to see a completed product, and because it is totally inadequate for handling requirement changes. If a change is necessary, the team would have to either ignore the change 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 then producing and implementing an operating subsystem or product as Version 1 or Release 1, then a second subsystem as Version 2 or Release 2 , and so on. For example, release 1 may consist of a stand-alone product that does not have all of the desire features. Release 2 would add additional features to the product. The interfaces between the releases must be carefully managed to avoid serious problems. 3. Concurrent Release This strategy involves multiple teams working on different pieces of a system and product 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 that each release team works independently of the other release teams. Given that fact, the releases may be in different development phases. This will significantly increase the managerial complexity of the project.

19

Pre-Planning 4. Fast Track, or Production Prototyping

04/03/2006

This strategy involves producing a working production prototype as quickly as possible. The whole requirement is developed as quickly as possible with careful and planned degradation of quality. The initial version of the system or product is then redeveloped through a series of reengineering projects that include additional functionality. This release strategy should be considered for high risk projects - it is less exposed to changes since the product is usually delivered before the requirements can change. The downside of this strategy is that support costs are significantly higher than for the other strategies due to the typically low quality of the initial delivery. Very sophisticated and professional project management is required to execute this strategy. 5. Hybrid A variation of the concurrent release strategy that involves a series of concurrent releases that use different release strategies. If the team is making a strategy decision, use the following methods, as applicable: 1. Perform a Risk Assessment. (See \\sfbfp4\PMO\Public\Downloads\Lewis Institute Forms\Risk Probability Analysis.doc The relationship between project risk and project strategy should be considered by the team. In general, the higher the risk of the project, the more risky your project strategy should be. A classic 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 minimize or reduce the risk factors. All high risk factors that cannot be constrained or eliminated during 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 \\sfbfp4\PMO\Private\PMO Documents\High Risk Memorandum.doc). (As an alternative, the risk may be recorded on the project SharePoint sites Risk Log.) 2. Will the selected strategy satisfy performance, cost, scope, and time requirements (as we understand them at the current time)? Eliminate any strategies deemed to not be feasible at this time. 3. Perform SWOT analysis. (See \\sfbfp4\PMO\Public\Downloads\Lewis Institute Forms\SWOT Analysis.doc) 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 agreement for presentation to the project board. The Project Charter generally consists of the sections listed below; however, the Project Manager will tailor it to fit the project: 1. Project Overview
20

Pre-Planning 2. Background 3. Problem/Vision/Mission 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. Governance/Issue Resolution 12. Strategy Proposal (with Known Assumptions and Dependencies) 13. Strategy Risks and Contingency Plans Deliverable: Complete Project Charter

04/03/2006

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)

21

Planning

04/03/2006

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 project team again. The team will brainstorm to identify all the deliverable tasks that need to be handled (or specd) for the project. For repeat projects, the team may review and update an existing Work Breakdown 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 can probably expect it to last anywhere from an hour to a couple of days. Participants should be asked to clear their schedules.

Identify Tasks
Identifying the deliverable tasks may take the form of Gap Analysis or Work Breakdown Structure. The goal will be to identify what should be done, not how it should be done. The product of this meeting will be a master list/index 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 reference to that function in all associated documents. This number is a nine-position code. The first three digits identify the project, the next three digits identify the task category, and the last three digits identify the actual task (assigned in a oneup fashion). For instance: CN1-001-001 would translate to conversion project (first round), category 001, task 001. So for example, assume that policy changes is category 001. The tasks might be change of name (CN1-001-001), change of beneficiary (CN1-001-002), change of owner (CN1-001-003), and so on. These identifiers are automatically assigned when the tasks are entered in MS Project. The group will prioritize the list, especially to identify any that need to be handled in order for Gap 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.
23

Planning Deliverable: Final Approved List of Tasks

04/03/2006

Task Analysis Workgroups: Sign-Up

The team members will be given the option to sign up for task analysis workgroups. Possible decisions include: 1. Sign up as a responsible party: This option is selected when the team members area is significantly impacted by the task, and the team member is the areas expert on the task. The team 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 the task, but does not have a major stake in the process. The member would be notified when specifications are complete and given the opportunity to have feedback, but would not be expected 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 not the areas 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, one programming representative, and one QA business analyst. As homework, each workgroup will be asked to research that task, including any current processing, 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 that the person could eventually be overloaded and hold up the project. The PMO will work with the area managers to avoid this situation and obtain delegates as appropriate. 2. If the team doesnt include at least one responsible party from the business area, QA, and programming, the PMO will ask the area manager to appoint a subject matter expert to represent 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: Workgroup/Task 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), review/finalize the complexity and priority, and if system changes are required, decide on a framework for the change (i.e., identify all the sub-tasks within the task).
24

Planning

04/03/2006

Component 1: Complete task analysis

The task analysis document should clearly outline the process, the objective, and the business need. 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 will also ask for estimates to complete testing. When possible, time-to-completion estimates should be given based on a range of best-case, likely, and worst-case scenarios. One of these ranges should be selected as a base for scheduling. The projects risk assessment should be used as the determining factor in the selection process. Low risk projects should use the best case or realistic estimates. For riskier projects, the realistic or worst case estimates should be used. However, all three sets of figures should be included in the project estimates so that the project board is fully informed regarding potential project schedules. The following technique should be used when estimating the length of time that will be required for 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 first cut estimates. 6. Each team member should discuss the assumptions and issues they considered when developing their estimates. 7. The estimates should be adjusted if a team member decides that the information learned during 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 lag time in their estimates for individual tasks. These individual task completion buffers heavily distort a projects critical path. In order to account for unexpected delays, etc., a time buffer for critical path delays will be added to the estimated end of the critical path by the project manager.

25

Planning

04/03/2006 The group should also decide whether there is a quick fix option for the task a non-system modification (e.g. procedure change, template, worksheet, etc.) that can be easily implemented to ameliorate 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 the functional should take. When it is clear what information the team needs to decide on, the PMO staff 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 will have 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 ready, rather than to wait on a completed Planning Schedule. The Planning Schedule will likely be backdated to include the workgroup kick-offs as the first stage of planning. Complete Task Analysis documents, Functional Specification Framework (if needed), and Planning Schedule

Deliverables:

3: Complete requirement definitions

If the requirements management process is being used, the Project Manager will work with a Business Analyst or someone filling the role of a Requirements Analyst to create and implement a Requirements Management plan. The Project Manager may also consider a distributed approach to requirements definition, where resources work more independently. The plan will be tailored to 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, the project team, and the project itself. The Requirements Definition Document will be written using a template provided, and it will include procedures, system specifications, data specifications, prototypes, report/letter samples, pre-requisites/constraints, and any other needed information. Note: As prototypes are completed, we will consider doing some basic usability testing on the design.

When the group completes a draft, the requirements analyst or business analyst should submit it for the following reviews, indicating that the specifications are subject to change until final signoff: 1. Programming should review the specification for technical feasibility and indicate an estimated programming time (hours and duration).

26

Planning

04/03/2006 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 comments/questions. 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 & 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 who signed off and when, post the specification in the SharePoint Project Library, notify the PMO that 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 test plans) and ask them to be thinking about them (keeping in mind that there is a chance that the project could be cancelled). The Project Manager will oversee this phase to make sure the project stays on chart with the Planning Schedule. If a requirements analyst or business analyst is managing the requirements process, he or she is expected to keep the Project Manager fully informed of all requirements activities. 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, the PMO staff will prepare an Implementation Plan or Software Project Plan. A sample Software Project Plan is available in the PMO Documents library. This document consists generally of the sections 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 initial or pilot 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 the specifications. Stages, deliverables, key decision points, and exit criteria for each item will be established. Even if a project is broken into stages, the project is not considered complete until the last stage is implemented, unless the project board makes a formal decision to cancel or close the project.
27

Planning

04/03/2006 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. The length of this period will be based on a sigma level as determined by the PMO, based on the complexity of the project and our previous experiences. This will allow for any unforeseen problems 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 that period), 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 PMOs plans for communications about the project, what points in the process will trigger those communications, what will be communicated, 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 established performance, scope, cost, and time estimates. A critical ratio will be used to determine whether a task is within allowable limits of being on time and on budget (the cost and schedule indicators in MS 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 whether they impact scope, necessary communications will take place, and if appropriate, the request will be provided to the project board for approval. See also the Change Management section of the PMO Requirements Management Process document in Appendix B.

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

28

Planning Note:

04/03/2006 If any change in scope arises during planning or implementation, it should be documented 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 will explain the process if the project goes forward and iron out any concerns or differences. (The PMO may opt to distribute the proposed plan for review prior to the actual meeting, with the caveat that the implementation plan is subject to change until a final draft is prepared for the project board). The group will perform Risk Analysis to determine any risks or threats to the plan (such as pending legislative changes, interest rate changes, seasonal schedules such as contest, etc.). This may be an informal discussion process, or a more formal process (resulting in an RPN calculation, risk register, and/or 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 about the project work itself, additional risks may be identified. See \\sfbfp4\PMO\Private\PMO Documents\Risk Assessment Worksheet.xls. 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 is beyond our control.

When the project team is finished reviewing the plan, including risks and contingencies, a final implementation plan will be distributed to each project team member for approval. The Project Manager may institute a Risk Register to monitor risks throughout the life of the project, as the risks come into play at different times over the life of a project. See http://sfbproject/sites/projectserver_120/Lists/Risks/AllItems.aspx.

6: Present implementation plan

The project manager will present the final Implementation Plan to the project board for approval to proceed. In addition to the plan, present PMO plans for Performance Reporting for the implementation 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 has approved the plan to proceed.

29

Execution & Control: General Principles

04/03/2006

Execution & Control: General Principles

Measurement
The PMO will monitor the plan during the execution phase to verify whether the project is on course, as decided in the projects communication plan. Measurement will be a matter of informal status discussions as well as formal measurement methodology (the Schedule Performance Index).

Methodology
For each task, the amount of work actually performed (EV) will be monitored at key points and compared to the amount of work that was planned (PV) to that point (this will be some combination of percent complete and hours worked). If there is a significant deviance (+/- 20%) in a particular task either in work completed or in hours worked the PMO staff will address it. The Earned Value calculations can be automatically performed in MS Project, and the Project Manager 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 what should be done to correct it. The PMO will then determine if the deviation is negligible, will require 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 will determine 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 the project, including PMO staff, programming, business analysts, test analysts, and any support staff. At a minimum, we expect hours tracked daily, and reported weekly.

31

Execution & Control: General Principles

04/03/2006

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 the requester/workgroups/team members to perform an impact analysis and determine whether the change impacts scope. Based on input from the project team, the PMO will determine whether the change should be approved. If the change represents a major impact to the project or its scope, it will be presented to the project 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.) will be 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 the request 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 was declined in the project library. For additional information on controlling changes (specifically deviations from established requirements, refer to the Change Management section of the Requirements Management process outlined in Appendix B.

32

Execution & Control: In-house Software Model

04/03/2006

Execution & Control: In-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 unit testing/standards review. Hours should be logged according to project task. Note: During this phase, business analysts should be researching and outlining what they will need to do during the upcoming testing phases (test plans).

2: Procedures
In conjunction with coding, technical writers should work with area business analysts and documented 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, as outlined in the project plan.

4: User acceptance testing/QA regression testing

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

33

Execution & Control: In-house Software Model

04/03/2006

5: Training
Note: This phase can take place in conjunction with UAT and regression.

This includes user training, help desk training, and/or agency force training (or notification, as applicable).

6: Go live
On this date, we will go live. A project could have an initial rollout date or dates in addition to a final go live date. For repeatable processes, Project Managers are encouraged to develop and implement Go Live plans or checklists. These plans are reviewed during the Reflections portion of project closeout, 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, and time 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. The group 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 team members who performed exceptionally during the project.

Additional project closure information

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

34

Execution & Control: Vendor Management Model

04/03/2006

Execution & Control: Vendor Management Model

Basic Steps
The basic steps for implementing a vendor model are outlined below. These processes are customized to fit the project, at the Project Managers Discretion. Steps 6 and following typically mimic other in-house projects. 1: Prepare RFP 2: Solicit bids 3: Grade bids 4: Select vendor 5: Complete contract 6: Receive product 7: QA testing 8: User acceptance testing 9: Training 10: Go live 11: Post-project review

35

PMO Process: Requirements Management

July 2007

Appendix A: Project Initiation Checklist

Establish Project Board. Establish Project Team. Obtain written approval from supervisor/manager for each project team member for each new project or project phase. 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 the following 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.

36

PMO Process: Requirements Management

July 2007

Set up appropriate SharePoint libraries (e.g. Task Deliverables, General Project Documents, etc.). Modify permissions on libraries as needed to lock down any libraries you dont want team members 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. Review access for team members (including suppliers, if applicable). Review TestDirector procedures for any changes needed. Post them on the SharePoint. Call project team for Project Charter, WBS, task assignment, etc., using established PMO processes.

37

PMO Process: Requirements Management

July 2007

Appendix B: PMO Requirements Management Process

Version: Date:

0.4 August 1, 2007

Author: Amanda Orgeron Document History Table

Version 0.1 0.2 0.3 0.4

Release Date 7/24/2007 7/25/2007 7/27/2007 08/01/2007

Description of Changes Initial draft of PMO process governing Requirements Management Added section regarding Requirements Workshops Added validation as part of Requirements Analysis; added procedure drafts as analysis technique Added process regarding vendor resource availability/vendor estimate cost prior to approval, hen the change order and work order approval Updated Requirements Analysis section with additional bullet points

0.5

9/18/2007

38

PMO Process: Requirements Management

July 2007

Purpose of This Document ...................................................................................................................................................40 Glossary ....................................................................................................................................................................................40 Components of the Requirements Management Process.................................................................................................40 Requirements Planning.....................................................................................................................................................40 Requirements Gathering & Elicitation ..........................................................................................................................40 Requirements Definition..................................................................................................................................................41 Requirements Analysis......................................................................................................................................................41 Requirements Verification ...............................................................................................................................................41 Requirements Change Management...............................................................................................................................41 Guidelines for Requirement Workshops.............................................................................................................................42

39

PMO Process: Requirements Management

July 2007

Purpose of This Document

This document is an overview of the requirements management process, as currently applied in 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
Requirements Analyst - the person assigned the role of overseeing and management requirements definition activities. This may be a Business Analyst, Technical Writer, or other project team member. Requirements Definition Document (RDD) - refers to the document prepared by the Business Analyst and/or Requirements Analyst assigned to the project, outlining the requirements for the solution.

Components of the Requirements Management Process

Requirements Planning
A project team Requirements Analyst (RA) will be requested or assigned to the project at the project managers (PM) discretion. The PM will meet with the assigned RA and/or key BAs to 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 & Elicitation

The assigned RA or BA will oversee the gathering and elicitation of known requirements. Below are some activities the RA may implement. The PM and RA will select appropriate activities and define them in the Requirements Plan for the project. Review WBS Conduct SME/Stakeholder interviews Hold requirements workshops Review historical project or requirement Information Review legal or compliance documentation Review existing or gap system

40

PMO Process: Requirements Management Develop process flow charts (esp. for new processes or functionality) Review existing Production or Help Desk issues Obtain feedback from Surveys, Agent Focus Group, etc. Observe users interacting with the system

July 2007

Requirements Definition
Based on the requirements collected during gathering & elicitation, as well as the items in the task list or WBS, the RA will draft a Requirements Definition Document (RDD). The RA may be a technical writer or may choose to partner with one, or may work without a technical writer. The RDD will be written according to the guidelines in the Requirements Definition 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) to analyze 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: Have the document reviewed by stakeholders outside of Requirements Team Perform system gap analysis Draft end use procedures to uncover missing details Review against similar functionality in same or related systems Compare to prior issue/defect/CM history

Requirements Verification
Requirements verification is an ongoing process of ensuring that the developing product meets the defined requirements. The PM may use a Traceability Matrix to oversee this process. It is also a part of quality testing.

Requirements Change Management

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

41

PMO Process: Requirements Management 1. The person discovering the deficiency will report it in TestDirector.

July 2007

2. The reporter, the PM, or the developer involved may flag the TD item as a Change Management issue by selecting Change Management 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 change, the justification and severity, and any other pieces/output/functionality that may be affected by the proposed change. 4. The item will be forwarded to the developer (in some cases an outside supplier) for evaluation. (For instance, for a new work order.) 5. The affected resources will determine whether to approve the item or defer it to a future project. 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 the status and keep a log of all change management items.

Guidelines for Requirement Workshops

Requirements Workshops are structured meetings designed to gather, elicit, and define requirements. 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, designs a sequence of activities that follows a logical progression with regard to time restraints, promotes participation, and keeps participants energized and engaged, and 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, and knowledgeable about the deliverables that need to be created. Workshops should always have a recorder, who captures the groups work in real time. The facilitator and recorder should not be the same person. These roles can be filled by the appointed 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

PMO Process: Requirements Management

July 2007

Appendix C: Project Closure Checklist

Verify that all tasks are complete. Verify that all pertinent documents (e.g. project board approvals, go-live approvals, final TestDirector 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 project evaluation (against the Charter and PCST targets), improvements seen during the project, and improvements 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 PMO Director. Prepare a cover memo to the project board for the final report, and ask formal permission to close 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 except administrators. Delete the MS Project file from Project Web Access. Notify Polly that the back-ups for the SharePoint site can be changed to an archived projects schedule.

43

PMO Process: Requirements Management

July 2007

On the PMO home page, move the project SharePoint site link from the list of active projects to the library for archived projects. Remove any other links as needed (e.g. Link libraries for Illustrations). On the PWA home page, remove the link to the project SharePoint site. Celebrate.

44