Attention!

The content on this site is a materials pilot. It represents neither changes to existing policy nor pending new policies. THIS IS NOT OFFICIAL GUIDANCE.

Owning strategy and outcomes

Procurement flexibility

Ask what challenges the team is having in driving toward intended outcomes.

Ask who is involved in setting strategy and outcomes.

The state blames or relies on the vendor for the strategy and achievement of the outcomes.

The state takes partial accountability for the strategy and achievement of the outcomes; leans on vendors for procurement strategy.

The state considers themselves wholly responsible for the strategy and achievement of the outcomes; leads strategy, collects feedback from vendors.

What's this about?

What happens when you lose ownership of your mission? In this conversation, Princess Ojiaku and Nikki Lee talk about the challenges of driving towards desired outcomes and the ownership of strategy and mission in Medicare and Medicaid IT projects.

Lesson outline

Active listening: A conversation on owning strategy (~1h, solo)
Sharing experience (30m, small group)
Discuss in community (1h, group)

Active listening: A conversation on owning strategy (~1h, solo)

For this lesson's material, Princess Ojiaku and Nikki Lee talk about the challenges of driving towards desired outcomes and the ownership of strategy and mission in Medicare and Medicaid IT projects. A full transcript is (with a few "ums," "ahs," and flubs removed) is provided below, if you'd rather read the conversation.

A conversation about owning strategy and outcomes.

Listen actively

As with previous conversations, listen or read actively:

Keep a thread running in the back of your mind regarding your own projects, and turn up your “bullshit filter.”
Pause the conversation at any point that you hear something that makes you think about some aspect of a project you’re working with that makes you… wonder.
Reflect and take notes on the themes and ideas discussed to share with your group. In an active listening/reading process, it is this reflection, not the content itself, that is most valuable.

The process of listening actively takes time. You can listen closely on a first pass or have a first listen on a walk, then sit down and do a second listen where you take some notes. Do what works best for you.

A conversation about owning strategy and outcomes

