Attachment E - VA VIP_Guide_3_2.pdf

w

VETERAN -

FOCUSED

INTEGRATION

PROCESS

GUIDE 3.2

December 2018

Veteran-focused Integration Process Guide 3.2 i https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

This page intentionally left blank https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx ii https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

Executive Summary and Approval The Veteran-focused Integration Process (VIP), a Lean-Agile framework, services the interest of Veterans through the efficient streamlining of Information Technology (IT) activities that occur within the IT enterprise.

VIP is a significant step forward for the Department of Veterans Affairs (VA), allowing more frequent delivery of essential IT services, via a no longer than three-month cadence, and minimal oversight processes. VIP also enhances the ability to track and monitor IT performance and strengthens management oversight and accountability.

Any VA IT project effort managed by the Enterprise Program Management Office (EPMO) that touches the VA network must utilize VIP, regardless of whether it spends government funding from VA’s Congressional IT Appropriation or any other appropriation.

This guide provides direction, procedures, and processes that staff must follow for successful IT project management within VA. The guide serves as a reference of VIP policies, definitions and procedural regulations for VA and the Office of Information and Technology (OIT) community. If there is a conflict with previously issued VA or OIT guidance or publications, the current version of the VIP Guide takes precedence.

As VA continually strives to improve project management effectiveness and efficiency, VA appreciates any insight that users can provide. Users should send their comments and suggestions for improvements of the VIP Guide to the VIP Business Office (vavip@va.gov) for review and consideration.

Approval for the Veteran-focused Integration Process (VIP) Guide 3.2:

Approved by:

Mr. John Everett / Date

Acting Associate Deputy Assistant Secretary (ADAS)

Enterprise Program Management Office (EPMO) mailto:vavip@va.gov iii

Record of Changes

Version Date Comments

1.0 12/31/2015 Initial Release

2.0 05/22/2017 Update to revise policy and responsibilities associated with VIP

3.0 12/27/2017 Update to revise policy and responsibilities associated with VIP

3.1 04/04/2018 Update to revise policy and responsibilities associated with VIP

3.2 12/13/2018 Update to revise policy associated with VIP

1. REASON FOR ISSUE. To revise Department of Veterans Affairs (VA) policy issued April 4, 2018.

1.1 SUMMARY OF CONTENTS/MAJOR CHANGES. This guide sets forth revised policies and responsibilities for managing VA Information and Technology (IT) projects under VIP. The changes include:

• Added a maximum six (6) month planned length to the Project Phase (Section 2.3)

• Removed 18-month time limit for the Product Phase (Section 2.4)

• Added a requirement to enter a release into the VIP Dashboard during the Product Phase

(Section 2.4.4)

• Added a requirement to have a release to IOC or production every 3 months (Section 2.4.4)

• Added a maximum four (4) month planned length to the Close Out Phase (Section 2.6)

• Added clarity on when the project ends (Section 2.6)

• Updated reference to VA approved tools (Section 3.2)

• Removed Appendix C (List of Contacts/Links)

2. RESPONSIBLE OFFICE. VIP Business Office (VBO)

RECISSION

Veteran-focused Integration Process Guide v.3.1, dated April 4, 2018, is rescinded.

iv https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

Table of Contents Executive Summary and Approval ........................................................................................................ ii

Record of Changes .............................................................................................................................. iii

1 Overview

1.1 Purpose

1.2 Projects That Will Employ VIP

1.3 Principles

1.3.1 Prioritize the Needs of Veterans and Users

1.3.2 Test Early and Often

1.3.3 Welcome Change Throughout the Project Lifecycle

1.3.4 Work Closely with all Stakeholders

1.3.5 Measure Progress by Delivery

1.3.6 Value Simplicity

1.4 Priorities

1.4.1 Security

1.4.2 User Satisfaction

1.4.3 Portfolio Approach

1.4.4 Accountability and Transparency

1.4.5 Continuous Improvement

1.5 VIP Roles and Responsibilities

1.5.1 Product Owner

1.5.2 IT Account Manager

1.5.3 VIP Triad

1.5.4 IT Portfolio Director

1.5.5 Receiving Organization

1.5.6 Project Manager

1.5.7 Program Manager

1.5.8 Scrum Master

1.5.9 EPMO VIP Business Office

1.5.10 OIT Governance Boards

1.5.11 IT Operations and Services Implementation Manager

1.5.12 Release Agent

1.5.13 Health Product Support (HPS) Application Coordinator (AC)

1.5.14 Strategic Technology Alignment Team

1.6 Flexibility of Project Requirements

2 VIP Lifecycle

2.1 VA IT Process (VIPR) Intake

2.2 Initiation Phase

2.3 Project Phase

2.3.1 Project Planning

2.3.2 Critical Decision 1

2.3.3 Contract Award and On-Boarding

2.4 Product Phase

2.4.1 Product Phase Start and Build Start

2.4.2 Build and Development

2.4.3 Critical Decision 2

v https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

2.4.4 Release Preparation and Release

2.5 Paused Status

2.5.1 Project Tasks

2.5.2 Required Reporting

2.5.3 Required Reviews

2.6 Product Transition and Project Close Out

3 VIP Reporting and Tools

3.1 VIP Dashboard and External Reporting Requirements

3.2 VA Approved Tools

3.3 VA IT Process Request (VIPR)

3.4 POLARIS Enterprise Release Calendar

3.5 Oracle Primavera P6 Team Member, Timesheets

4 Managing a Project with VIP

4.1 Agile Implementation

4.2 Required Artifacts

4.2.1 Critical Decision 1

4.2.2 Critical Decision 2

4.3 VIP Governance Process

4.4 VIP Issue Escalation Process

4.5 Leveraging Lessons Learned from VIP/Technical Review (TechRev)

Appendix A Agile Terminology

Appendix B Types of Projects that Will Employ VIP B.1 Infrastructure B.2 Sustainment B.3 Inter-Agency Agreements (IAA) B.4 No Production Release “Projects”

List of Figures Figure 1: The VIP Lifecycle Figure 2: VIP Lifecycle – Intake Figure 3: VIP Lifecycle – Initiation Figure 4: Relationship of Epics to Solution(s) Figure 5: VIP Lifecycle – Project Planning Figure 6: VIP Lifecycle – Critical Decision 1 Figure 7: VIP Lifecycle – Contract Award and Onboarding Figure 8: VIP Lifecycle – Product Phase Start and Build Start Figure 9: Build Development Cycle Figure 10: VIP Lifecycle – Critical Decision 2 Figure 11: VIP Lifecycle – Release Preparation and Release Figure 12: VIP Lifecycle – Product Transition and Project Close Out Figure 13: VIP Lifecycle – Scrum Lifecycle Figure 14: VIP Escalation Hierarchy vi

Additional Resources:

The VBO SharePoint site has links to additional resources, including websites and email addresses:

https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Homepage.aspx https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Homepage.aspx https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

1 Overview

On December 31, 2015, the Office of Information and Technology (OIT) implemented a new Information Technology (IT) delivery and governance framework that encompasses the portfolio/program/project levels.

The Veteran-focused Integration Process (VIP), a Lean-Agile framework, services the interest of Veterans through the efficient streamlining of activities occurring within the IT enterprise. This effort prioritizes increasing value to the Veteran, information security, portfolio management, and continuous organizational learning and improvement within the VA.

VIP is a significant step forward for VA, allowing more frequent delivery of essential IT services benefitting the Veteran by reducing and optimizing the oversight process. VIP also enhances the ability to track and monitor IT performance and strengthens management oversight and accountability. VIP incorporates portfolio-centered strategic planning, Agile development methodology, a three-month cadence, two Critical Decisions, and a single integration release cycle.

VIP propels the Department with even more rigor toward Veteran-focused delivery and sustainment of IT capabilities and infrastructure projects. The VIP framework unifies and streamlines IT delivery oversight, and enables efficient delivery of secure and predictable IT solutions. With VIP, VA takes another generational leap forward in its commitment to serve our nation’s Veterans.

V represents Veteran-focused. This policy prioritizes Veteran needs and it empowers employees to deliver excellent customer service for improvement of the Veteran experience. From an IT perspective, this means VA will focus project efforts on Veteran outcomes, rather than complex processes and documentation. OIT will focus on building value for the Veteran, through easier access to integrated health care, benefits, and other services.

I represents a single Integration release process. OIT eliminated the numerous independent groups, staffed by more than 90 individuals, with over 10 processes to conduct reviews and assessments in the latter stage of the Product Phase. With VIP, compliance organizations are engaged early to provide input during planning to ensure successful and faster delivery. Compliance organizations are monitoring progress and the implementation of the requirements during the entire development cycle, rather than just at the end.

P represents Process which includes Portfolios, Programs and Projects. Portfolios, Programs, and Projects facilitate the integration of information-sharing, partner and stakeholder communication required for a successful IT management program. VIP reoriented its organizational structure to allow OIT to better divide responsibility and streamline the oversight process.

This guide serves as a reference of VIP policies, definitions, and procedural regulations for VA and OIT community.

1.1 Purpose

The primary goal of VIP is:

To increase the speed of delivering high-quality, secure, and sustainable IT capabilities to benefit the Veteran.

To achieve this goal, VIP enables a flexible project management process that allows VA to deliver https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018) usable and beneficial products centered on the needs of users through frequent releases. By increasing the frequency of releases, decreasing the requirements for large amounts of documentation and oversight, and focusing on the continued sustainment and operation of deployed systems, VIP helps to succeed in meeting this objective.

1.2 Projects That Will Employ VIP

The VIP Framework is mandated for any project effort managed by the Enterprise Program Management Office (EPMO) that touches the VA network, regardless of whether it spends government funds from VA’s Congressional IT Appropriation or from another appropriation. This mandate includes projects that complete a Critical Decision 1 (CD1), but are not required to complete a Critical Decision 2 (CD2) because of non-deployment into production. Projects that complete a CD1 and not a CD2 need the Project Manager (PM) and/or Contracting Officer Representative to verify completion of met requirements prior to closing the project.

