Once the agreement has been signed, you can start billable work on the project. The steps in the project will probably look something like this:
- Meet with Account Management for the internal handoff
- Draft a problem statement
- Kick off the project
- Gather data
- Communicate your progress
- Write the final report
- Identify further work
- Conduct a postmortem
You may notice that this document is not very prescriptive: it doesn't tell you what to do each week or how to do it. If you're working on a Path Analysis, it's up to you to design the project to fit your partner's needs. Path Analyses are incredibly flexible by design, because we want teams to have the space to adapt quickly to what they learn. This is both a challenge and an opportunity — and if you need help navigating it, reach out to your account manager or lead/supervisor for support thinking through how to approach your project.
The account manager (AM) for this project has been involved since the very beginning. They likely attended the initial business development meetings and probably helped draft the interagency agreement (IAA). The first thing that'll happen is the AM will schedule a meeting with the 18F members of the team to go over what they know about the project and hand off any background documents that you should review prior to the partner kickoff meeting. Get familiar with what the partner originally contacted us about and how they described their needs and expectations. Understand what we sold them and how that is articulated in the statement of work.
Once you've had the internal handoff meeting, start thinking about how you want to use the kickoff meeting. Will it be a 90 minute meeting? A day-long working session? Figure out what's going to be the best use of people's time and what you'll need to get started. Some teams have found it useful to do some stakeholder interviews prior to the kickoff meeting and use the time to talk about what they heard. See this sample interview script to help get you started.
It may be happen that you are asked to do work or attend meetings with the partner before you have had an internal handoff or kickoff meeting. Please remember to wait until the internal handoff meeting or kickoff meeting, if you're not doing pre-kickoff stakeholder interviews, before starting work on the project.
The problem statement should be a short, 2-3 sentence description of what problem the partner is trying to solve. You should be able to apply the 5 "W"s (Who, What, Where, When and Why) to the problem statement. It should not suggest a solution. If you need some help creating one, see Dan Brown's article on How to Build a Problem Statement or this TTS Problem Statement document with different types of problem statements with examples.
The problem statement may need to be modified over the course of the project as you learn more, but having it prior to the first meeting with the partner will help make your understanding explicit and will reveal discrepancies between your understanding and the partner's.
The main purpose of the project kickoff is to make sure everyone involved is aligned on the goals of the project and on what will be delivered at the end of the engagement. Regardless of how long they're scheduled to run, you'll probably feel like there's not enough time to get to everything. Spend as little time as possible, if any, explaining how 18F works so you can focus on getting what you need to start the project such as agreeing to a reasonable scope of the path analysis and identifying stakeholders and user groups to interview. You will likely be able to conduct some of these interviews at the workshop itself by talking to relevant stakeholders and users (if you are on-site with the client.) Set expectations beforehand and make sure that the right people are available, and that you set aside some time to conduct these interviews.
By the end of the workshop, you should have alignment on a clear, manageably scoped problem, a good start on user and stakeholder interviews, and the beginnings of a strategy for the engagement. You should also have a clearer idea of what specific skills you will need to help you complete the path analysis. Make it a point to request more staff or a different staffing composition if you determine that additional skills are needed.
See these sample kickoff agendas for different timeframes to get you started:
- 90-minute agenda
- Half-day agenda
- Full-day agenda
- Multi-day agenda
Also it may be helpful to articulate the deliverables as goals or objectives rather than pieces of work or solution. That gives you more space to discover what might be the best path forward for the partner.
The approach will vary depending on the project, but may look something like this:
- Week 0 -- Do the internal handoff and any pre-work for the kickoff
- Week 1 -- Kick off project, schedule interviews, revisit staffing if needed
- Week 2-3 -- Conduct interviews, collect data
- Week 4 -- Check in with partner to share initial findings, conduct any remaining interviews, revisit the problem statement if necessary, do a mid-project retro
- Week 5 -- Analyze findings, start writing the report/presentation
- Week 6 -- Present final report/presentation
- Week 7 -- Incorporate partner feedback into the final report, run a project post-mortem
Remember, you can start the report/presentation at any time or alter this schedule as needed to fit the shape of your engagement. Most projets will have both a slide deck and a paper, consider the slide deck the movie trailer, and the paper the script.
While this is an 8 week project, you'll likely need to restrict the data collection part of the engagement to two weeks or so. Scheduling participants takes a lot of time. Analyzing interviews takes a lot of time. If you try to do more interviews than you can fit in two weeks, you'll run out of time and budget very quickly. Keep in mind that the point of a path analysis is to get a better understanding of the partner's problem. Go broad, not deep. You can (and should!) suggest additional work to delve more deeply into the issues you uncover here. It is not recommended to interview more than 12 folks.
At the same time, however, there are usually delays in scheduling interviews in the vast majority of projects. So do all you can to encourage your partner to help contact potential interviewees as quickly as possible. Then prepare for the case that scheduling still spills over into week 2, for instance, which may push interviews into week 4.
It may be important as part of your engagement to determine how ready the partner is to undertake a procurement to begin to address some of the problems identified. You can deepen the understanding of how ready the partner is by using some or all of the following questions as part of your data gathering activities:
- How do they currently buy software? What are their current contract obligations (if any)?
- Is the procurement office open to doing things in a new way? (e.g. Publishing RFPs on Github, using smaller project scopes, requiring open source, engaging new, non-traditional vendors)
- What are the FAS vehicles (if any) that the partner could potentially use?
- What barriers might the partner face around procurement? (e.g. are they required to use a certain contracting vehicle? Are there limitations on contracting vehicles based on the type of buy or funding?)
- What are the procurement office's deadlines? How long does it take to issue a solicitation? How long do solicitations remain open? What is the average time to award a contract?
As you gather data, make sure to bring the partner along as you synthesize it into findings and recommendations (blog post: Getting partners on board with research findings).
Partners will be a lot more invested in what you recommend if they understand and buy into your findings. What you don't want to do is keep the partner in the dark about your findings and recommendations until the final presentation. Don't aim for the Big Reveal. You're not a magician.
There are a few primary ways we do this:
- Meet with the partner regularly (at least weekly) to discuss what you're working on, share insights, and ask questions. Get clear early on about what meeting tools will work for everyone, and use video calls if possible. Include partners in stand-ups.
- Send a "Weekly Ship:" a quick report emailed to the partners at the end of each week. Here's the Weekly Ship template, an example of a Weekly Ship doc, and the Weekly Ship origin story. We also share Weekly Ships in #the-shipping-news Slack channel, so we can see what's happening across projects.
- Plan a mid-project review with the partner after your research sprint to communicate progress, initial observations, and update the project brief as needed. If you've been meeting weekly, this may be a short check-in, but it's helpful to take stock and make sure you're still aligned on the focus and goals. As you create presentations and begin to share ideas, follow presentation best practices to ensure you're being concise and compelling.
You can start writing your final report/presentation on day one of your path analysis, if you choose. You can start documenting notes and other items that may begin to frame out your paper.
The PA report template offers lots of structure and advice to work with, even before you begin the drafing process. You can restructure this report as you see fit to be tailored to what the partner needs. For example, if your partner wants next steps up front, you can move actionable items to the beginning of the paper.
Aim to share your report — or at least its content — with partners well before the last week of the engagement, so they have time to react, ask questions, and clarify. You don't need to wait until the whole report is fully baked before sharing; the more you can share initial recommendations and insights as you go, the better. Work with the partner to come up with recommendations that will work given the agency’s resources, culture, and priorities.
A couple of tips to consider as you write:
- Write for all your potential audiences - They likely include both technical and non-technical stakeholders.
- Tie your recommendations to your findings - Best practices are great. So are your informed opinions. But findings are what you actually observed. It's a good idea to find out whether the partner agrees with your findings before you start working with them on recommendations. If not, is there some context you're missing? Is the way you're articulating the finding not resonating? If you have a finding the client acknowledges but that isn't a priority for them, it's probably better for you to spend your time on recommendations for findings they do care about.
- Make sure your recommendations address your problem statement - If they don't, either rewrite them so they do or rewrite your problem statement.
- If there's more work for 18F, say so - We want to recommend what we truly believe to be in the partner's best interest, not what's in our own self-interest. But if there's further work to be done, and 18F is in a position to do it, we need to connect those dots for the partner by saying so explicitly in the Next Steps section of the report. If the next steps for the project include a procurement, call this out and talk about potential options for the partner to procure a digital solution.
- Ask for help from the Writing Lab - The Writing Lab can help you write, organize, and edit final reports and slide decks. They'll meet with you to go over expectations and the type of help you're looking for, and you don't need a full draft in order to get help. Submit an issue to get started, or ask in the #writing-lab Slack channel.
If you've waited until after delivering the final report to talk about further work, you've waited too long. Although the further work happens after the report, you'll want to raise the issue of potential work much earlier in the process.
Does the partner need to build a prototype to validate assumptions with their end users? Do they need to better understand a particular workflow before moving on? Do they need to undertake a procurement? Talk to a user group we didn't cover during the PA? And is 18F in a position to help them? Then start talking about this at the mid-point of the project. Explicitly call these out in Next Steps.
Here's a resource for you to understand what services TTS offers.
We want to make sure we get better at this with each project we do. Once the path analysis is over, find someone outside the project to facilitate a postmortem. This could be your account manager if they are accustomed to doing it. What went well, what didn’t and why, and what needs to change next time? Drop a summary of your findings in the #postmortems channel in Slack. Check out the postmortem template and instructions