Princess	00s	Good morning, my name is Princess Ojiaku, and I’m an innovation specialist at 18F. Today, we’re talking about vendor outcomes and strategy, and who does what, and who should do what. I’ve asked my colleague, Nikki Lee, to share her experience with us so we know what a good situation looks like and what a bad situation looks like, and everything in-between. I’m going to ask Nikki to introduce herself a little bit, talk about who she is and what she does at 18F!
Nikki	29s	Hey everybody! I’m Nikki, I think some of you actually know me, because I’m a product manager at 18F who has worked really closely with CMS for a number of years. I spent the bulk of my time working on the eAPD project with Jerome Lee and Nick A. And outside of federal work, I’ve done a variety of projects at the State level, predominantly with the CA state Medicaid system, both their eligibility and IMMS systems, and a year working with VT on their integrated eligibility initiative.
Princess	1m09s	Awesome. Well, thanks for giving a bit of your background. We’ve talked a bit before we recorded about the insights you’ve gained from some of that work, and the main thing that kept coming up was just “don’t outsource your mission.” So, I think the first thing that comes to mind when you hear “don’t outsource your mission” is that you might hand everything to the vendor, and have them do everything. Can you talk a little bit about that situation and what that means?
Nikki	1m45s	Yeah! I think this happens really commonly at the state level, and at CMS in DSG sometimes, which is that we don’t have expertise in technology, we don’t feel confident that we have the skill sets needed, we don’t have the time needed to run technology projects, and we delegate wholly to them and say “this is your problem now.” The challenge with that is that they don’t know the mission, and they don’t know the policy, and they don’t know the complexity of the space. No matter how much you screen for that, you’re still losing out because they’re always at least two or three degrees away from the core mission decisions. And generally what you also see with vendors is that the more time they spend developing policy expertise, the less time they’re spending keeping their technology skills really sharp. This happens with all levels Medicaid IT projects, from the simplest HITEC implementations up to implementing complex IMMS system functionality. This particularly shows up, and you can see this happening a lot, when a state has a system integrator, because a lot of times (but not every time) when they hire a system integrator what they’ve done is just given them the keys to everything, and they’re letting the system integrator run the show and make all of the decisions. That’s great for the system integrator’s account manager’s bottom line, but that team doesn’t have the context, and the relationships needed, to make smart decisions and good tradeoffs. So, it is really risky in terms of fulfilling the mission.
Princess	3m25s	That makes a lot of sense. If you’ve handed the keys over, so to speak, you’re in a situation where they’re setting strategy and outcomes, and not you, and they have more incentive to… kind of keep long contracts going, and maybe they are acting to that end. But, I’m wondering if there’s other ways it can happen where a state thinks they are owning the process, and maybe the vendor isn’t, but there’s still something in the way of actually achieving strategy and outcomes in an advantageous way.
Nikki	4m03s	Yes. That absolutely happens. I’ve seen that happening at the state level as well. Even though you’re not outsourcing the ownership to a vendor, you’re outsourcing it to a team internally that really is quite far away from your program team, and far away from human services and Medicaid expertise. That commonly happens if you have… if you have an internal contracts division, where the contracts team is taking a really strong hand on things, or it can happen with the PMO. That’s really common, because they’ll designate a project manager, and they’ll say “The project manager is accountable for the project success, and therefore they’re in charge, because they’re the person who is supposed to make this work.” They’re the person making the decisions about the strategy, which is starting to lead you in a dangerous direction. And the other place that can commonly happen is if you have a centralized IT organization, and they start to make decisions about what is important, what isn’t, what we can do, what we can’t… even though these are all state employees, they’re not all deeply in-tune with the Medicaid program. This is when you start to encounter the outsourcing risk.
Princess	5m18s	It’s almost like a trap, where you’re like… “Well, we have someone in the state doing it!,” but it’s not someone who is aligned with the goals and the mission of what you’re trying to do. I think that raises the question of what it means to really own a technology project? You can think you’re owning it (when you’re not), so where does ownership need to sit to work, and what does it mean for ownership to work?
Nikki	5m50s	Ultimately, ownership needs to sit with whoever the leadership is in whatever your human services division or department or organization is. These are the people who are speaking directly to what the major needs are. What are the things we’re trying to achieve? What are the metrics we’re looking at? Those are the people who are going to have the best insights and positioning to make prioritization decisions, to make tradeoff choices… So, if we think about it from the State Officer perspective, these are the people you are in contact with regularly. These are the people that CMS is communicating with, the people that are signing the APDs, and funding letters. Those are the people who should be making decisions, and often they are in a very abstract way, but then they’re handing off, and it’s not travelling all the way down to their direct reports, and the people reporting to the people the next layer down. What you want to see is 100% ownership at that state Medicaid director level, and that it continues down, and at the bottom you’re not getting to less than 50% ownership on the program side. Again, the IT folks don’t know the mission, and they don’t know the intricacies of Medicaid. Ultimately, you want to see that technology isn’t this separate, added on thing. It’s just another piece of how you get your work done. That’s a little bit difficult in the government world of today, because it’s not a skill set that we’ve encouraged people to pursue, and in fact we actively discourage people who are non-technical from developing more fluency in technology. But we need to shift to a world where we think about technology more like writing. Like, Princess, you yourself are significantly better at writing than I am, and that’s OK, but… I can still write some words. I can write something, and send it to you to fix, for example. So, my inability to write at your level of skill and quality doesn’t hold me back from doing my work, and you want to see a similar thing with technology. Ideally, everyone who needs to do something understands enough about technology that they’re not blocked from doing their job, and that’s the world that we haven’t yet gotten to. In today’s world, we see people blocked by their inability to do things with technology. They can use something that someone else has built, but they don’t know how to build something themselves, they don’t know how to sequence it out, they’re not confident making a judgement call as to whether something is “good” or not.
Princess	8m35s	As a follow-up to that, I’m wondering if people are hesitant to fully step into this product ownership role that is needed, because they’re afraid that they don’t know enough about technology, even though—as you said—they don’t need to know everything, they just need to know enough to make some of these decisions. It’s just a skill that you need to have in that space.
Nikki	9m02s	Yeah. I think that one of the biggest things that we often don’t do is just ask the technologists to explain things to us in words that we understand. So, if there’s one thing that I would tell everyone to do tomorrow—-everyone on the program side—-hold your technologists, most of whom you’ve hired directly and given a lot of money to, hold them accountable for talking to you in plain language in terms that you understand. And if you don’t understand what they’re saying, ask them again, or say “I didn’t understand that, can you explain it in a different way?” I promise, no matter how un-technical you feel, there’s a level that someone can explain it to you that you will understand, and you will understand the decision that needs to be made, you will understand the tradeoffs and the pros and cons of what each of those are, and that means that you can actively participate in choosing the path forward, which is often the thing that is not happening today. Technologists will be faced with a decision, and they’ll be able to choose Path A, B, or C, and because they are not talking to the program staff, they make that decision on their own! In reality, they should be talking to the program staff, because… maybe the technologist thinks “Option A” is the best option, but it turns out that paints you into a corner a year down the road, or it comes into conflict with policy requirements, or it makes doing something critical really hard. If you don’t have program staff in the room, you’re never going to do a good job of identifying what those “unforeseen consequences” of your decisions are.
Princess	10m45s	I love that. It sounds like there is some… ideal state we can get to, or as close to it as we can. Can you talk more what that would look like, where you have the IT staff, the policy people, the product owner, and the developers all working together… what would that look like in a state?
Nikki	11m13s	So, the pipe dream is that there’s enough fluency and comfort and confidence in the program office that folks closest to the mission are the ones who are really able to lead the projects, and people from other disciplines and areas of expertise are supporting them. They’re bringing them information, and they’re going back and executing inside their areas of expertise, but they’re not the ones making the decisions about what they should be doing today, what we should be doing tomorrow, what outcomes the system needs to create for humans. All of that should be owned by the program folks. It’s the same as with your contracting offices. Your contracting office should help you make decisions about how to structure your contracts, help you execute on them, select good vendors… but, in most places, you would never tolerate your contracting office telling you that the thing you’re trying to procure a vendor to do is the wrong thing. They don’t know what your program needs are. Similarly, with technology, except we too often let the technologists tell us that we’re wrong.
Princess	12m31s	That’s a great analogy. It’s just… we’ve elevated them to this expert status, and they don’t have the perspectives to set strategy in this way. So, we’ve talked about the ideal state. Is there a more “realistic” state, where something could (by this row in the rubric) could still be in the “green,” but is a bit more like something is achievable?
Nikki	13m06s	That’s fair. I think a “green” state that we can achieve today is having people act in teams and in pairs. In particular, pairing up someone who is a program expert with someone who is deeply fluent in technology, and knows how to deliver on a software development project. You can combine those two people as a team, they have 50/50 ownership, and they can support each other. You can see them together making those decisions and making those tradeoffs, because then your person who has more technical fluency can translate things coming from your tech contributors, and the person with more of the program fluency can be doing the other way around: here’s what’s coming from policy, and from leadership, and together making decisions. “What should our strategy be?” “What should our roadmap look like?” “Are we on track? Are we going too fast? Too slow?” And, as always happens when you’re delivering around a particular deadline, what should we cut from this, and what features can we remove without breaking the core of what is essential about this, and what features can we absolutely never remove? Through the power of teamwork, you can achieve this, but you have really healthy, functional collaboration with mutual respect.
Princess	14m30s	I’m curious about… so, that’s the green situation. What about a yellow situation, or maybe a red? What do those look like, and how can state officers identify those?
Nikki	14m47s	Red is easy. Red is a program is barely involved in software development. Yellow is a bit trickier. In yellow, what you often see is that you’re staff—your program staff from your human services organization—the trick is, in a yellow situation, they’re usually on the team as SMEs. They provide input and feedback, but don’t drive decisions, and don’t drive making tradeoffs. They’re at the table in conversations, but they’re treated more like research subjects, than decision makers, and they don’t usually have the authority to say “This project is going in the wrong direction.” Or, “we need to prioritize this thing over that thing.” Sometimes, it’s explicit, like where you can accidentally outsource to an outside PMO. But, sometimes it also looks like them being nominally in charge, but when they raise up what they think is important, the team talks them down, or says “No! You’re wrong!,” or “You don’t understand, because the technology can’t do that.” And while that’s valid feedback, what you want to see from the teams is a “get to yes” attitude. If you’re not seeing that “get to yes” attitude, and you’re not seeing program staff feeling like they’re the ones who understand what we’re doing today, what we’re doing tomorrow, and what we’re doing in a month from now… and they’re not the ones making the decisions… then you’re definitely in a “yellow” situation.
Princess	16m22s	It seems like it’s also a question of team health, as well as people in the roles that work to drive strategy. It seems like a lot of situation might be “yellow,” and it seems like it might be a little harder to get to the realistic “green” state. I’m wondering, what state officers can do to help a project get closer to the green state if it is in the “yellow,” or unfortunately in the “red.” What things can they do to nudge things closer to the “realistic green state,” or the “ideal green state,” even?
Nikki	17m05s	The first thing that State Officers can do is really hold the people you’re talking to accountable for understanding the “why” and the “what” of every technology project. Then, hold them accountable to really being the drivers on that. Whose making the strategic decisions? Whose making the tradeoffs? Are they informing the technologist and the technologists are making the decisions, or are they asking the technologists to advise them, and ultimately they’re the ones making the decisions? So, push them to be in that leadership role, and to really take hold of their destiny and their strategy (especially). That’s the first one. The next thing that I’d say is that, as State Officers, you have the ability to encourage the states that you work with to do certain things. For example, you can encourage them to help their program staff learn more about technology, and become more familiar with technology. There are classes that people can take, there are trainings that people can take, there are small, low-risk projects you can do to learn more… these are all things that you can remind them about and say “Hey! This is arguably part of DDI!,” or that this is helping develop a solution. And the third thing, you can suggest to them that they develop more of a digital services team. At the very minimum, you want to see more project and product management embedded within your organization. But, also, can you have software developers inside the program office. Sometimes it’s a little tricky because of how state politics play out, but wherever possible, encourage that. State politics are the problems of the state. At the end of the day, CMS is providing most of the money here, especially if you’re in a DDI situation, you’re providing the lion’s share of the money. I think it’s totally reasonable for CMS to say “Hey! We feel a lot better when this money is going to fund staff inside of your program division who have technical expertise!” as opposed to a state-level IT shop, or a vendor. Arguably, again, DDI can provide funding for that as well. If you’re hiring a software developer, for example, and they are working entirely on Medicaid IT systems… why wouldn’t that be DDI?
Princess	19m35s	Great! Yes. I think that it’s good to know there’s funding avaiable, or that is a way to nudge them towards that. To remind them that “hey, you can use this to get closer to this end.” I’m curious about your #2 point: investing in helping program staff learn about technology. Is that something they could also nudge with funding? Like, maybe we could use this to pay for a training?
Nikki	20m08s	I’m no expert on the regs, but I think that’s something that should be supported in regs, because that leads us to a future where the government does a better job of owning solutions, and ultimately, we’re able to more efficiently deliver high-quality solutions to the public. Having your own in-house team that deeply understands your mission, deeply understands the existing system, and can just carry it forward… it costs money in the short term, but it is more cost effective than outsourcing to vendors.
Princess	20m41s	Building that long-term strategy, and making sure technology is a sustainable part of work, and the team, is something that seems really important. I’m wondering if you have any closing thoughts for State Officers as they’re navigating this row of the rubric and talking with their states.
Nikki	21m04s	I think the important thing to remember is that as a State Officer, you’re in such a powerful advisory position to help your states get unblocked. A lot of states are not super-comfortable navigating technology, and they don’t necessarily know how to get out of the situation they’re in, and into a better future. You are a huge of part of that, and you can be a huge force in helping them modernize. You don’t have to just tell them about the regs, you can help them figure out better ways to structure their technology projects.
Princess	21m44s	I think that’s a good closing. I love that.
Nikki	21m48s	You have the power!
Princess	21m50s	Yes! You are helping them guide their strategy-setting process and you’re empowering them. That should feel good.
Nikki	22m07s	And, it’s not just… in this new world, the job of a State Officer isn’t just about navigating regs. It’s about helping technology projects be successful.
Princess	22m19s	Yes. Definitely. I think that’s a wrap. Thank you so much, Nikki, and I hope every State Officer finds this super helpful.
Nikki	22m33s	I also hope they find it helpful!
Princess	22m37s	(Laughter) I don’t know if that was a good closing, but that’s what we’re going with!