However, there are conditions that apply in different circumstances. Because one size does not fit all and different products have different needs, VIP strives to appropriately tailor the requirements to the product.

To the maximum extent possible, all spending of government funds on IT must employ both VIP and Agile processes. This will vary based on the type of product, which is why Portfolio Directors can modify VIP processes for specific products. When pursuing new products, OIT strives to buy existing products before building a new product, and prefers cloud solutions. Even if a product is not a standard software development project, it must still follow VIP and Agile best practices. Several examples are provided in Appendix B. If there is any uncertainty about whether a project must follow VIP, contact the VBO at vavip@va.gov for guidance.

1.3 Principles

VIP aligns itself with the following six core principles:

1.3.1 Prioritize the Needs of Veterans and Users

By keeping the priorities of Veterans and users at the forefront of policy, VIP ensures an outcome that meets their needs. The needs of users drive decision-making—not the needs of the VA, nor the personal preferences of leadership.

1.3.2 Test Early and Often

With VIP, VA wants to deliver a secure and reliable product to users early and often. Testing throughout the IT project lifecycle with the intended user of the product is the best way to ensure the outcome will be usable and provide the user-requested functionality. Stakeholders will have opinions and ideas about how a product should look or work; and these will be considered. However, VA will rely on direct feedback from end-users, coupled with the IT development knowledge of seasoned IT Subject Matter Experts to confirm that the most appropriate technological solution is being used to meet the Product Owner’s business requirements.

1.3.3 Welcome Change Throughout the Project Lifecycle

Additional requirements that are discovered through development and testing are prioritized by the Project Team and Product Owner in the backlog. By utilizing Agile methodology, OIT fosters an environment that is both adaptable and reflective.

https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

1.3.4 Work Closely with all Stakeholders

Success requires close collaboration across the team—from the IT Project Team to the Release Agent to the Product Owner to the team responsible for sustaining and hosting the product. We communicate early and often to make transparent decisions. Agile development methodologies require development teams to meet often with Stakeholders to elaborate and prioritize requirements, ensure transparency, and foster a collaborative work environment.

1.3.5 Measure Progress by Delivery

OIT’s Project Teams deliver solution(s) that meets the needs of the end-users as the principal measure of progress. A frequent delivery cadence means that end-users should experience tangible improvements regularly. Documents do not equate to progress; progress is a working product or service.

1.3.6 Value Simplicity

VIP does not create documentation for the sake of documentation, nor does it create complex processes when a simple one will suffice. This policy values trust and works in a principles-based manner, not a rules-based hierarchy. OIT will not answer the same questions multiple times in different formats. To work in an Agile manner, this governance process must have clear and simple processes that avoid redundancy.

1.4 Priorities

In accordance with the principles listed above, VIP is committed to the following institutional priorities:

1.4.1 Security

The priority of OIT is the safety and security of Veteran data. Security is not just a check-point or a document; it is embedded in the process by the Project Team. Security requirements are identified at the start of the project, addressed throughout development, then confirmed and tested before the product is placed into production.

1.4.2 User Satisfaction

An IT project is not successful unless it meets the needs of the end-user. Throughout the VIP Lifecycle of each project, the Product Owner, representing product users, will have a key role in the decision-making process during the development of the product. As one of the three decision-makers for Critical Decisions, the Product Owner will be able to regularly express concerns and/or approvals to best meet user satisfaction.

1.4.3 Portfolio Approach

By transitioning from a project-based to a portfolio-based structure, VIP enables projects and their Project Teams to operate within a common framework. Grouping similar projects into portfolios ensures more effective management of resources and allow for a portfolio-level focus on tasks like release processes and risk management. This structure also enables more sharing of effective trends and successful patterns.

1.4.4 Accountability and Transparency

VIP enhances accountability and measures performance through data-driven metrics and simplified approval processes. Data is made available at the portfolio/program/project levels.

With the utilization of three key decision-makers in the VIP Lifecycle, data will be more fluidly communicated and foster an environment of transparency.

https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

1.4.5 Continuous Improvement

VA is committed to continuous learning and evaluations. VIP allows VA to gather lessons learned by taking an analytical view at both successes and failures and then sharing these opportunities for improvement with the enterprise. In addition, OIT will reevaluate its governance and IT management processes continuously to ensure they stay lean.

1.5 VIP Roles and Responsibilities

Successful outcomes require an effective Project Team, aware of roles and responsibilities, with a clear understanding of the objective and scope of the project, and the needs of all users and Stakeholders. While roles and responsibilities may vary from project to project, the following key roles are included in VIP (although not every role is required for every project):

1.5.1 Product Owner

The Product Owner is an individual in the business office within VA that sponsors the “solution” by expressing the requirement for the product. The Product Owner is the organization’s representative of the individuals who will be served by the product. The Product Owner drives the business requirements (Epics, sub-Epics, and User Stories). The Product Owner, along with the PM, is responsible for prioritizing the project backlog in activities such as Sprint Planning. The Product Owner is one of the three decision-makers (VIP Triad) for CD1s and CD2s.

The Product Owner or Designee:

• Provides business requirements

• Defines project goals, scope, Epics, sub-Epics, user stories, roles, and priorities

• Serves as part of the Scrum Team and makes day-to-day decisions on behalf of their business office

• Prioritizes the backlog

• Approves/accepts the product

A successful and effective Product Owner will have daily contact with the Project Team, invest in understanding the needs of their users, and trust that the information provided by the Project Team with respect to operations is reliable, but verify that information is accurate. The Product Owner will be a partner to the Project Team and participate as an active member of the Scrum Team. As such, the Product Owner prioritizes the needs of their users above all, and makes decisions on behalf of the business office represented. The Product Owner will also be engaged in the Project Close Out Phase actions and participate in the transition to the Receiving Organization and Sustainment Phase of the Product Lifecycle.

1.5.2 IT Account Manager

The IT Account Manager (ITAM) collaborates with the Business Stakeholders to understand the business needs and requirements. The ITAM is responsible for coordinating with the Product Owner to create new VA IT Process Requests (VIPR) and for submitting them for portfolio-level review. The ITAM also works with the Portfolio Director to triage the requests and further define the requirements. ITAMs are responsible for arranging and brokering the meetings between alignment groups and the business to select the appropriate Alignment Epics for the product.

An ITAM serves as the lead IT executive reporting to the CIO and is responsible for the creation and management of the business partner’s portfolio. An ITAM provides strategic leadership to maximize value by managing IT product prioritization, balancing portfolios, and allocating resources. He or she https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018) is the primary contact between IT and the business partner, interfaces with industry, and serves as a catalyst to drive innovation. ITAMs collect data about OIT performance throughout all VA. This information facilitates OIT issue resolution, change management, and enterprise innovation.

1.5.3 VIP Triad

The VIP Triad consists of the Portfolio Director, the Product Owner and the Receiving Organization Representative. The VIP Triad is the decision group for CD1s and CD2s. The VIP Triad is also the decision group for VIP Triad Technical Reviews (TechRevs) where they have direct oversight of the project.

NOTE: The VIP Triad consists of members that have direct oversight of the project/product and can make real-time informative decisions in support of the project lifecycle.

1.5.4 IT Portfolio Director

The IT Portfolio Director oversees a larger grouping of similar projects organized into programs. A successful IT Portfolio Director creates and manages the framework in which their programs operate, ensuring an environment that positions the programs for success; and ensures the needs of the user and Veteran are addressed. This individual must have a close working relationship with their Program Managers, advocating for them within the larger VIP and OIT context.

The IT Portfolio Director ensures the use of Agile methodologies, comprehends the needs of the Product Owner and other Stakeholders, and addresses the needs of the VA. The IT Portfolio Director strives to meet VIP and other VA compliance measures, and is one of the three decision-makers (VIP Triad) for CD1s and CD2s. The VIP SharePoint site offers guidelines that assist the IT Portfolio Director in assessing a product’s risk and visibility, to determine what level of VIP guidance a project should follow. If an IT Portfolio Director is not able to attend a CD, they have the authorization, via a duly signed Delegation of Authority (DOA) memo, to designate a Voting Proxy in their place. In addition, the IT Portfolio Director will serve as the lead contact/POC for the development lifecycle of all projects, programs, and systems within the portfolio. Part of that effort ensures the completion of sustainment operations and maintenance cost elements including technical debt.

1.5.5 Receiving Organization

The office responsible for performing or coordinating with the hosting organization on day-to-day system operational and administrative tasks related to a system is the Receiving Organization. The Receiving Organization identifies a Sustainment Manager to oversee Receiving Organization responsibilities. Enterprise Program Management Office (EPMO) Transition, Release, and Support (TRS) is the primary Receiving Organization for sustainment of IT projects. Hosting may occur internally with IT Operations and Services (ITOPS) or externally with a vendor (e.g. Cloud). While TRS generally serves as the Receiving Organization, exceptions may be made when projects are deemed “infrastructure only” and will be entirely supported by ITOPS or, a special exception exists. The Receiving Organization Representative, known as the Sustainment Manager, is one of the three decision-makers (VIP Triad) for CD1s and CD2s. In addition, the Receiving Organization is engaged in the Project Close-Out Phase actions as part of the transition process to the Sustainment Phase of the Product Lifecycle. Involvement of the Receiving Organization early in the project lifecycle allows the organization to anticipate impacts to future product sustainment resources.

1.5.6 Project Manager

The Project Team designs, develops, and delivers the product. An OIT Project Manager (PM) leads the team, and is responsible for delivering a secure and usable product on time, on budget and in scope to the Product Owner (Section 1.5.1). The PM keeps the project on track, manages project https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018) goals and scope, tracks reporting requirements, and ensures delivery. Assembly of this team can occur from portfolio resources, other VA resources or resources acquired via a contract award.

The PM ensures:

• The VIP Dashboard must be updated within three business days

• Entries for Initial Operating Capability (IOC) Production, with the IOC Entry and IOC Exit dates, are added to the Planning and On-Line Activity/Release Integration Scheduler (POLARIS) calendar

• New systems are registered in the VA Systems Inventory (VASI) per Directive 6404

1.5.7 Program Manager

Programs are a limited collection of similar projects, delivering comparable work, generally addressing related applications or requirements and Product Owners in comparable situations.

Projects may include products and/or services, and the Program Manager is responsible for participating in defining and prioritizing the Program Backlog. This specific backlog drives the delivery of work performed by the Program Manager. The Program Manager is also responsible for removing impediments at the Program level. This individual works with the Portfolio Director to understand objectives, budget, portfolio, and program requirements.

Program Managers should ensure that the PMs within their programs are:

• Delivering a product that meets users’ requirements

• Adhering to VIP policy and procedures

• Delivering on-time, on-budget and within scope

• Tracking and delivering valid data for reporting requirements

1.5.8 Scrum Master

A Scrum Master is a servant leader who ensures that the Project Team understands and implements Agile practices. The contractor is responsible for providing a Scrum Master for the project. If the project does not have any contracted resources, someone from the Project Team is assigned to be the Scrum Master. The Scrum Master, in coordination with the PM, is responsible for:

• Facilitating the daily standup/Scrum meeting

• Helping the team maintain their Burndown Chart and Velocity

• Facilitating Sprint Planning sessions, Sprint Reviews, and Sprint Retrospectives

• Assisting in Build Planning

• Shielding the team from interruptions during the Sprint

• Removing obstacles that affect the team

• Assisting the Product Owner in User Story development

• Assisting Product Owner in prioritizing backlog items

• Encouraging collaboration between the Scrum team and Product Owner

1.5.9 EPMO VIP Business Office

VIP Business Office (VBO) falls under the Agile Center of Excellence (ACoE), a division of the Enterprise Program Management Office (EPMO), and is responsible for overseeing the VIP Lifecycle.

Additionally, the VBO team will collect and analyze all performance data to enhance accountability within OIT.

1.5.10 OIT Governance Boards

The IT Governance Framework gives all OIT senior executives the opportunity to contribute their https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018) subject matter expertise to specialized Governance Boards, where they will serve alongside business partners. Detailed information on the Boards can be found at the OIT Governance site. One of the boards provides direct oversight of the VIP governance process, ensures that best practices of Agile product development and delivery are followed (i.e., Epics, Process Owner, PM), and that accountability for meeting budget, schedule, resources, scope, and key gates are managed appropriately.

1.5.11 IT Operations and Services Implementation Manager

The IT Operations and Services (ITOPS) Implementation Manager focuses on the implementation of the product. The ITOPS Implementation Manager does the intensive planning and coordination work to support implementing information systems or new processes into the business environment, including a seamless transition of the product into an operational state. For projects that require implementation support, an Implementation Manager will be assigned to support the PM. The Implementation Manager will provide focused coordination of the deployment and implementation activities. PMs may request an ITOPS Implementation Manager and other ITOPS resource via an email to OIT ITOPS Service Request VAITOPS.ServiceRequest@va.gov. Many service requests are more implementation-oriented and do not require a PM. An ITOPS Implementation Manager can be assigned to lead non-VIP efforts that do not: require enterprise or multi-district deployment; involve new construction; require new solution design development, interfaces, integration with other systems, platform engineering, major acquisitions, or district-wide or site-level implementations of previously developed/tested configurations. This work would be entered through VIPR, and the Demand Management Office would determine which efforts would be directly routed to ITOPS in collaboration with ITOPS representatives participating in the VIPR discovery and review processes.

1.5.12 Release Agent

The primary role of the Release Agent is to monitor, audit, and report on the completeness, integrity, and traceability of the project data associated with a release. The Release Agent provides information about release requirements and feedback about the status of project data to the Project Team and other Stakeholders. The Release Agent also collects metrics at certain points and intervals. This feedback enables the Project Team to address any deficiencies as quickly as possible.

The Release Agent maintains an up-to-date picture on the quality and completeness of the product, with a particular focus on deficiencies that would prevent VA from releasing new functionality to production. The Release Agent ensures that the Portfolio Director, Product Owner and the Receiving Organization's Representative have access to this information on an ongoing basis.

1.5.13 Health Product Support (HPS) Application Coordinator (AC) The HPS AC, or equivalent, is a member of the Project Team developing new health products, enhancing health products, or sustaining health products. The HPS AC serves as a Veterans Health Information Systems and Technology Architecture (VistA) Subject Matter Expert (SME) to the PM, Release Agent (RA), and Project Team and is responsible for assisting with coordinating the activities for the national release of health products and/or VistA patches, ensuring a smooth transition of the assigned health product or VistA patch from development to Health Product Support for sustainment. The AC performs a technical review working closely with the developers and test sites, reviewing all required project documentation, installing and testing Initial Operating Capability (IOC) of VistA patches, and when applicable, testing of new health products prior to national release of the health product or VistA patch. All findings will be stored in approved VA tools as part of the product.

https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx https://vaww.oit.va.gov/governance/ mailto:VAITOPS.ServiceRequest@va.gov https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

1.5.14 Strategic Technology Alignment Team

The Strategic Technology Alignment Team (STAT) assists in guiding IT Program and Project Managers in the alignment of business and IT functions to VA Enterprise Architecture (EA) and Security standards, such as Design, Engineering and Architecture (DEA) Epics, Federal Information Security Management Act (FISMA) Security Epics, One-VA Technical Reference Model (TRM), and Enterprise Design Patterns (EDPs). STAT consists of two teams, one for FISMA Security and one for DEA; each with their own agent roles. Each VIP Project will be assigned a FISMA STAT Agent, as well as a Tier 1 and Tier 2 DEA STAT Agent. The FISMA, and Tier 1 and Tier 2 DEA STAT Agent assignment process is identical to the Release Agent assignment process previously detailed and generally occurs following Release Agent assignment.

1.6 Flexibility of Project Requirements

Portfolio Directors can tailor VIP project requirements to accommodate a specific body of work. In rare instances, primarily for high-risk/high-visibility products, Portfolio Directors can add additional requirements they deem necessary beyond the core set of required artifacts, if it is in the best interest of the VA enterprise to hold the product to additional scrutiny.

https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

2 VIP Lifecycle

VIP creates a streamlined IT oversight process that further uses the Agile Project Management Methodology. The following sections of the VIP Guide outline the phases of development of an IT project, from Intake to Sustainment, as depicted through the VIP Lifecycle.

Figure 1: The VIP Lifecycle

2.1 VA IT Process (VIPR) Intake

Figure 2: VIP Lifecycle – Intake

The VA IT Process Request (VIPR) is the only method to request new or enhanced VA IT capabilities. In conjunction with the VIPR Tool, it is a mechanism to access expertise to help in the identification and analysis of IT solutions that satisfy business needs while delivering the best value to VA, as well as to identify the IT funding and/or resources required to implement and/or maintain those solutions. The VIPR Intake Process ensures Product Owner requests are validated, analyzed, and/or transitioned to service providers for execution. The VIPR Intake Process is often the avenue to obtain operational infrastructure, application sustainment, development or other specialized support in coordination with the Account Management Office.

VIPR Intake is the process through which OIT absorbs the problem statement and starts to envision a designed solution. A clear objective for the product must be defined during this stage, and be https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018) clearly represented in the problem statement. The problem statement must be written by the Product Owner in collaboration with the ITAM and, as applicable, the Project Team. Defining the problem statement is one of the most critical parts of any product development process, as it identifies all work that follows. As the business requirements become better defined, a unique identifier, called a VIPR number, is assigned at project intake.

All project members should be familiar with the basic Business Epic that is entered into the VIPR tool.

Once the project is approved, this Business Epic is the first statement that should be entered into the VA approved repository for project documentation.

After a project is accepted through VIPR Intake, an Enterprise Project Structure (EPS) number is assigned, a PM is assigned, and the project is entered into the VIP Dashboard. Entry into the VIP Dashboard moves the project from Intake to the Initiation Phase.

2.2 Initiation Phase

Figure 3: VIP Lifecycle – Initiation

In the Initiation Phase, high level Business Epics are further defined into an initial set of Epics that will prepare the project for success in the Project Phase. Following the Agile methodologies, IT product requirements are expressed in terms of Epics and User Stories. OIT captures all necessary data in the Epics to satisfy product requirements.

OIT’s ability to remove certain review functions is dependent on data being entered in online tools (VIPR, VA approved tools, etc.) and accessible by members of the portfolio, project, or support teams.

As Epics are built, they must be available in the VA approved tool repository for review. This includes the Business Epics and the various Alignment Epics (including Section 508, Design, Engineering, and Architecture (DE&A), Security, etc.). For assistance with Alignment Epics, please send an email to epics@va.gov.

The Business and Alignment Epics (Figure 4) should include hardware, software, security, development, environments, cloud and other services, and sustainment requirements necessary to create the capability. VA Enterprise Architecture standards and reference architectures will always be leveraged, unless an emerging requirement provides a need for a new technology solution.

mailto:EPICS@VA.GOV

Figure 4: Relationship of Epics to Solution(s)

2.3 Project Phase

For OMB reportable projects, the Project Phase is a reportable activity. OMB requires reportable activities to be six (6) months or less. For consistency, all projects that follow VIP should keep the planned Project Phase length to a maximum of six (6) months. If a project has a justifiable reason to plan the Project Phase for more than six (6) months, that must be approved via an Exception Memorandum signed by the Deputy Assistant Secretary (DAS) or Deputy Chief Information Officer (DCIO) of the Project Manager’s organization. If a project planned for a Project Phase of six (6) months or less, but needs more time, no Exception Memorandum is required.

2.3.1 Project Planning

Figure 5: VIP Lifecycle – Project Planning

Project planning occurs within the Project Phase, to ensure the project is resourced correctly (funding, resources, and contracts) for a successful product delivery. During planning, and throughout the life of the project, Project and Program Managers must maintain an audit file that supports how costs and budget information were derived for individual builds and total lifecycle product costs.

The sources used for the cost estimates could include the Budget Tracking Tool (BTT), Primavera historical product cost data, Integrated Funds Control, Accounting, and Procurement (IFCAP), and others, and must be documented. Capital costs, as part of Development, Maintenance, and Enhancement (DME), the funding most often used by IT projects, can include:

• Hardware

• Software development and acquisition costs https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

• Commercial off-the-shelf acquisition costs

• Government labor costs

• Contracted labor costs for planning, development, acquisition, system integration

• Direct project management and overhead support

• Costs of migrating/sustain the product in the Cloud

All applicable costs must be included to arrive at the total lifecycle project costs.

Project planning includes specifying all Key Performance Indicators (KPIs) and Service Level Agreements (SLAs). The Release Agent should ensure the aforementioned is captured in the Business Epic and Sub-Epic record(s) for the project entered in the approved tool. Before the conclusion of this phase, a Critical Decision 1 (CD1) will occur.

High level but important activities that occur during the Project Phase include:

a. Forming a project team

b. Elaborating Business and Alignment Epics into sub-Epics

c. Generating a PWS as required

d. Identifying the Receiving Organization

e. Identifying Initial Operating Capability (IOC) requirements (if appropriate)

f. Creating a Primavera project entry

The Receiving Organization should be the group responsible for ongoing sustainment of the product upon closure of the project. The Receiving Organization’s sustainment responsibilities will be led by a Sustainment Manager. Usually sustainment support will come from EPMO's Transition, Release, and Support (TRS) Office.

During the Project Phase, a Release Agent is assigned to monitor the release. For any questions regarding the process, please contact the Release Readiness Office at OITEPMOTRSRROReleaseAgents@va.gov.

The Release Agent’s role is to enhance the likelihood of a successful release by reviewing and ensuring that information provided by the Project Team, including appropriate project data, is being managed in the repositories within the VA approved tools. For more information about the role of the Release Agent, please refer to Section 1.5 of this document.

It is essential that all releases, whether IOC or national release, be added to the POLARIS calendar as early as possible, and is updated regularly. Assistance from the POLARIS user community in providing this essential information will greatly enhance the ability of OIT and Veterans Health Administration to successfully plan limited resources to support the multiple product IOC Production events and deployment to field sites.

The ideal time to create an entry in POLARIS is around the time of a CD1, or before, when the need-by date is communicated. The date can be easily updated all the way up to the week before release.

The next best time to create or update the POLARIS entry, is just after contract award when the proposed/estimated completion date should be known.

https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx http://vaww.oed.wss.va.gov/process/Public/API/DisplayProcessOverview3.html?ID=SLM http://vaww.oed.wss.va.gov/process/Public/API/DisplayProcessOverview3.html?ID=SLM mailto:OITEPMOTRSRROReleaseAgents@va.gov

2.3.2 Critical Decision 1

Figure 6: VIP Lifecycle – Critical Decision 1

A Critical Decision 1 (CD1) occurs when a project is ready to begin the process of moving to the Product Phase. This can be done to acquire contract resources for the Product Phase if contract resources are required, or to acquire FTE resources. The approval is given by the VIP Triad at a CD1.

The VIP Triad decision for a CD1 can be: Approve or Disapprove; there is no “Approve with Conditions”. CD1 artifacts can be found under Section 4.2.1, Required Artifacts, in this guide.

Templates for CD1 required artifacts can be found on the VIP SharePoint site.

By CD1, a project should have its scope, schedule, resources, documentation and acquisitions planned, along with any risks identified, funding secured, IOC sites determined, and documentation updated. The effort retains its VIPR unique number for the Calendaring and Release processes. The Program Manager should review projects prior to the CD1, but this is at the discretion of the Program Manager.

VIP only requires a single CD1 per project which validates the project is ready to move forward with acquisition (a contract), or ready to receive FTE resources, thus allowing the project to continue planning until ready to begin builds. While the CD1 template requests feedback on builds, the PM is not committed to the future build dates at the time of the CD1. Future builds presented on the build slide in the CD1 are proposed and not committed; as dates cannot be accurately determined until all resources have been on-boarded and planning is completed. Build dates are not committed until the PM enters them into the VIP Dashboard as an Approved build, with Planned Dates for Start and Completion. Once the build is approved in the VIP Dashboard, the Planned Start Date and Planned Completion Date cannot be changed without Program Planning and Oversight (PPO) and VIP support. A CD1 does not have to list all builds for the entire project. Per VIP policy, a Portfolio Director does not have to approve all builds at a CD1.

VIP policy does not mandate that any build needs a formal approval before starting, outside of the project Scrum meeting. However, a Portfolio Director can decide to have an approval for every build for every project, or, make that decision on a project-by-project basis. The Portfolio Director may also choose to handle build approvals through a Scrum of Scrums, Super Scrum of Scrums, or via the Program Manager.

When the Portfolio Director, Product Owner, or Receiving Organization Representative is not available to act as the approving official for CD1s and VIP Artifacts, a duly signed Delegation of Authority (DOA) https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Assessment%20and%20Reporting.aspx https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018) authorizes specific employees to act as a Voting Proxy on behalf of their respective position. This DOA memo must be on file with the VBO.

2.3.3 Contract Award and On-Boarding

Figure 7: VIP Lifecycle – Contract Award and Onboarding

This stage is necessary only if the product requires an acquisition and/or contract support. During this period, the Project Team should work closely with the Technology Acquisition Center (TAC) to ensure that the Performance Work Statement is written so that the contractor(s) shall follow both an Agile Methodology and the VIP established by OIT to enable an Agile, user-centered process.

2.4 Product Phase

VIP recommends the Product Phase not exceed 24 months, but leaves the responsibility for monitoring Product Phase length to the Portfolio Director.

2.4.1 Product Phase Start and Build Start

Figure 8: VIP Lifecycle – Product Phase Start and Build Start

NOTE: The Project Team should deliver releases as rapidly as possible during the Product Phase.

In VIP, a development cycle is called a build. Builds are not to exceed three months planned length, but can be of a shorter duration. The goal should always be to deliver functionality into production at the end of a build. However, a build would be considered on-time if the functionality passed User https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

Acceptance Testing (UAT), was accepted by the Product Owner, and was placed into a Pre-Production or Production environment at the end of the build cycle. Each build that develops code should submit their code to the EPMO Open Source Coordination Office.

2.4.2 Build and Development

Figure 9: Build Development Cycle

Build and Development should begin after the start of the onboarding of contractors. Each build is not to exceed three months planned length. VIP provides a flexible development framework in which Agile teams can release as rapidly as they are capable, so a Project Team could choose to have 6, 12, 18, or more builds.

The Product Phase is divided into builds, which are further divided into Sprints. A build can have multiple Sprints within it, or each Sprint could be considered its own build. Regardless of the length of the cycle or Sprint, as determined by the Project Team, everyone must follow the standard development cycle.

Builds can be for development, IOC testing, release, or other activities depending on the project type.

Builds that are for development should strive to end with a push to production, but pre-production and a completed UAT is acceptable. UAT in pre-production is a signed validation of the functionality from the Product Owner and users. If critical defects are found, resolution needs to occur immediately. Less severe defects can be deferred to the next Sprint (or release) depending on the severity of the defect.

A defect is a deviation from requirement or standard, such as a failure to meet customer acceptance criteria. Defects could also occur as flaws or imperfections in a software product or process. In an Agile environment, testing and critical defect resolution should be completed within the same Sprint and/or build.

2.4.3 Critical Decision 2

Figure 10: VIP Lifecycle – Critical Decision 2

A Critical Decision 2 (CD2) occurs after all (pre-IOC) testing is complete and the PM believes the build or product is ready for release and addresses all relevant compliance requirements. This decision should answer the following questions:

1. What are the systems this product interfaces with and is it compatible with all of them?

2. Have all sustainment operations and maintenance costs been addressed, including

Technical Debt?

3. Who are the Stakeholders and teams directly affected by this new product, and are they aware of the impending release?

4. Does the system meet applicable Alignment Epics, Alignment Sub-Epics, and Alignment

User Stories?

5. Has all required testing associated with Alignment Epics been completed and documented?

6. Has all required regression and end-to-end testing been completed, and all documentation updated?

7. Have all required Quality Assurance Reviews been completed and documented?

The Release Agent assigned to the project will publish a Release Readiness Report distributed to the VIP Triad and other Stakeholders prior to any production release (either IOC Production, General Availability, or a national production environment – but not pre-prod). The Release Readiness Report provides the VIP Triad (Portfolio Director, Product Owner, and Receiving Organization Representative) with the most up-to-date picture of the quality and completeness of the release candidate, so the VIP Triad can make an informed decision regarding approval/disapproval of the release.

The Portfolio Director, Product Owner, Receiving Organization Representative (VIP Triad) approves or disapproves the product for release. The VIP Triad decision for a CD2 can be: Approve or Disapprove;

there is no “Approve with Conditions”. CD2 artifacts should be provided to the VIP Triad in a timely manner before CD2. When the Portfolio Director, Product Owner, or Receiving Organization Representative is not available to act as the approving official for CD2s and VIP Artifacts, a Delegation of Authority (DOA) memo, authorizes specific employees to act as a Voting Proxy on behalf of their respective position.

The VIP requirement for a CD2 should be tailored by the VIP Triad. If no product is being delivered into production, then a CD2 is not required.

https://vaww.vaco.portal.va.gov/sites/OIT/epmo/vip/Pages/Policy%20and%20Guidance.aspx (DEC 2018)

This decision reviews the full product, and if nothing significant changes in the product’s technical environment or security profile, by VIP policy, approvals are not required for future releases. This means the only release that requires a full CD2 is the first release into production. Once this first release occurs, subsequent CD2s may be held at the discretion of the VIP Triad, simply to ensure the proper requirements have been updated and the appropriate parties are prepared for the additional release(s). CD2 Artifacts can be found under Section 4.2.2, Required Artifacts. Templates for CD2 required artifacts can be found on the VIP SharePoint site.

Use of IOC Implementation Model If a project uses the IOC implementation model, CD2 approval means that the product is approved to begin implementation at the first IOC test site.