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 CPS 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
The account manager 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. 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 client kickoff meeting. Get familiar with what the client 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 client 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 client 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 client will help make your understanding explicit and will reveal discrepancies between your understanding and the client’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 client.
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
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.
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 client 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.
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 two primary ways we do this. The first is the Weekly Ship, a quick report on the status of the project emailed to the client and dropped into #the-shipping-news Slack channel at the end of each week. Here's an example of a Weekly Ship doc.
You should also plan to have a mid-project review with the partner after your research sprint to communicate progress to date, initial observations, and update the project brief as needed. See the blog post about Getting partners on board with research findings.
Additionally, some 18F teams include a weekly meeting (in-person when the 18F team is co-located with the client) in their cadance so the client receives two updates each week (the weekly ship and the weekly meeting). When teams include a weekly meeting, the mid-project review tends to be much smaller or just another weekly meeting since the client has been updated all along (especially when weekly meetings are held in-person because the client and 18F team is co-located).
Consider starting this at about the mid point of the path analysis. This always takes longer than you'd think; getting started on writing the stuff that doesn't depend on finishing your analysis -- like the problem statement, background, etc. -- can help overcome the inertia of a blank page.
It's a good idea to find out whether the client agrees with your findings before you start working with them on recommendations. If they don't, figure out why. Is there some context you're missing, for example. Is the way you're articulating the finding not landing well with them? You may need to better understand the situation or better explain the finding. If you have a finding that the client acknowledges but that is not a priority for them to address, it's probably better for you to spend your time on recommendations for findings they do care about. Work with the partner to come up with recommendations that will work given the agency’s resources, culture and priorities.
The PA report template includes several elements: a problem statement (what problem we're trying to solve), background (what's the current state), findings (what you observed), recommendations (how to address the findings), and next steps (what needs to happen to execute on the recommendations and where 18F might be involved). A couple of tips:
- Write for all your potential audiences - They likely include both technical and non-technical stakeholders.
- Don't try to do too much - Aim for 12-15 pages. Seriously reconsider how much detail you're providing if you have more than 20 pages, not counting the appendix. Move descriptions of what methods you used to the appendix. Too many findings or recommendations makes it hard for the partner to focus. Also resist the urge to go into too much detail about how to adopt a better product development process, or user-centered design process, etc. It's better to demonstrate a better way to work alongside a partner during a project, not talk about it in a report.
- Tie your recommendations to your findings - Best practices are great. So are your informed opinions. But findings are what you actually observed. Focus on your findings and make it clear how the recommendations you're making directly address them.
- Make sure your findings address your problem statement - If they don't, either rewrite them so they do or rewrite your problem statement.
- Use the right tool for the job - Slide decks are great for presentations, but they're not great for communicating detail. If you need both a report and a slide deck, make sure to give yourself enough time to create both.
- If there's more work for 18F, say so - We want to recommend what we truly believe to be in the client'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 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? 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