ESBD_356196_1713886878548_FNS Handbook 901 v.2.4 (pg 351-490).pdf

7.1 Project Management 7.0 Project Management 349

Plan a reasonable rollout schedule to provide the opportunity for making course corrections and adjustments along the way o Use a phased approach o

Turn to federal and State partners for technical assistance whenever necessary

Role of the Project Manager

A PM should be assigned very early and is ideally involved from the beginning of the project. A PM is not the same as a functional manager. A functional manager is the head of a group of employees with similar skill sets, such as the head of IT or accounting departments. In some cases, a functional manager is the project sponsor responsible for providing the resources for the project. A duty is not focused on particular employee skill sets, but on the project goal as a whole. A project team may consist of employees from multiple departments. As such, the PM must be empowered by the sponsor, and knowledgeable of each functional area to direct the work of team members.

An effective PM is expected be well versed in the following areas of expertise:

Application area knowledge, standards, and regulations (e.g., functional, technical, financial, and procurement) Project environment (i.e., cultural, social, and political) General management skills and knowledge Communication skills Interpersonal skills

While a knowledgeable PM is responsible for efficient project oversight, the PM relies on a knowledgeable State agency and federal project staff. The project staff is equally responsible for being knowledgeable of the critical activities of the project to include efficient use of funds. The project staff should clearly understand the role of the PM and how it relates to their roles.

Further information can be obtained from (http://www.pmi.org) or its A Guide to the Project Management Body of Knowledge.

7.1 Project Management 7.0 Project Management 350

The Project Manager:

Does no work other than managing the project Does not take on assignments or participate as a member of workgroups Keeps the project on schedule, on budget, and within scope Understands the environment in which the project will operate Understands that each project is different depending on the technology, culture, and personalities of critical stakeholders Guides the project toward the most realistic definition of success

Identifies the most disruptive risks and develops response plans with the team that eliminate or reduce consequences Avoids confusion by clearly outlining the critical path when creating the project schedule Establishes the right relationships with team members and stakeholders along with a speedy issue-resolution process Works with complex scenarios and decisions involving numbers, and the politics that may accompany some project decisions Understands that the operations perspective is key to turnover of the system to the production world Is flexible, yet firm, and checks their ego at the door Spends 90% of their other time communicating with and facilitating the project team

Figure 51: PM Responsibilities

7.2 Project Management

Knowledge

7.0 Project Management 351

7.2 Project Management

Knowledge The Project Management Institute (PMI®) is a professional organization recognized as the leader in the project management field.

PMI has organized project processes into five categories.

These five categories are the basis of the Project Management Lifecycle (PMLC) discussed in chapter 2.0:

1. Initiating

2. Planning

3. Executing

4. Monitoring and Controlling

5. Closing

Project Integration Management The processes required to ensure that the various elements of the project are properly coordinated. These include the project charter, project plan development, project plan execution, integrated change control, and project closure.

Project Scope Management The processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. It consists of initiation, scope planning and definition, scope verification, and scope change control. Scope management also includes creating the Work Breakdown Structure (WBS).

Project Time Management The processes required to ensure timely completion of the project. It consists of activity definition, activity sequencing, schedule development, and schedule control, as well as analyzing activity sequences, activity durations, and resource requirements to create the project schedule.

A Guide to the Project Management Body of Knowledge (PMBOK®) is the only American National Standards Institute (ANSI) standard for project management.

Figure 52: PMI Project Processes

7.2 Project Management

Knowledge

7.0 Project Management 352

Project Cost Management The processes required to ensure that the project is completed within the approved budget. It consists of resource planning, cost estimating, cost budgeting, and cost control.

Project Quality Management The processes required to ensure the project will meet the requirements and needs for which it was approved. Quality Management consists of:

Quality planning Identifying the quality standards relevant to the project and determining how to satisfy them

Quality assurance Evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards

Quality control Monitoring specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance

Project Human Resource Management The processes required to make the most effective use of the people involved with the project, those who organize, and those who manage the project team. Management consists of organizational planning, obtaining staff, and team development.

Project Communications Management The processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information. It consists of communications planning, information distribution, performance reporting, and administrative closure of the project.

Project Risk Management The systematic process of identifying, analyzing, and responding to project risk to project objectives. It includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of adverse events. Activities include risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control.

Project Procurement Management The processes required for acquiring goods and services to attain project scope from outside the performing organization. It consists of procurement planning, solicitation planning, solicitation, source selection, contract administration, and contract closeout.

Project Procurement Management should serve the following purposes:

Provide an open, fair, and competitive process that minimizes opportunities for corruption and ensures the impartial selection of a contractor

Avoid potential and actual conflicts of interest or the appearance of a conflict of interest Establish an objective basis for contractor selection Obtain the best value in terms of price and quality Document the requirements that a contractor must meet to obtain payment Provide a basis for evaluating and overseeing the work of the contractor

7.3 Roles & Responsibilities 7.0 Project Management 353

Allow flexible arrangements for obtaining products and services given the particular circumstances, provided such arrangements do not violate the other purposes of Project Procurement Management

Project Stakeholder Management The processes required to identify all people or organizations impacted by the project (i.e., the stakeholders) and analyze their expectations. Additionally, this includes evaluating their impact on the project and developing appropriate management strategies for effectively engaging stakeholders in project decisions and execution. These processes include planning stakeholder management, managing stakeholder engagement, and controlling stakeholder engagement.

To supplement this chapter, IT project managers should refer to additional resources (see Section 7.7 Other Resources, on pg. 368), colleagues in other State agencies, and industry best practices.

7.3 Roles & Responsibilities

Project managers should have a defined formal structure for the project and for the project staff. This provides each individual with a clear understanding of their authority and responsibilities for successfully accomplishing project activities. Project team member accountability is essential for effective assignment performance and for achieving project goals and objectives. When team members participate in the planning process, they will have a sense of ownership and buy-in to the project management plan. This promotes responsibility and accountability for successfully completing the project. The roles and responsibilities of project participants will vary.

Determining and defining participant requirements should be done during the project management planning process.

On a large project, individual role assignments may require full-time support of the function On smaller projects, role assignments may be performed part-time, with staff sharing in the execution of multiple functions

Tasking and individual responsibilities are covered in section 1.8 Roles and Responsibilities, as activity assignments are defined in the planning process. Typically, these assignments are shorter term and exist only until the completion of the activity deliverable.

State agencies may choose to have FNS participat - a project executive steering committee. This provides an opportunity to obtain federal reaction to plans and challenges at the earliest stages, For more information on Procurement, refer to chapter 4.0 of this handbook.

7.3 Roles & Responsibilities 7.0 Project Management 354

and to obtain federal buy-in when necessary. FNS may also participate as technical advisors on the project throughout the SDLC and PMLC, or on an as needed basis.

A Responsibility Assignment Matrix is a common tool used in project management. It is also referred to as a Responsibility, Accountability, Consult, Inform (RACI) Chart (See Figure 53). The RACI Chart defines each should only fill one role per activity.

There are four possible roles that a stakeholder may be assigned:

1. Responsible the stakeholder must perform that activity

2. Accountable the stakeholder must make decisions regarding the activity, and be responsible for any consequences resulting from those decisions

3. Consult the stakeholder only provides input

4. Inform the stakehol

Figure 53: Example of a RACI Matrix

7.4 Project Management Plan 7.0 Project Management 355

7.4 Project Management Plan

A Project Management Plan is a formally approved document defining how a project is managed, executed, and rocedures, priorities, and responsibility for handling various situations. It establishes the baselines from which performance metrics are measured. The Project Management Plan is generated during the initiation phase of a project. Specific details may be missing at that time or circumstances may change. Because of this, the information within a Project Management Plan is

Project Management Plan must be approved by the Change Control Board (CCB) in accordance with the Change Management Plan section of the Project Management Plan. The CCB is a formally charted group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project. The RACI Matrix and the Communications Management Plan section of the Project Management Plan explain how changes are communicated.

A Project Management Plan is made up of the following components:

Change Management Plan Documents how change will be monitored and controlled to include managing the change control process involving the CCB

Configuration Management Plan Documents the functional and physical characteristics, how to control any changes to such characteristics, record and report the implementation status of the changes, and support auditing to verify conformance to requirements

Requirements Management Plan Describes how requirements will be analyzed, documented and managed

Scope Management Plan Describes how the scope will be defined, developed, monitored, controlled, and verified

Scope Baseline The approved version of the scope statement with a Work Breakdown Structure (WBS) that is used as the basis for comparison and can only be updated through the formal change control process

Schedule Management Plan Establishes the criteria and activities for developing, monitoring, and controlling the schedule

Schedule Baseline The approved version of the schedule that is used as the basis for comparison and can only be updated through the formal change control process

Cost Management Plan Describes how costs will be planned, structured, and controlled Cost Baseline The approved version of the budget that is used as the basis for comparison and can only be updated through the formal change control process Quality Management Plan Process Improvement Plan Describes how activities will be reviewed and analyzed so that efficiency improves as the project progresses

7.4 Project Management Plan 7.0 Project Management 356

Human Resource Management Plan Describes how the roles and responsibilities, reporting relationships, and staff management will be addressed and structured Communications Management Plan Describes how, when, and by whom information about the project will be administered and disseminated Risk Management Plan Describes how risk management activities will be structured and performed Procurement Management Plan Describes how a project team will acquire goods and services from outside the performing organization Stakeholder Management Plan Defines the processes, procedures, tools, and techniques to effectively engage the stakeholders in project decisions and execution based on the analysis of their needs, interests, and potential impact as well as defining who the stakeholders are

These components may contain additional sub-components that further support the plan depending on the complexity of the project and the chosen methodologies. The following subsections discuss some of the higher priority Project Management Plan components in more detail. However, this information is not exhaustive, and additional resources are outlined in section 7.7.

Requirements Management Plan

A Requirements Management Plan defines the methodology a PM intends to use to compile and evaluate requirements, maintain requirement documentation and tracking, and manage related activities. This plan

Traceability Matrix (RTM) is a common component of the Requirements Management Plan. An RTM tracks requirements from origination to implementation in the final result. It supports testing activities by linking requirements to specific tests for requirements. An RTM is also a useful tool in managing the scope of a project.

The RTM is useful not only throughout the life of the project, but after project completion it provides a history of the system from inception to decommissioning. This may prove helpful in the M&O phase to perform maintenance, define the scope and effect of enhancements, and serve as a functionality baseline when system replacement is considered.

7.4 Project Management Plan 7.0 Project Management 357

Communications Management Plan

Communication is widely considered the most important PM skill. Any factors or activities that may impact the quality and progress of work being performed must be communicated to the appropriate stakeholders. A PM must be proactive and thorough in distributing accurate information in a timely manner to the right audience.

The Communications Management Plan describes the communications process the PM will use for this purpose.

To ensure effective communications, a PM must develop a Communications Management Plan that establishes . A Communications Management Plan contains information regarding:

Who sends and receives communication What communication is sent How communication is sent (e.g., by telephone, in a meeting, by e-mail, etc.)

Figure 54: Example of a Requirements Traceability Matrix

7.4 Project Management Plan 7.0 Project Management 358

How often communication is updated What terms to include in a glossary

Who sends and receives communication is key to understanding and managing all the channels of communication.

The potential number of communication channels can be calculated by n(n-1)/2, where n is the number of stakeholders. Using this formula, a project with 10 stakeholders has 45 channels of communication.

This is not the same as the number of messages to be communicated or how often communications occur. Not defining who can communicate to whom could result in inadvertently leaving key personal out of conversations and/or distorting messages. The RACI Chart (see Figure 53, page 354) is a valuable tool to use in developing the Communications Management Plan.

What is communicated is key to ensuring that relevant information is being shared with the stakeholders who need it. Inundating communication channels with information that stakeholders find irrelevant will upset stakeholders and potentially cause them to ignore communications. As an example accountants do not need, nor

The medium used to send communication can determine the effectiveness of the information. This may include e-mail, phone calls, websites, in person, etc. Each medium has pros and cons which make them situationally appropriate, or more effective. Stakeholder preferences, location, and the importance of the message are key determining factors in selecting a communication medium.

Managing the frequency of communications should be based on how often messages need be updated.

Communicating too much may generate a false sense of urgency or create a sense of minutiae. In either case, too many communications may result in stakeholders devaluing communications. Not communicating enough is a far more common occurrence, and starves stakeholders of vital information.

Figure 55: Lines of Communication

7.4 Project Management Plan 7.0 Project Management 359

Communications require a glossary of terms to ensure everyone receives and understands the same message.

Misinterpretations because of differing terminology is common, especially in organizations where acronyms and jargon are prevalent. While it may seem tedious, defining common and not-so-common terms is the best way to mitigate communication issues.

Risk Management Plan

The risk management plan is where the PM defines the methodology used to identify risks and the methodology used to generate appropriate responses. The risk management plan may also contain sub-components such as a risk register (or log) and response plans. These sub-components individually identify risks, their impacts, and possible responses. Building a risk management plan requires doing risk analysis. When risks are identified, they need to be analyzed for the probability of occurring, the consequences if they occur, and reasons they might occur.

to scope, schedule and cost must be determined, rated for severity and prioritized for action.

Risks must have an appropriate response when they are identified and ranked. They may be mitigated, accepted, transferred, or avoided. The PM must continually look for new risks, reassess old ones, and re-evaluate risk response plans. The PM has to make sure the right people are still assigned to response actions and that the actions still make sense in the context of the latest project developments. Risk management should be reported as part of project status reports.

Figure 56: Risk Analysis Process

7.4 Project Management Plan 7.0 Project Management 360

Project integrity is achieved by adopting and practicing continuous project risk management. Disciplined risk management provides repeatable processes for delivering the quality required for business success. Past projects and lessons learned from other similar projects are good ways State agencies can identify risks.

7.4.3.1 General APD Project Risks

FNS SSO has observed the following risks as common to APD projects:

Poorly defined requirements Scope creep Lack of stakeholder management Political pressure Subcontractor management Inadequate planning Miscommunication Lack of focus Procurement process delays Failure to secure prior federal approval and funding Incremental or limited funding Inadequate State agency oversight and project management Turnover of key staff

7.4.3.2 Recurring APD Process Risks

FNS has identified several recurring issues specifically associated with the APD process that are risks State agencies should consider in their risk analysis and risk management planning. These issues may delay the APD process and ss, or failure to recognize these issues relevancy to a current effort until they are in the middle of a project.

Examples of recurring issues that add risk to a project include:

A lack of understanding that a partnership exists between the State agency and the federal government, which relies on good communication and collaboration

See appendix A13 Sample Status Report for a sample Risk Register in section A13.12 and for a sample Risk Response Document in section A13.13.

7.4 Project Management Plan 7.0 Project Management 361

Lack of familiarity with the dollar thresholds for APDs, RFPs, and contracts requiring FNS approval Lack of current technical knowledge and expertise within the State agency to write or review critical

APD documents, to include:

o Requests For Proposals (RFP) and contracts o system design and functional requirements

Over reliance on the contractor to prepare required APD documentation, which can render a State vulnerable to the cont

Mistaken perception that FNS can always absorb or compensate for cost overruns Incomplete cost allocation methodology that excludes State-participating federal programs

Insufficient understanding of the impact and resources involved for data conversion strategy and schedule Inadequate descriptions for system maintenance and operations methodology, costs, and assignment of responsibilities Inadequate time in the project schedule to assess the full impact on business processes, change business rules where necessary, and prepare staff for the transition Underestimation of the strain of new IS development on the entire organization Insufficient funding for user training and user support functions Not involving State IT and procurement staff throughout the project State program staff may be unaware of State standards, current procurements and contracts, and even conflicts with existing development efforts Not performing adequate testing (including the pilot) before and after implementation of a new system or major enhancement(s)

Project planning is the best time for recognizing these common issues among all State agencies. Preparing risk mitigation plans for a project will significantly reduce the risk of running out of time, or federal funds, prior to a

7.4.3.3 Common IS Project Risks

Some risks are common to all IS projects, regardless of the technologies or methodologies being utilized. Common difficulties related to project management are:

Giving the contractor too much control, responsibility, or authority, or both on behalf of the State agency (i.e., abdicating strategic decision making and fiscal responsibilities)

7.4 Project Management Plan 7.0 Project Management 362

after development is underway)