Meet with your small group and connect what you learned in this lesson to situations you’ve seen with your state projects. Consult the notes you took throughout the lesson and try to link them to a story that you can tell about a particular project. It’s probably useful to do some brainstorming on this before you meet with your small group to trade stories.

When you get together with your small group:

Share your stories with each other.
Figure out which ones are the best candidates for a case study or use case that would be helpful to share with other state officers.
As a group, choose useful stories and write notes on how they link up with the concepts shared.
- Include in your notes:
  - When did this story take place?
  - What were the events or background leading up to this story?
  - How did this story demonstrate an ideal or non-ideal situation?
  - What specific principles from the lesson does this story illustrate?
  - If the story shows an ideal, what were the conditions that made it work? How did it fit with the principles shared in the lesson?
  - If the story shows a non-ideal, what could have changed to make it better?
Share these notes with the larger group when you meet.
After discussion with the larger group, document these stories and their connections to the lesson to help other state officers understand how this lesson’s concepts apply to their work.

Discuss in community (1h, group)

You will need someone to volunteer to take some notes. Whomever was born after (but closest to) January 20th should be the note taker today.

Check in. (5m timer) While people are arriving, check in with each-other. How is everyone doing? Take a moment to share something positive from the week, either at work or at home.
Centering. (3m timer) We jump from meeting-to-meeting and there’s nothing healthy about that. You will get more from the next hour if you’re here. A simple breathing exercise (breathe in on 4, hold 4, exhale 4, hold 4) is a good way to clear your mind and body. There’s lots of resources online (4m20s) regarding simple centering exercises that you could investigate and use at the start of group conversation.
Focus. (1m timer) Take one minute to identify one or two insights this conversation led you to. Make a note or two in your notebook so you can be focused when you share out.
States and vendors. (30m timer) As a group, first share out which aspects of the conversation you found to be most interesting in your reflections. Then, after you share out which dimensions of vendor management inspired reflection on your professional practice, go back around and take a minute or two each (round-robin) to share why those ideas triggered insight. This should take roughly 30 minutes total, and try and create space for everyone to share out.
Transformation. (15m timer) Were there themes that you saw emerge from your insights? Commonalities across projects? Identify what you saw as a group. Then (and more importantly), do you have any thoughts about your process with states, and how you might transform your process so as to improve outcomes? The note taker should try and capture the group’s thoughts regarding themes and process transformation for sharing back out to the group/community.

In the guides

This lesson is the beginning of a journey. If you're interested in learning more, there's material in the 18F Derisking Guide that you'll want to check out.

From the Federal Field Guide:

From the State Software Budgeting Handbook: