Overview

The Launchpad is the foundation of our System Development Life Cycle for Major IT Development Projects (MITDPs). Stage 1 sets that foundation with some of the basic tenets for why the State of Maryland should invest in your MITDP.

Stage 1 consists of three sections, with a total of four required worksheets. All four worksheets must be submitted in full for your Stage 1 submission to be accepted.

State of Maryland employees with access to Google Docs can access all four worksheets in this Google document. Individual links to each worksheet are also available in the guidance for each section, as well as a link to download a version of the worksheet in the Microsoft Word .doc format.

For an example of an approved submission of Stage 1 of Launchpad, see this document. (Note that this link is only accessible for State of Maryland employees.)

Understanding of User Needs

In order to complete this section, your team will need to talk directly to users, including state employees, members of the public, and individuals who are part of other groups that are impacted by your program. Based on these conversations, you will develop primary user groups that will be used throughout the life of your MITDP to identify core problems, recruit participants for usability testing, and prioritize features across iterations of the product.

Guidance for completing this section:

For this section of the Launchpad, you will need to provide two assets:

1. A summary of the research that you’ve conducted directly with users

2. Overviews for each Primary User Group including the problems they face

Conducting interviews directly with representative users

In order to complete this section, you will need to conduct interviews directly with representative users from each of your primary user groups, with a minimum of nine (9) interviews overall. This is required as a foundational step toward the needs and perspectives of your users, which helps you define your Core Problems in the next section. For most projects, you’ll want to interview more than nine users, which is encouraged.

Your team may have also conducted other forms of research, such as surveys or focus groups. These can be complementary to the user interviews that are required as part of your MITDP Launchpad.

User Research Summary

Your User Research Summary is an overview of how you’ve conducted your research interviews with representative users to help understand the problems you’re looking to solve. It documents high-level information about each of your user groups, how you recruited and selected representative users, the specific interview guide(s) used for interviews, and the dates, durations, and interview notes from each of the interviews you conducted.

If you have already hired a UX Lead for your MITDP, it can be reasonable for that individual to lead your user research efforts. In the case that you have not yet filled the UX Lead role, you may need to hire a user research team to support this area of your Launchpad. Feel free to reach out to our MITDP Oversight Division for guidance on how to do so.

An example may help:

Imagine that you are researching users involved in construction management. Consider the following prompts in your user interviews:

1. What is your role in construction project management? Why does this role exist?
2. How would you define success in this role? What needs to be true at the end of each month or year for your role to have been successful?
3. [for some of the key aspects that they’ve listed as part of their role] Walk me through how that works with your current system (Note that ideally the session is conducted on-site and in-person, allowing the interviewer to directly observe the participant using their existing tools and processes)
4. What are the biggest blockers or challenges that prevent you from being successful?
5. [for each blocker or challenge] Walk me through how that works step-by-step (again, this is ideally conducted on-site and/or in a way that allows for direct observation of current behaviors with existing tools and processes)
6. What are the biggest enablers that currently exist and help you in being successful?
7. What worries you most in your current role?
8. If you could change one thing about how this work is managed, what would you change?

Note, importantly, that these questions are somewhat subjective, which is why we require that user research is conducted with only one participant at a time. In a group setting, the answers to any of these could be affected by the existence of a person’s peers, manager, or direct reports in the conversation, which can influence them to answer in a different way based on what they think would be best for that other person to hear.

Meeting 1-on-1 with individuals also provides a more natural lens toward observing real-world behaviors, such as by asking the interview participant to walk through how something works in their day-to-day working environment and observing how they work with current processes, systems, and tools. This is where your research plan can include elements of participant observation and contextual inquiry.

If you have already hired a UX Lead for your MITDP, it can be reasonable for that individual to lead your user research efforts. In the case that you have not yet filled the UX Lead role, you may need to hire a user research team to support this area of your Launchpad. Feel free to reach out to our MITDP Oversight Division for guidance on how to do so.

Primary User Groups

Building on your interviews with users, you’ll identify Primary User Groups (this is likely 2-5 groups). For each primary user group, fill out a section of the worksheet to document the group’s primary needs, pain points, opportunities, technology needs, and a journey map of key touchpoints.

An example may help:

Imagine you are part of a software development team researching the experiences of environmental consultants, who work on behalf of businesses in the state, and who need to maintain their professional licences with the state so that they can continue to serve the business community. As you research them, you discover the following needs they have as professionals, along with a number of pain points they have in accomplishing those need:

Primary User Group: Licensed Environmental Professionals

#	Primary User Needs (use provided format and limit to 5)
1	A way to submit necessary forms and materials to obtain or renew my professional license so that I can continue to work in my field.
2	A way to pay any fees associated with my license and receive proof of payment so that I can prove to my clients that my license is up to date.
3	A way to find the correct, up-to-date license forms and requirements so that I can fill out the application correctly, along with all required supporting documentation.
4	A way to get timely notification about renewals so that I can manage my licenses and not have to miss work.

#	Pain points / Barriers (no limit, include at least 3)
1	Currently, I have to submit information to the state through the mail, which adds unnecessary delays to the timeline and doesn’t give me confidence my materials have even been received, much less processed.
2	Having to pay through a physical check can add an additional 3-4 days to request the check if going through a central office. It then adds 1-2 weeks to the processing time because it goes through the state’s fiscal team before the program receives my application.
3	The state is often asking for information or documentation that it already has. Collecting that documentation can sometimes be time intensive or just repetitive.

Notice that the user-needs in this example speak to things that this user group needs (a way to apply/renew for a license, a way to pay, a way to find up-to-date requirements, a way to get renewal notifications) in order to achieve an outcome (securing or maintaining their status as a licensed professional). These needs and outcomes are independent of the current way the state serves these professionals today. The pain points then speak to the challenges this user group has in achieving these outcomes that stem from the specific solution the state has in place today. To reiterate: user needs are independent of the current solutions; pain points are specific to the current solution.

If you find yourself with way too many user groups, you likely need to reduce the scope of the problem you’re trying to solve right now. Who are the biggest user groups? Who are the most impacted user groups? Can you start with them?

If you find yourself with way too many user needs or challenges, you likely need to make your user groups more granular and / or reduce the scope of the problem you’re trying to solve right now.

For additional guidance on conducting user research, see our MITDP Guide for Ethical, Inclusive, and Effective User Research

Required worksheets

For this section, you are required to use the following worksheets:

Worksheet	Link	Download
User Research Summary worksheet	Google Document	Word Document
Primary User Groups worksheet	Google Document	Word Document

Acceptance criteria

We will evaluate the materials you provide based on the following criteria:

#	Criterion	How we’ll assess this
1	User Research Summary and Primary User Groups are submitted using required worksheets	We’ll review your submission to ensure that it uses the required worksheets
2	User groups have been identified that represent all relevant user types	We’ll review your list of user groups to ensure that relevant groupings are included
3	Research plan provides estimates of the number of potential users in each user group	We’ll check whether estimates are present, including the data sources used
4	Interviews have been conducted with at least nine (9) individual users	We’ll check to ensure that your team has conducted interviews with at least nine (9) individual users Note: User participation in Focus Groups does not meet this requirement
5	Participants of user research interviews adequately represent all primary user groups	We’ll cross-reference your list of interview participants with your list of primary user groups to ensure that you’ve conducted interviews with a sufficient number of individuals in each user group. We’re generally looking for at least three (3) participants per Primary User Group. Note: User participation in Focus Groups does not meet this requirement
6	Interview guide is included in Research Report and is in alignment with MITDP user research guidelines	We’ll review your interview guide(s) to ensure alignment with the MITDP Guidelines for Ethical, Accessible, and Effective User Research
7	Synthesis has been conducted to develop insights from user research	We'll review the screenshots or other deliverables included from your synthesis process to observe how your team went from raw data to polished insights
8	Primary User Groups have been identified	We’ll review your Primary User Groups to ensure that significant user groups have been included
9	All sections for each Primary User Group are completed, and align with other research findings	We’ll review your Primary User Groups to ensure that all sections are completed and findings are in alignment with existing research deliverables

Recommended resources

These resources can help you complete this section:

Resource	Link
MITDP Guide for Ethical, Accessible, and Effective User Research	Webpage

---

Core Problems & Definition of Success

Together, the core problems your project is intended to solve and your definition of success will become the baseline scope for your MITDP. Once approved, MITDP funds can be spent on any work the team deems necessary to solve your core problems and achieve your definition of success.

Guidance for completing this step

You’ll start by prioritizing the core problems that your MITDP intends to solve. Then, for each core problem, you’ll identify a definition of success — i.e., the things that must be true for the problem to be considered solved. Lastly, you’ll define success metrics for each definition of success — i.e., what metrics would quantitatively “prove” that you have achieved your definition of success?

While these prompts may seem simple, this information is worth spending time on as it defines the scope of your MITDP and limits what you can spend MITDP funding on. Future changes to this scope require review and approval by DoIT as well as notification to the legislature. Your project’s performance will be measured against the information you provide here, and your progress will be reported publicly.

Core Problems

All agencies use software, and software is never perfect. There are always problems. But what makes a problem a “core” problem?

• A core problem connects a software problem to user pain-points and undesired outcomes in a way that avoids the “so what?” objection.

For example, it's not enough to say "our software is out of date" So what? What consequence does "out of date software" have — for the agency, for the state, for Marylanders?

Similarly, it's not enough to say "our spend too much time copying information between multiple disconnected systems". Again – so what? What consequence does this pain point for your users have — for the agency, for the state, for Marylanders?

For a core problem statement to be convincing, you need to make plain what undesired outcome your problem or pain point leads to. Therefore, any good core problem should explicitly frame the negative impact that Maryland residents experience because of this core problem.

Here's an example of a good core problem statement:

• Core Problem: Disconnected Systems Cause Administrative Burden for Case Workers Leading to Missed Casework Deadlines.
  • Software deficiency: Our software systems are disconnected, thus requiring essential information about juveniles in the system to be manually duplicated between multiple systems.
  • Pain Point: Because of this, case workers spend several hours each day reentering information into multiple systems, taking valuable time away from helping youth achieve their goals.
  • Undesired outcome: This, in turn, leads caseworkers to regularly miss their required casework activity due dates.

---

Why is this a good core problem statement? It connects a 1) gap or deficiency in technology to 2) pain points for users to 3) undesired outcomes. It's unlikely that anyone would ask "so what?" after reading this core problem statement. By connecting gaps to pains to undesired outcomes, you effectively avoid the "so what?" objection.

Note that a software deficiency may lead to many undesired outcomes. The question then becomes: which undesired outcome or outcomes do you single out in your core problem statement? This is challenging. On the one hand, you want to pick an undesired outcome that seems genuinely compelling — such that, if you solve for it, Marylanders will easily see the value of your work. However, you want to make sure you pick an undesired outcome that you can confidently measure. If you pick an undesired outcome that is not only caused by the software deficiency in your core problem, but by many other causes that you have no control over, then you may struggle to measure what impact your solution has on it.

For example, in the above core problem statement, an example of a too-high-level undesired outcome might be "recidivism". Since the software deficiency reduces face time between case workers and their clients, it is conceivable that the software deficiency contributes to elevated rates of recidivism. But recidivism is influenced by many other factors as well — social, economic, political, etc. — most of which you have no control over. Thus, you may struggle to ever truly measure what kind of impact you have on recidivism. That's why "caseworkers regularly missing their required due dates" is a better undesired outcome to single out in this core problem statement. If you have user research that plainly connects deficiencies in the software to caseworkers missing their due dates, then it's likely that you can definitely measure whether or not your eventual solution is eliminating this undesired outcome.

Definition of Success

For each core problem, you need to write a corresponding definition of success. A definition of success answers the question: What must be true for this core problem to be considered solved?

But what makes a good definition of success? A good definition of success defines a desired outcome that's clearly connected to the core problem statement and yet completely independent of what the eventual solution might be. (That will be explored in your Product Strategy worksheet and in your Implementation Strategy during Launchpad Stage 2).

Continuing the core problem example in the previous section, here's what that could look like:

• Definition of Success: The following must be true for this core problem to be considered solved:
  • Case workers report being able to spend the time they truly need with their juvenile clients in order to help them reform their lives away from crime.
  • Caseworkers are able to regularly meet their required casework activity due dates.

What makes this a good definition of success? It focuses on the things that must be true in order to state that the problem has been solved – without defining the solution.

This is an essential point – a definition of success does not define the specific solution, but rather defines the positive outcomes that must be achieved in order to know that the problem was solved. It leaves the "solution" open. This is essential. Don't bake the solution into your definition of success. The "solution" will be decided on later, through product strategy (and implementation strategy) – after all core problems, definitions of success, and success metrics have been defined. There are typically many different ways to solve a core problem – and each of those different approaches will have pros and cons. Leaving the solution open at this stage gives you the freedom to find a product and implementation strategy that will work best for you, your users, and the State, in light of all of your core problems, and in consideration of all of your constraints.

Note also that this definition of success explicitly frames the positive impact that will be experienced by achieving this definition of success.

---

Success Metrics

Now that you have a definition of success, you need success metrics to go along with it.

A success metric is a quantitative metric that tells you whether or not you are getting to your definition of success. Think of it as the quantitative equivalent of your qualitative definition of success.

How many success metrics do you need? That depends on the definition of success. The more dimensions to your definition of success, the more success metrics you are likely to need. Your success metrics should be holistic – i.e., they should cover your entire definition of success.

That being said, we don't need every single metric you intend to track. When it comes to defining success metrics, you should aim for "just enough" success metrics. What are the minimum number of success metrics necessary to feel that you could quantitatively "prove" you have achieved your definition of success in its entirety. In other words, you should have a minimally holistic set of success metrics for each definition of success / core problem statement.

Note — whenever possible, appropriate success metrics should not be binary (e.g., "we didn't have a case management system before and now we do"). Instead, they should be a range. A range allows you to evaluate what progress you are (or aren't) making over time, thus allowing you to make more informed decisions as you proceed.

Continuing the example above, that could look like:

#	Description of metric	Current value	Target value	Source of current value
1	Percentage of case workers reporting that they are able to spend the time they truly need with their juvenile clients in order to help them reform their lives away from crime.	5%	>= 95%	Quarterly Case Worker Satisfaction Survey (link)
2	Percentage of casework activities completed by their original due dates.	50%	90%	DJS Case Work Activity Log (link)

Again — note that these success metrics form a more or less quantitative mirror image of the definition of success. Tracking only one of these wouldn't be enough to know if we've achieved our entire definition of success — we have to track both.

If having three core problems doesn't feel like enough, you may need to reduce the scope of what you're trying to solve right now and / or prioritize. What are the biggest problems, either in terms of impact or number of people impacted? What problems, if left unsolved, creates the greatest risk of future, bigger problems? The state cannot solve all its problems at once, so pick the most impactful one(s) to start with.

If you have questions or are experiencing any challenges with this step, reach out to our MITDP Oversight Division and we'll be happy to help.

Required worksheets

For this section, you are required to use the following worksheet:

Worksheet	Link	Download
Core Problems & Definition of Success worksheet	Google Document	Word Document

Acceptance criteria

We will evaluate the materials you provide based on the following criteria:

#	Criterion	How we’ll assess this
1	Worksheet is completed using required format	We’ll review your submission to ensure that it uses the required worksheet
2	Worksheet includes up to three (3) core problems using provided format	We’ll review your core problems to ensure that they are structured using the provided format, including its undesired outcome, its desired outcome, and a description of where or how it is occurring
3	For each core problem, success is described in a way that is clear, achievable, and independently verifiable	We’ll review your response to the “Definition of Success” section for each core problem to ensure that it’s described in a way that is measurable and achievable
4	For each core problem, three (3) impacts of success for the people of Maryland are listed	We’ll review your responses to the “Impacts of Success” section for each core problem to ensure that three (3) impacts are listed that provide value for the people of Maryland
5	For each core problem, a set of success metrics are provided, each with current values, target values, and current value sources	We’ll review your responses to the “Success Metrics” section to ensure that you have provided a minimally holistic set of success metrics such that, if all of the success metrics achieved their target values, it would provide strong objective evidence that you have achieved your definition of success in its entirety. We will also ensure that, for each metric, you have provided a current value and a target value. We will also ensure that you have provided information about the sources of the current value, and whether or not your team is able to access those sources on an ongoing basis.

---

Product Strategy

In doing service delivery, you are creating an enduring capability for your users. In other words, you are creating a product. But what kind of product? There may be many different paths to serving your users. Which path will you take? That is ultimately a question of strategy.

An example may help:

Imagine that you are starting a business aimed at pet owners who have animals with grooming needs. Based on what you learned about your customers, and about the pets that they have, you may explore a few strategically different visions for your business:

1. You might decide to start a traditional grooming service. You open a business in a physical location, you advertise in your community, and you serve your customers, and their pets, by grooming their pets right there in your shop.
2. Alternatively, you might decide to start a mobile grooming business --- i.e., you purchase large vans, equipped with grooming equipment and supplies, that you then drive to your customers homes, so that you can groom their pets right there in the van, while parked in their driveway.
3. As a third alternative, you might decide to start a "grooming training" service -- where you train customers how to groom pets themselves, instead of grooming the pets for them.

These are ideas that you might have developed directly from your user research; which path you decide to move down is a strategic decision about your product service delivery.

Guidance for completing this step

You will consider all that you have learned as a team — about your users, about the problems you intend to solve, and about the definitions and measures of success that you have identified. You will then brainstorm different ways of going about getting to your definition of success — in other words, different product strategies. You may, along the way, even want to run a couple of product experiments, to better understand the pros and cons of the different strategies. After weighing the evidence, you will then choose a particular product strategy. This is your product vision.

Required worksheets

For this section, you are required to use the following worksheet:

Worksheet	Link	Download
Product Strategy worksheet	Google Document	Word Document

Acceptance criteria

We will evaluate the materials you provide based on the following criteria:

#	Criterion	How we’ll assess this
1	Worksheet is completed using required format	We’ll review your submission to ensure that it uses the required worksheet
2	Worksheet contains a clearly articulated, high-level product strategy	We’ll review your submission to ensure that the product strategy chosen is clear, while high-level
3	Worksheet contains other product strategies that you considered but ultimately rejected, along with your reasons for doing so	We’ll review your submission to ensure that it includes rejected product strategies, as well as your justifications for rejecting them.
4	Worksheet contains links to artifacts that you and your team used to work out your product strategy	We’ll review your submission to ensure that it contains links to various working artifacts that show how you and your team went about determining your product strategy

Completing Stage 1

For information about submitting Stage 1 of your Launchpad, see How To Submit.

Go to Launchpad Stage 2 Go to Launchpad Overview