Placing a large focus on front-end/user interface modules while neglecting other critical elements of the system such as security, system capacity, notices, and reporting

Delaying or neglecting management reporting Staying abreast of all aspects of the project budget, not just the implementation contractor costs Not obtaining prior approval from all applicable federal agencies before the project starts Not obtaining prior approval of changes and updates that occur while the project progresses Not realizing that changes in cost, scope, and schedule, or procurement changes, must be submitted as an APD Update (APDU) and approved by FNS before new significant costs may be incurred (i.e., erroneously thinking retroactive approval can be sought)

7.4.3.4 Risk Management and the SDLC

Risk management is implemented to minimize negative impacts on an organization and provide a basis for sound decision making. Effective risk management must be totally integrated into the SDLC and the PMLC. While each phase of the SDLC and PMLC have different risks, the basics of risk management methodology are the same regardless of the phase. Risk management is a repetitive process that needs to be performed during each major phase of the SDLC and the PMLC. The risk management plan needs to be constantly re-evaluated. As each SDLC and PMLC phase proceeds, new circumstances will arise that may not have been foreseen during initial risk analysis. Furthermore, problems solved during the course of the project may introduce risks directly related to the solution. This will prompt the risk analysis re-assessment process. Table 39 describes the characteristics of each SDLC phase and indicates how risk management can be performed in support of each phase.

