Other work to finish:

• Get a print/downloadable version
• Online version
• Create an online form for a digital version
• Help with diagrams

Project Charters as a foundational tool to successful engagements

Just over five years ago the United States Digital Service was created in the aftermath of technical challenges surrounding the launch of HealthCare.gov. Since then, USDS has expanded its reach to agencies and departments across the Federal government. There has been no shortage of lessons along the way. To share some of that knowledge we'd like to share thoughts on crafting a Project Charter with tools like the Digital Service Strategy Canvas and Engagement Key Plays.

After establishing a relationship with an agency, teams use project charters to kick off an engagement. They are a primary mechanism for teams to set expectations with government agencies. When well thought-out and written they serve as a major component in building strong relationships with partners. They provide documentation of executive stakeholder support and a level of authority of the work, a vital reference point. For USDS they also serve as a touchstone throughout the project lifecycle.

Each charter should reflect the nature of the project. Included below are three tools, a project charter template, an engagement key play diagram, and a digital strategy canvas. Used in conjunction will help your work through background, strategy, and ensure your charter reflects the nature of the project. While USDS has found these components to be effective, our primary intent is for you to take what works, make it your own, and leave the rest (or give feedback so we can improve!).

Engagement Key Plays and Digital Strategy Canvas

In addition to a Project Charter guide and template are two new tools to assist in project and team development: The USDS Engagement Key Plays and Digital Strategy Canvas.

USDS Engagement Key Plays

USDS provides numerous ways to help departments and agencies. Most of our engagements fall into general patterns varying in time, scale, requirements, and limitations. Over time we have found some types of projects are more successful than others for various reasons. When creating your charter consider these key plays and alter your charter to reflect an appropriate level of risk to success.

The US Digital Service Strategy Canvas

As opposed to the Key Plays and Project Charter the canvas is intended for internal teams only. By working together to consider what success should look like prior to an engagement, subsequent conversations with your stakeholders can then address potential problems faster. It's important to work through the canvas with empathy, respect, and assume good intentions. The outcome is to be able to holistically consider and describe a problem in addition to potential motivations and incentives for behaviors.

Project Charter Background & History

Government is an incredibly complex environment. Therefore, charters need to remain highly flexible to accommodate the changing circumstances. There are no fixed matrices or score cards here; the only constants are "it depends" and "things will change."

Charters are not magic bullets. They don't prevent change or uncertainty. They can however help you and your team set mutual expectations concerning how you will work together and what the beginning, middle, and end of the project will look like.

With a mutual understanding of communication, expectations, and criteria, your team will be well positioned to:

• –Ask more productive questions
• –Surface learnings faster
• –Uncover root cause incentivizes that will drive better behavior

Producing a charter should be a collaborative effort with your stakeholders. Drafting it together is an important method to drive consensus, set expectations, and have potentially difficult but necessary conversations up front.

Guide to Project Charter Components

Key Components

There are four key components to consider for any charter: objectives; outcomes; criteria (for success, handoff, and exit); and agreement.

Objectives focus conversations with your team. They also ensure alignment and overlapping priorities with your stakeholder. Objectives provide a quick summary and focus on proactive actions. Be sure to call out specific users to ensure the focus of the engagement is around the people it serves. If possible, create objectives so good people can't say no. (i.e.- "improve the lives and relocation experience of veterans", "ensure the American people have access to Medicare resources", etc). This is the elevator pitch of your project.

Outcomes measure the success of these objectives. They should be as measurable and quantitative as possible. Choose metrics that measure impact not optics and will reflect successful objectives. For example, projects that require rapid deployment and intervention might refer to Dickerson's Hierarchy of Reliability to create metrics (mean time to resolution, build/deploy downtime, or availability/uptime). In contrast, projects that deal with procurement might choose to focus on product quality (support calls related to design/product, usage statistics, estimated vs delivered story points, etc)

The next section includes success, handoff, and exit criteria. All three work together to create boundaries for the team and set expectations for your organizational partnership. They help outline the best and worst scenarios and can drive critical conversations if (and when) landscapes change for your internal team and partnership. By leading with success criteria for your stakeholder the focus is on a positive partnership with the agency. Teams are then encouraged to use this as a gateway to address and discuss what happens should boundaries change and the project face the possibility failure.

Finally, every charter should have an agreement and signatures from a primary executive stakeholder from both departments. This is a simple but important step. It will help open doors and quickly gain buy-in and approval from other groups.

Considered Components

Charters should be kept terse to accommodate ambiguity, flexibility, and shifting landscapes. As projects change, overly detailed charters could potentially lock teams into a vision that no longer aligns with a changing landscape, which may disturb the momentum of a project.

That said, there are certainly instances when including extra information may be beneficial for your team. For instance, detailing logistic and meeting details may be helpful to ensure regular communication with one group but may limit flexibility with another.

This leads us to another set of components to possibly include in your charter, which we'll call considered component. For instance, project backgrounds can be used to provide context for new or changing relationships with agencies. Similarly, listing stakeholders can drive awareness of roles and responsibilities across an organization. Finally, listing communication guidelines can affirm requirements for individuals and expectations of commitment.

Limited Use Components

Components such as roadmaps, communication logistics, dependencies, and out-of-scope items have been used by teams on projects requiring another level of detail, prescriptive information, or shorter timelines. These limited use components should be used at your team's discretion as they tend to be more solution-driven. Focus on impactful conversations and refrain from including items that have been discussed outside of a charter.

Project Charter Template

Key Components

Date

Project Charter for [Project Name]

What follows is a living document, which outlines the collaboration between Agency X and USDS. It is not a fully prescriptive or contractual plan, but rather a vision for engagement.

Project Objectives:

In uniformity with USDS values this charter and engagement aims to deliver better government services to the American people through technology and design. The goal of USDS' involvement is to drive the design process for a replacement of the Widget Application. Based upon USDS' understanding and evaluation of the current Widget Application, the best approach is one that meets the following objectives:

• Provides a significant improvement in usability for the Widget Workers
• Utilizes usability principles and styles in line with Agency X's existing design system.
• Supports the mission of Agency X and Widget Workers: To allow for the faster, more streamlined adjudication of Widget decisions.

Project Outcomes:

The team will deliver a report outlining the pain points, roadblocks, and technical barriers to effectively utilize the Widget Application. Recommendations may encompass all aspects of the process including recommendations around policy, technology, business practices, and procurement. The report will be delivered immediately following the readout.

• The team will also deliver a new Widget Application design which significantly improves the Widget Worker workflow by decreasing time spent per widget by 50%

• The new design has been validated by 3 different users per persona using user-centered design principles by the design hand off dates
• Adoption across teams of iterative development practices including test-driven development and once-a-week backlog grooming

Success Criteria:

• Consistent and maintained scope

-

• To avoid scope creep or expansion changes to the overall product roadmap will be discussed and prioritized prior to any sprint work beginning.
• Subject Matter Experts availability
  • To ensure accurate understanding and correct interpretations policy experts are required throughout each sprint to support the team by answering questions as they arise. The Policy experts will try to reply with feedback within two business days.
• Resource allocations
  • USDS will dedicate full-time resources towards the Widget Application. Once allocated, they will streamline direction by working closely with the Product Owner.
• High level of engagement
  • Communication and responsiveness is key to delivering good product in a timely manner. All parties will follow sprint cadence.

Handoff Criteria:

• To ensure the success of the continuation and life of the engagement USDS will help vet and hire a dedicated product or program manager.
• As USDS introduces agile across the organization handover of agile rituals to an X agency program manager will commence.
• Before handing over the engagement USDS will ensure an operational contract is in place between X agency and X contractor.
• USDS will have regular retro's and post-mortems for releases with the contributing team
• Continued conversations and regular meetings between USDS and X Stakeholder will ensure consistent progress or discussion and the removal of blockers.

Exit Criteria

• If success criteria are partially met then this charter will be reassessed with stakeholders. Actionable next steps will be created and communicated which focus on removing blockers, adding a concrete timeline, and specific deliverables which focus on realignment of success criteria.
• If success criteria should change or there are limitations to handoff such as contract, resourcing, or availability changes occurs protocol dictates a reassessment and iteration of this document to reflect a changing landscape

Agreement This agreement may be modified only in writing, duly signed by the authorized representatives of both parties. Any such written modification shall become an annex to this agreement. This agreement may also be cancelled by either party with 30 days notice by the submission of a cancellation notice in writing to the other party.

This agreement takes effect upon signing by both parties and expires four years from the date of signature.

This agreement is signed in the spirit of cooperation and collaboration to build more effective digital services in the federal government.

Exec Name Title, Digital Service Agency Month Day, Year

Exec Name Title, Agency Organization Month Day, Year

Considered Components

Project Background and Opportunities:

Agency X's current system Widget Application, originally built in 1996, has largely failed to keep pace with the evolving demands of Widget Workers over the last few decades. Today, development obstacles and funding shortfalls have turned it into a system in need of replacement that is less secure and difficult to update. In order to meet the needs of the end user, in addition to the many planned technical advances, Agency X requires the collaboration of USDS guidance on establishing a user-centric design approach to software development.

Stakeholders & Key Players:

Frequent and transparent communication is paramount to the successful replacement of the Widget Application. USDS and Agency X are committed to this goal. All parties will use the agile development process, introducing small, incremental software changes during short, 1-2 week sprints. USDS will provide Agency X access to sketches, prototypes, and other supporting materials during this process.

*Wherever possible, roles will attempt to be kept in place for the duration of the project. The charter may be revisited if one of these roles is replaced.

Stakeholders

Executive Sponsor: Shelley Shore, Agency X SES - Widget Programs.

Product Manager* : Joe Smith, Agency X - Program Director

Engineering Lead*: Nick Cadwell

Design Lead*: Laura Beech

Business Partner Lead*: John Blaze, Agency X – Operations

Teams: Agency X HQ, Agency X Policy Team, Agency X Widget Operations Team, Agency X Widget Application Engineering Team, USDS Widget Application Design team.

Key Players

Project Manager: Kara Apple, Agency X- Project Manager

Design Director: Jonas Jackson, USDS

Users: Widget Workers

Communications:

Status will be shared throughout the engagement every [Day of Week] afternoon/morning via [Method of Comms]. Status reports will include project goals, blockers, accomplishments, etc.

Scheduling will be maintained by [Person] and [Person] who can be contacted at [Method of Comms}.

Limited Use Components

Roadmap

The below Roadmap is written as a living document, rather than a contractual set of milestones. Any dates listed below (except Preliminary Design Validation) are contingent beginning \<date\>, and prompt participation of all stakeholders as necessary.

| Goal | Date | Features/Deliverables | | — | — | — | | Requirements Validation and Discovery | April 15 | Observe current workflow of Widget Application and understand the intention behind requirements. | | Preliminary Design Validation: Tasks A, B, and C | May 31 | Present and review wireframes for proposed Widget Application and iterate based on stakeholder feedback (end user feedback has already been completed as part of the agile design process) | | Preliminary Design Validation: Tasks D & E | June 18 | Present and review wireframes for proposed Widget Application and iterate based on stakeholder feedback (end user feedback has already been completed as part of the agile design process) | | Alpha/MVP Handoff | August 31 | Engineering Handoff of a skeleton system to test basic features, including:

• Access for Widget Application
• View Widget Adjudication Status
• File Widget Application for Type A | | Beta Handoff | Oct 1 | Engineering Hand-off of a design that meets most basic features and workflow, could be tested with a few manual workarounds. | | Launch Handoff | Nov 15th | Robust Design delivery of error states, edge cases, and all case types. |

*These milestones mark handover completion dates, in reality design handoffs should happen in an agile, iterative fashion each 2-week sprint.

Communication Logistics

Design Working Sessions	Time: Biweekly, Fridays 1030-1200 Location: Video Conference Dial in Info Content: Design will share their work in progress and lead discussion about the design and feedback they have gotten from real users. The design review is where acceptance of the works in progress will be made. In an effort to keep the project aggressively moving forward, a stakeholder missing the design review may not halt progress or approval past the meeting time to give review. Whenever possible, feedback contradictory to the end user research will side with the end user feedback shared by the design team. Participants: Agency X Product Manager, USDS design team, Widget Application Engineering Lead, Business partners, and USDS Design Director (optional).
Leadership Check-in	Time: Every 3 weeks, Monday 1530-1600 Location: Video Conference Dial in Info Content: Touchbase on team progress and alleviate any concerns Participants: Agency X Product Manager, USDS design project lead, and USDS Design Director, Executive Sponsors.
Sprint Review	Time: Every 2 weeks, Wednesday 1330-1600 Location: Video Conference Dial in Info Content: Sprint Ceremonies for complete engineering and design teams to share progress. This meeting is largely for informative purposes only. Approvals and Code reviews should be done in respective working sessions. Participants: Agency X Product Manager, Widget Application Team (Engineering & Design), Business Partners.

Dependencies

• Completion of System Z which is an integration point for Widget Application.
  • Product owners of System Z and Widget Application will touch base frequently to discuss on any slippage of schedule.

Out of Scope:

• Robust Training guidelines and instructions for Widget Workers to learn the new Widget Application.
• Conducting design critiques or content audits for any other system touching the Widget Adjudication process and other components of Agency X.
• The idea of seamless integration between Widget Application and Widget Documentation is an interesting project but will be out of scope for the initial MVP this charter covers.