Table 39: Risk Management in Support of SDLC Phases

SDLC Phase Phase Characteristics Support from Risk Management Activities

Initiation The need for an IT system is determined and the purpose and scope of the IT system is documented.

Identified risks are used to support the development of the system requirements, including security requirements, and a security concept of operations (strategy). Data conversion is another high risk area for consideration at this stage.

Development

The IT system is designed, purchased, programmed, developed, or otherwise constructed. The system is tested and User Acceptance Testing is completed.

The risks identified during this phase can be used to support the security analyses of the IT system, which may lead to architecture and design tradeoffs during system development.

7.5 Monitoring and Control 7.0 Project Management 363

Table 39: Risk Management in Support of SDLC Phases

SDLC Phase Phase Characteristics Support from Risk Management Activities

Implementation

The system is piloted and rolled-out to the user community. The system security features should be configured, enabled, tested, and verified.

The risk management process supports the assessment of the system implementation against its requirements and within its modeled operational environment. Decisions regarding any risks identified must be made prior to system operation, including data conversion.

Maintenance & Operation

The system performs its functions.

Typically, the system is being modified on an ongoing basis through the addition of hardware and software and by changes to organizational processes, policies, and procedures.

Risk management activities are performed for periodic system reauthorization (or reaccreditation) or whatever major changes are made to the IT system in its operational, production environment (e.g. new system interfaces).

Disposal

This phase may involve the disposition of data, hardware, and software.

Activities may include moving, archiving, discarding, or destroying data and sanitizing the hardware and software.

Risk management activities are performed for system components that will be disposed of or replaced to ensure that the hardware and software are properly disposed of, that residual data is appropriately handled, and that system migration is conducted in a secure and systematic manner.

7.5 Monitoring and Control

State Agency Project Monitoring & Control

Monitoring and control of a project is the process of tracking, reviewing, and reporting project progress against performance objectives which were defined in the Project Management Plan. The State agency is primarily responsible for these activities, but FNS is involved to some extent as well. FNS expects State agencies to establish a plan for monitoring the development of State automation projects as a condition of project approval. Overall project monitoring includes specifically monitoring project procurements and formal acceptance of contracted

Refer to chapter 6.0 Test Planning for additional information on testing risks.

Refer to chapter 9.0 Systems Security for security related risk management.

7.5 Monitoring and Control 7.0 Project Management 364

services. The results of State agency monitoring are reported either in the APDU, or at critical junctures in project execution. FNS may require specific State monitoring activities to ensure appropriate project oversight. Likewise, FNS may participate in State agency monitoring activities or conduct additional review activities at its discretion.

Quality Assurance (QA) is a key activity of monitoring and control. It may be performed by a QA contractor or by qualified State agency staff. The QA contractor must not be the same as the project management contractor.

Likewise, the State QA staff should be independent from the project management or development staff.

Implementation QA includes independent monitoring of project status indicators such as schedules, accomplishments, deliverables, and costs. Implementation QA also incorporates formal reviews of development and implementation activities. These reviews are critical to the oversight of IS development projects.

State agencies should have detailed project schedules. They should establish and maintain frequent status reports to oversee their staff and contractors on the project level. They should submit status reports to FNS to ensure overall program administration. FNS may require the State agency to provide contractor and project status reports for informational purposes throughout the project. These may be outlined as conditions for funding approval.

The results of State agency monitoring may be reported in routine status reports in addition to APDUs. For management to make informed and timely decisions regarding work efforts, status reports should reasonably reflect current project performance.

Contractors are often required to provide monthly reports to the State agency (in accordance with the contract).

These reports are a significant source of much of the information needed to keep FNS informed of the project status. In some cases, contractor reports can be forwarded directly to FNS with no additional work. If contractor reports are incomplete, the State agency must supplement contractor information in the status report. It is

Status reports need not be lengthy to be informative and meet FNS expectations. Thorough status reports make annual APDUs easier to compile. Project

Reviews should be conducted periodically throughout the PMLC to gauge project progress and status.

See the Sample Status Report in appendix A13.

7.5 Monitoring and Control 7.0 Project Management 365

changes that exceed program thresholds must be approved in advance by FNS through the submission of an APDU As-Needed.

When submitting status reports to FNS, State agencies should include the following information:

The time period covered by the report Narrative description of current project status Description of activities that took place in the reporting period o Explain if activities were added or omitted from those in the approved APD o Areas where activities did not correspond to the project work plan Significant accomplishments Major deliverables received/approved Areas where the project is behind, why, and what steps are being taken to make up time or adjust the remaining schedule Status of previously identified problems or concerns Newly identified problems or concerns o A contractor and the State may have a different idea of what constitutes a concern o In addition to the reports, consult FNS for guidance in resolving problems

Project staffing changes Budget that shows any known or expected variations from the approved APD budget in a way that FNS can see what has changed o Previous quarters should show actual costs o Future quarters should show budgeted costs A thorough narrative of For future quarters, review all estimated costs to the budget o Show changes for all line items you anticipate will change and explain why

The most common reason would be for delays, when a cost is moved to a future quarter Contractor bills and payments made

FNS Project Monitoring

FNS will perform its own monitoring in addition to the activities performed by the State agency. FNS will monitor State agency projects using a variety of methods such as reviewing documents and reports, and participating in conference calls and virtual demonstrations. FNS reserves the right to conduct on-site monitoring through project status visits; local or state agency reviews, or both; participating in user training; and participating in User Acceptance Testing (UAT).

7.6 Project Closure 7.0 Project Management 366

FNS may elect to conduct a System Functional Requirements Review after the system has passed UAT, before the pilot, or before the deployment of software. FNS may decide to do all of these. Please note that this does not have to be an on-site review. The review may be conducted by reviewing UAT or Pilot Evaluation documentation, or both, provided by the State agency.

Reasons for doing this include:

Evaluating system performance and accuracy Looking for indicators of successful development Verifying that functional requirements were met Ensuring that all policy to be administered through the system is accurate Analyzing the integrity of data capture, edits, and calculations Verifying that UAT was thorough and successfully completed Ensuring the system interfaces successfully with other program IS and external entities, including EBT Reviewing the project FRD to ensure it meets all State and federal requirements

7.6 Project Closure

The purpose of project closeout is primarily to bring closure performance, updating the skills inventory, capturing key project metrics, and filing all pertinent project materials into the project repository. This includes documenting final actual project expenditures, closing open contracts, and finalizing project records. All finalized project documents should be archived for future reference for other projects.

At this point the project is within the closing phase of the PMLC and the responsibilities of the project manager are to:

Assess how closely the project met customer needs Highlight what worked well Learn from mistakes made during the project Identify patterns and trends Derive ways to improve on processes executed throughout the project Communicate results to all stakeholders

Please see chapter 6.0 Test Planning for more information about testing requirements.

7.6 Project Closure 7.0 Project Management 367

There are many activities executed throughout the life of a project that require documentation during closeout.

These activities may include:

Managing project scope Managing the Managing the budget will result in a final budget in the form of an actual expenditures report Monitoring and controlling risks that have been recorded in an updated risk management worksheet Managing change control and deliverable acceptance Documenting organizational changes in final approval forms Issuing logs and status reports

Project closure may include a post-implementation review, preferably six months after implementation and roll-out are completed. The purpose of conducting a post-implementation review is to gather the information required to meet IAPD process responsibilities. The review may be conducted by the State agency as a deliverable, by FNS, or a combination. This review is a time to assess the project and derive any lessons learned and best practices to be applied to future projects. The post-implementation report may be used for an internal State ent imposed by FNS prior to the The information is sent to FNS in a post-implementation report. Many State agencies may have a formal post-implementation review process in place. Others may use a less formal method that achieves the same results.

The review has three main tasks:

Solicit feedback Conduct project assessment Prepare post-implementation report

The review may start with a survey designed to solicit feedback from the project team, end users, and other stakeholders. The PM should gather feedback using a survey appropriate to the project. Depending on the size and type of the project, and the structure of the responsible State agency, different surveys may be required for different stakeholder groups. At a minimum, feedback should be solicited from the project sponsor (this may be the director or CIO), project team members, and end users. Once feedback has been collected and evaluated, an assessment meeting may be conducted to derive best practices and formulate lessons learned to inform future efforts. The PM should gain consensus on what was successful and what was not and derive best practices and lessons learned. These should be documented both for the individual State agency, as well as for the benefit of other State agencies. Ideally, the best practices and lessons learned should be stored in a centralized organizational repository, facilitating access and retrieval by managers of future projects. The PM may conduct the project assessment by meeting with select members of the project team and stakeholders to present the

7.7 Other Resources 7.0 Project Management 368

summarized results. Other topics of discussion should include results of the feedback surveys and other aspects of the completed project.

After the project assessment, the PM prepares a post-implementation report, which is a distillation of the information gleaned from the assessment that is organized, according to feedback categories, and has added information on key project metrics. Topics to include in the report are an assessment on the effectiveness of project management, risk management, communications, change management, issues management, implementation and transition, and performance of the project team. The PM must present or distribute the post-implementation report to members of the responsible organization and should share it with FNS.

7.7 Other Resources

For additional information on project management, consult any of the resources listed in Table 40 and Table 41.

Table 40: Internet Project Management Resources FNS http://www.fns.usda.gov/

Project Management Institute (PMI®) http://www.pmi.org

New York State Project Management Guidebook Release 2 https://its.ny.gov/nys-project-management-guidebook-release-2

North Dakota Information Technology Department, Project Management http://www.nd.gov/itd

North Dakota Project Management Guidebooks and Templates https://www.nd.gov/itd/services/project-management/customized-project-management-tools-and-templates

NIST Information Systems Guide Conducting Risk Assessments http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80 0-30r1.pdf

A critical reason for the post-implementation review is to ensure that the system is reviewed and evaluated before the warranty period expires. States often tend to relax after implementation and forget that they have a limited time to identify any problems or shortcomings with the system and get them fixed during the warranty period.

See chapter 3.0 The Advance Planning Document Process for more details.

7.8 Project Management

Summary

7.0 Project Management 369

Table 41: Literary Project Management Resources A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute

Lientz, Bennet P. and Kathryn P. Rea, Project Management for the 21st Century, (Academic Press, 2002).

Kerzner, Harold, Project Management: A Systems Approach to Planning, Scheduling, and Controlling, (Wiley, 2006).

7.8 Project Management Summary

For purposes of the APD proce a set of information technology related tasks, undertaken by a State agency to improve the efficiency, economy, and effectiveness of administration and/or operation of its human services programs.

Project managers should have a defined formal structure for the project and project staff o Project team members should have a clear understanding of their authority and responsibilities for successfully accomplishing project activities o See 1.8 Roles and Responsibilities

A Project Management Plan defines how a project is managed, executed, and controlled. It contains these core components:

o Change Management Plan o Scope Baseline and Management Plan o Schedule Baseline and Management Plan o Cost Baseline and Management Plan o Quality Management Plan o Communications Management Plan o Risk Management Plan o Procurement Management Plan o Stakeholder Management Plan

Governance of the project is based largely on Project Management Plan components and those directly responsible for them

Managing the project is part of the Monitoring and Control functions of the project Management Lifecycle o Common tools used for managing the project include the Scope, Cost, and Schedule Baselines, Quality Assurance (QA), and the annual APD Updates (APDU)

7.0 Project Management 370

o Documents final, actual project expenditures; closes completed contracts; and finalizes project materiel o May include a post-implementation review, preferably six months after implementation and roll-out are completed

8.0 Financial Management 371

8.0 Financial Management

Key Points

The information in this section should allow you to understand the following:

What federal Regulations and guidelines govern the financial management of IS projects?

How are allowable costs determined and allocated in a budget?

What financial information must be submitted with the APD to obtain FFP approval?

What are the guidelines for Cost Allocation when planning, implementing and maintaining an IS?

What reporting guidelines and forms are mandatory for the State agencies to use when reporting costs?

Chapter Contents

8.1 APD Financial Preparations

General APD Funding Requests

Regulatory Guidance

Administrative Requirements

8.2 Allocable Costs

Necessary and Reasonable Costs

Direct and Indirect Costs

Allowable Costs

Unallowable Costs

Processing Cost Disallowances

Developmental Versus Operational Costs

8.3 Common Cost Items for IT Systems Projects

Compensation for Personnel Services (Staff Costs)

Outside Contractor Professional Services

Internal/State IT Professional Services

8.0 Financial Management 372

Documentation/Materials

Telecommunications

Equipment and Other Capital Expenditures

8.4 Waivers of Depreciation

Software Costs

Hardware Costs

Site Preparation Costs

Interest

8.5 Cost Allocation

Division of Cost Allocation Services (CAS)

Cost Allocation Stakeholders

Cost Allocation Plan

Cost Allocation Methodologies

Indirect Cost Proposals

8.6 Cost Reviews and Audits

Office of Management and Budget (OMB) Responsibilities

Food and Nutrition Service (FNS) Review

General Budget Estimates

Operational Budget Estimating

Completing the Planning Advanced Planning Document Budget

Completing the Implementation Advance Planning Document Budget

Completing an APDU Budget

8.7 Expenditure Reporting

Revised Project Cost Estimate

Actual Costs to Date

Program and Budget Summary for SNAP APDs

8.0 Financial Management 373

WIC Developmental Costs

WIC- State Agency Management Information System Annual Cost Survey

Annual APDU Expenditure Reporting

Regional Office Expenditure Review

8.8 Other Resources

8.9 Summary

Chapter Acronyms ADP Automated Data Processing

CAP Cost Allocation Plan

CFR Code of Federal Regulations

EAR Emergency Acquisition Request

EBT Electronic Benefit Transfer

FFP Federal financial participation

FFR Federal Financial Report (Form FS-425)

IS Information System or Systems

M&O Maintenance and Operations

MIS Management Information Systems

NSA Nutrition Services & Administration

OMB Office of Management and Budget

RO Regional Office

SAE State Administrative Expense

SAM State Agency Model

SDLC System Development Lifecycle

SSO State Systems Office

8.1 APD Financial Preparations 8.0 Financial Management 374

8.1 APD Financial Preparations

One of the major purposes for submitting an Advance Planning Document (APD) is to secure federal funding for systems planning and/or development of eligibility and issuance systems. Sound financial planning and cost determination activities are essential for preparing the APD. Costs must be determined, allocated, and identified to support the APD submission. They are also integral for establishing APD activities based on expected funding thresholds. (See section 1.5.1 Thresholds for applicable APD funding thresholds.)

General APD Funding Requests

Guidance for acquiring information systems through the APD process can be found in 7 CFR 277.18.54 This regulatory section establishes conditions for requesting Federal financial participation (FFP) funds and the related documentation for IS Purchases.

State agencies must follow the APD process to obtain FNS approval before they initiate activities to:

Plan for procuring the IS Procure the IS Implement the IS Perform Maintenance and Operations (M&O) on the IS

Most costs associated with new or upgraded IS are not considered administrative and must be approved beforehand through the use of an Advance Planning Document. Without prior approval, State agencies are at risk for not being reimbursed. Therefore, State agencies must follow the APD process to obtain FNS approval before they initiate activities. See chapter 3.0 The APD Process for a detailed look at the APD process.

For definitions of terms used in this handbook, please see appendix A1 Acronyms and Glossary of Terms.

8.1 APD Financial Preparations 8.0 Financial Management 375

Preparing and reviewing APDs encompasses not only programmatic and technical considerations, but also a host of financial management concerns. These include:

Assigning costs to the correct costing categories Determining costs allowable under federal regulations Assessing equipment and handling depreciation Allocating those costs to the correct program Preparing IS project budgets Reporting, reviewing, and reimbursing subsequent costs

Funding acquired through the APD process is available for activities such as procuring contractors for planning, development, and M&O eligibility/issuance information system. Financial resources are available for these activities if the IS project meets FNS program objectives and requirements for eligibility and issuance system funding. For example, the APD process is not used for telephony systems or payroll systems that aren t used directly as part of the development of an eligibility/issuance system. The approval of funding not directly related to an eligibility/issuance system development is accomplished trative funding.

This chapter covers topics related to the financial management of IS projects supporting SNAP and WIC. Because many practices are governed by program-specific regulations, there is a close relationship between financial management requirements and the entire APD process. Therefore, a State agency must be familiar with the program-specific IS requirements as a basis for understanding and using the financial management information presented in this chapter. It is important to understand the prior-approval thresholds, funding sources, and reimbursement rates for each program when applying the financial management guidance in this chapter.

Regulatory Guidance

The Code of Federal Regulations concerning Grants and Agreements should be used as a base reference during the APD process, especially in regard to the Department of Agriculture.55 The information in 2 CFR Subtitle A -- OMB Guidance for Grants and Agreements and Subtitle B FAR for Grants and Agreements56 applies to organizations that receive federal funds. This may be either directly from the federal government or passed through to an entity such as a local government, nonprofit organization, or educational institution. State agencies also need to follow the financial management requirements for SNAP (7 CFR 277.1 through 285.5)57 and WIC (7 CFR 246.1 through 246.28).58

For more information on the relationship between the APD process and Financial Management, see chapters 1.0 and 2.0.

8.1 APD Financial Preparations 8.0 Financial Management 376

The factors affecting the allowability of State agency IS project costs under federal Awards are included in sections 2 CFR 200.403 (a) through (g).59 This regulatory section covers the allowable cost determination, but does not identify specific circumstances or dictate the extent of federal or government unit financial participation of a particular program or project.

Table 42 lists Regulations and Policies to assist State Agencies with preparing an APD and assigning correct funding and cost areas.

Table 42: Regulations and Policy Governing Financial Management

Authority Topic - Purpose

2 CFR 200.0 to 200.52160 Title 2 Subtitle A Chapter II Office of Management and Budget Guidance Part 200 Uniform Administrative Requirements, Cost Principles, and Audit Requirements for Federal Awards

2 CFR 200.400 61 Title 2 Subtitle A Chapter II Office of Management and Budget Guidance Subpart E Policy Guide

7 CFR 277.1 to 277.1862 Title 7 Subtitle B Chapter II Subchapter C Part 277 Payments of Certain Administrative Costs of State Agencies

7 CFR 277 Appendix A63 Title 7 Subtitle B Chapter II Subchapter C Part 277 Appendix A Principles for Determining Costs Applicable to Administration of the Food Stamp Program by State Agencies

7 CFR 246.1 to 246.2864 Title 7 Subtitle B Chapter II Subchapter A Part 246 Special Supplemental Nutrition Program For Women, Infants And Children

7 CFR 271.1 to 285.565 Title 7 Subtitle B Chapter II Subchapter C Part 271-285 Food Stamp and Food Distribution Program

Costs must meet general criteria in order to be allowable under materiel awards.

- 2 CFR 200.403

8.2 Allocable Costs 8.0 Financial Management 377

Administrative Requirements

The federal awarding agency must manage and administer the federal award so that funding is expended and associated programs are implemented in full accordance with U.S. statutory and public policy requirements as stated in 2 CFR 200.300(a).