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, and Stage 2 gets into the details of how your team will deliver on our investment.

Stage 2 consists of 6 sections, including 7 required worksheets. All required worksheets must be submitted in full for your submission to be accepted.

State of Maryland employees with access to Google Docs can access all of the worksheets for Stage 2 in this Google document. Individual links to each worksheet are also available in the guidance for each section.

State of Maryland employees can also see this example of an accepted Launchpad to understand what we're looking for with Stage 1.

Implementation Strategy

Your implementation strategy tells us how you are planning to approach solving your core problems and achieving your definition of success. Crucially, this is NOT a project plan. Instead, your implementation strategy is based on the assumption that there are many things you do not yet know about how the project will go. It is intended to give us confidence that you have a strategy for minimizing risk, resolving uncertainty, learning as you go, and delivering quickly and cheaply. Instead of asking for a plan, we ask for:

1. A description of your potential solution paths, including system, data, and architecture considerations

2. Your current thinking around how to break the project down into smaller segments of work, how you will prioritize or sequence them, and how you will know if you’re delivering value throughout each segment

3. A list of significant unknowns and open questions, how you will collect the data necessary to answer them, and key decision points, with particular attention to forks in the road where the project might change based on what you’ve learned

4. A plan for what you will deliver during your 90-day build

Your implementation strategy can and will change as the project moves forward.

Guidance for completing this step

To complete this section of the Launchpad, you will start by completing the Technology Options worksheet, which includes a question on whether you’re confident on what technology options to use for your project.

In the case that you’re already confident about which technology will be best, you’ll need to fill out the Implementation Strategy worksheet, which is described below.

But it’s ok if you aren’t confident about this yet! In the case it would be helpful to evaluate options for what technology might be best, you can fill out the Alpha Testing Strategy worksheet instead. This will help you scope an “Alpha Phase” for your project, during which you’ll be able to test and evaluate technology options to get a better understanding of what might work best to solve your Core Problems and address your user needs.

At the end of your Alpha phase, you’ll still need to complete the other steps, including filling the Implementation Strategy worksheet and completing a 90-Day Build, but these steps will hopefully be much easier after testing your preferred solution with real-world use cases.

Optional step: Starting with an Alpha phase

If your team thinks it would be helpful to start with evaluating options for what technology might be best, you’ll fill out the Alpha Testing Strategy worksheet. This worksheet has two parts:

1. Scope & Evaluation considerations

2. Development & Testing Strategy

Scope & Evaluation Considerations

Provide answers to these questions about what functionality you’ll look to test with your Alpha prototypes, how you’ll assess whether a given solution is successful, and what types of resources and duration you’ll need to be confident in planning an implementation strategy with a more specific solution. We encourage you to be candid about trade-offs, potential concerns, and open questions, as this will demonstrate your thoughtfulness and attention to the risks and opportunities that exist across different approaches. We do not expect you to have all the answers right now.

Development & Testing Strategy

Provide a description, in 1000 words or less, of how you plan to go from the current state to being able to recommend options for implementation. This helps us understand what you would do if your Alpha phase was funded tomorrow and how you’re planning to approach the inherent unknowns in testing potential solutions. Note that this can and will change throughout the project. This summary is intended to give us your current thinking.

Please include descriptions of:

• How you are breaking the effort down into smaller segments of work, how you will prioritize or sequence them, and how you will know if you’re on track to recommend a specific approach for your MITDP

• Significant unknowns and open questions, and how you will collect the data necessary to answer them

• Significant decision points, with particular attention to forks in the road where you might change direction based on what you’ve learned

• The staffing that you’ll need to complete the different areas of work

Required step: Documenting your Implementation Strategy

If your team is confident about which technology will be best for your MITDP, you’ll fill out the Implementation Strategy worksheet. This worksheet has three parts:

1. Delivery Strategy

2. Systems & Architecture Considerations

3. Plan for 90-Day Build

Systems & Architecture Considerations

Provide answers to these questions based on what you have learned through discovery and planning. We encourage you to be candid about trade-offs, potential concerns, and open questions, as this will demonstrate your thoughtfulness and attention to the risks and opportunities that exist across different approaches. We do not expect you to have all the answers right now.

Delivery Strategy

Provide a description, in 1000 words or less, of how you plan to go from the current state to the desired state. The purpose of this is for us to understand what you would do if the project was funded tomorrow and how you’re planning to approach the inherent unknowns in any system implementation. Note that this can and will change throughout the project. This summary is intended to give us your current thinking.

Please include descriptions of:

• How you are breaking the project down into smaller segments of work, how you will prioritize or sequence them, and how you will know if you’re delivering value throughout each segment, including demonstrating working software within 90 days

• Significant unknowns and open questions, and how you will collect the data necessary to answer them

• Significant decision points, with particular attention to forks in the road where the project might change based on what you’ve learned

• How the staffing of your project will change at different stages or milestones

Plan for 90-Day Build

As a new MITDP, you are required to demonstrate working software within your first 90 days of delivery*. This requirement helps ensure that all MITDP teams have the necessary skills and resources to succeed, provides early indicators in cases where there are challenges that need to be addressed, and encourages teams to start small and work iteratively.

It’s important to note that the output of your “90 Day Build” does not need to include all of the possible features or functionality of your MITDP. Far from it! It should include working software showing how the software will be able to approach one or two of the features that you prioritized for the project.

Your answers to these questions help us understand the scope of functionality that you’re planning to include in your 90-Day Build, your Definition of Ready—which is how we’ll know when you’re able to start the work of software development and your 90-day countdown will begin—and your demonstration environment, which is how we’ll be able to access your working software and its underlying code. At the end of your first 90 days, we will have a review meeting to see what the team has delivered, and what it plans to deliver next. The purpose of this is to view and evaluate working software. Screenshots or slide decks will not be accepted.

*Delivery begins when the “Definition of Ready” below is met, NOT at the point of MITDP determination. If sufficient time has passed between determination and the beginning of delivery, we will revisit the 90-Day Build details below and make changes if desired.
‘

Required worksheets

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

Worksheet	Link	Notes
Technology Options Worksheet	Technology Options Worksheet	This worksheet is required for all projects
Optional: Alpha Strategy Worksheet	Alpha Strategy Worksheet	Fill out this worksheet if it would be helpful to conduct an Alpha phase to evaluate options for what technology might be best
Implementation Strategy Worksheet	Implementation Strategy Worksheet	Fill out this worksheet if your team is already confident about which technology will be best

Acceptance criteria

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

#	Criterion	How we’ll assess this
1	Worksheets are completed using required format	We’ll review your submission to ensure that it uses the required worksheets shared in the section above
2	Responses to items 1, 2, and 3 of the Technology Options worksheet demonstrate a thorough review of the competitive landscape, including detailed analysis of the viability of existing options	We’ll review your response to items 0.1, 0.2, and 0.3 with service delivery teams in other states to ensure a thorough understanding of potential solutions

Criteria that apply to the Alpha Strategy worksheet** *(these do not apply if you are submitting an Implementation Strategy)

#	Criterion	How we’ll assess this
3	Response to item 1.1 includes a reasonable and achievable amount of functionality for testing, including a strategic on focus on key functionality that will help determine the best possible solution	We’ll review your response to item 1.1 to ensure that it includes a reasonable and achievable amount of functionality that will directly support your ability to evaluate technology options, in addition to your notes on trade-offs, potential concerns, and open questions Note: Building on your notes for trade-offs, concerns, and open questions, these details can continue to iterate over the course of the approval process. The scope for your Alpha phase will not be finalized until the project is formally approved as an MITDP
4	Response to item 1.2 includes reasonable and achievable plans for assessing whether prototypes are successful	We’ll review your response to item 1.2 to ensure that your team has identified effective methods for evaluating Alpha prototypes
5	Response to item 1.3 includes relevant requirements for conducting an Alpha phase, including contracts, staffing, system access, and/or operational needs	We’ll review your response to item 1.3 to ensure that all likely requirements are included so that your team can successfully evaluate options
6	Response to item 1.4 provides a reasonable and achievable amount of time for completing the Alpha phase, including detail on the expected durations for different categories of work	We’ll review your response to item 1.4 to ensure that it includes a reasonable estimate of time based on the categories included and the durations estimated for each category

Criteria that apply to the Implementation Strategy worksheet (these do not apply if you are submitting an Alpha Strategy)

#	Criterion	How we’ll assess this
7	Response to item 1.0 is no more than 1000 words	We’ll review your response to item 1.0 to ensure that it is no more than 1000 words
8	Response to item 1.0 includes a plan for user-centered, iterative development and testing, including a breakdown of the work into achievable segments with processes for testing working software with end-users	We’ll review your response to item 1.0 to ensure that it includes descriptions of the following areas: How you are breaking the effort down into smaller segments of work, how you will prioritize or sequence them, and how you will know if you’re on track to recommend a specific approach for your MITDP Significant unknowns and open questions, and how you will collect the data necessary to answer them Significant decision points, with particular attention to forks in the road where you might change direction based on what you’ve learned The staffing that you’ll need to complete the different areas of work
9	Response to item 1.0 demonstrates an adequate sense of openness and curiosity around open questions and significant unknowns, with an approach that will support iterative changes over time based on what they learn	We’ll review your response to item 1.0 with attention to its detail around significant unknowns and open questions to assess the level of openness and curiosity in your approach
10	Response to item 1.0 demonstrates an understanding of how to assess and evaluate options for what technology might be best	We’ll review your response to item 1.0 with attention to its detail around how you’ll evaluate different technology options in a manner that will can lead to a selection of what might be the best path forward
11	Response to item 1.0 demonstrates understanding of key decision points	We’ll review your response to item 1.0 with attention to its detail around significant decision points to assess your understanding of which areas of the project will require coordinated and strategic attention
12	Response to item 1.0 demonstrates an understanding of how the staffing for the project will change at different stages or milestones based on modern practices for iterative, user-centered software development	We’ll review your response to item 1.0 with attention to its detail around how staffing will change at different stages or milestones to assess your understanding of how team structures will need to change based on modern practices for iterative, user-centered software development
13	Response to item 2.1 demonstrates an understanding of the risks of vendor lock-in and proposes a reasonable and achievable approach to maintaining data portability	We’ll review your response to item 2.1 with experts in procurement and technical architecture to ensure that the solution can maintain data portability
14	Response to item 2.2 lists all likely technology infrastructure and data sources that will need to integrate with the system	We’ll review your response to item 2.2 to ensure that it lists all likely technology infrastructure and data sources that will be needed for integrations
15	If 2.2 includes system integrations, submission includes at least one system diagram that demonstrates a technical approach that is reasonable and achievable	We’ll review your response to item 2.2 with technical architects to ensure that technical approaches are reasonable and achievable
16	Response to item 2.3 includes reasonable and achievable plans for supporting identity management, electronic signatures, and/or accepting payments, if applicable	We’ll review your response to item 2.3 to ensure that plans for supporting identity management, electronic signatures, and/or accepting payments are included when necessary, and review plans for supporting this functionality with technical architects to ensure that they are reasonable and achievable. In the case that this area of work will be led by a contractor, we may provide specific requirements for those contracts around system integrations.
17	Response to item 2.4 demonstrates competency in software reliability engineering, with detail around how the team will be structured to manage the specific needs of the proposed system	We’ll review your response to item 2.4 with software reliability engineers to ensure that the included plan and team structures are reasonable and achievable. In the case that this area of work will be led by a contractor, we may provide specific requirements for those contracts around system management.
18	Response to item 2.5 demonstrates competency in performance measurement and data analysis, with detail around specific methods and processes for research and measurement	We’ll review your response to item 2.5 with experts in performance measurement and data analysis to ensure that the proposed approach to instrumentation and research methods is reasonable and achievable
19	Response to item 2.5 demonstrates awareness and understanding of privacy concerns and requirements	We’ll review your response to item 2.5 with experts in privacy and data management to ensure awareness and understanding of critical factors
20	Response to item 3.1 includes a reasonable and achievable amount of functionality for the 90-day build, demonstrating the team’s core technical competencies	We’ll review your responses to item 3.1 to ensure that it includes reasonable and achievable amount of functionality for your 90-day build, including notable trade-offs, potential concerns, and open questions Note: Building on your notes for trade-offs, concerns, and open questions, these details can continue to iterate over the course of the approval process. The scope for your 90-day build will not be finalized until the project is formally approved as an MITDP
21	Response to item 3.2 includes relevant requirements for the project’s Definition of Ready in a manner that is clear and independently verifiable	We’ll review your response to item 3.2 to ensure that (a) all likely requirements are included as part of the Definition of Ready, (b) all requirements listed are actually necessary for the 90-day period to begin, and (c) all requirements are described in a manner where their completion can be clearly and independently verified
22	Response to item 3.3 includes a plan for demonstrating working software that will allow members of MITDP Oversight teams to evaluate both the user experience and the quality of the underlying code	We’ll review your response to item 3.3 to ensure that the plan for demonstrating working software will allow members of MITDP Oversight team to evaluate both the user experience and the quality of the underlying code in a manner that is reasonable and achievable

Stakeholder Engagement Strategy

Guidance for completing this step

To complete this section of the Launchpad, you will submit a list of your project’s stakeholders using the worksheet below, providing names, titles and contact information. We will reach out to some stakeholders on your list as part of the MITDP determination process. We expect that you will continue to edit and adjust this list as the project progresses.

The worksheet organizes your stakeholders by level of engagement and subject area.

Level of Engagement
For levels of engagement, we’re using a framework with four levels, which are based on how often the stakeholder is expected to interact with your project and what types of activities or input you expect during those interactions.

Engagement level	Time commitment	Expected activities	Expected actions
1 / Awareness Group	1 to 2 hours each month	Receiving project updates every 4 to 6 weeks	Sharing updates with colleagues Sharing any feedback or concerns that arise from reviewing project updates
2 / Advisory Team	4 to 6 hours each month	Attending bi-weekly Sprint Reviews and/or reviewing meeting materials	Providing written feedback noting any concerns and/or overall support for the content and decisions in each Sprint Review
3 / Support Team	TBD based on the needs of the Core Team	Supporting the Core Team as an Subject Matter Expert (SME) or technical specialist	Being available as-needed for specific areas of expertise, such as policy analysis, data engineering, security reviews, visual design, or user research coordination
4 / Core Team	100% allocation / 40 hours each week	Running the work of the project day-to-day	Being 100% allocated to the work of moving the project forward *Note that you’ll get into more detail on this team in the Staffing and Leadership Strategy section

Roles to consider including in your stakeholder groups
Stakeholders for your project are likely to come from many different teams and subject areas. The table below provides some of the common subject areas you may want to consider.

Note: We’ve omitted “Core team” as a column here, as that will be a focus for the next section.

Subject area	For your Awareness Group	For your Advisory Team	For your Support Team
Program Ownership & Management The people who run the program(s) your product is supporting	Managers of adjacent programs that might be affected by your timing or strategy Stakeholders responsible for budget, contracting, or hiring efforts that need to stay aligned with your project’s progress	The Program Manager(s) of the programs being supported Anyone who will need to approve the product before it launches	Program and Policy Analysts who can advise on different program areas as an SME Office Managers who can support in getting access to relevant buildings and booking rooms for in-person meetings
Technology Infrastructure	Your agency’s DoIT Portfolio Officer Your agency’s Chief Information Officer	The CIO, Deputy CIO or operational director over the systems being changed	Engineers and Technical Architects working on existing systems
Data Management	The Chief Data Officer of your agency, or designee	The Chief Data Officer of your agency, or designee, in the case that data sharing is critical to project success (otherwise, the Awareness Group may be a better fit)	Data Engineers to help your team extract, transform, and access data from across systems Data Managers and Supervisory Data Analysts to support identifying and gaining access to key datasets
Accessibility		Accessibility Specialists to provide project-specific support	Accessibility Specialists to provide project-specific support Communications Specialists to support refining and approving public-facing content Front-End Web Developers to support improvements to online accessibility
Security	Your agency’s Chief Information Security Officer	Your agency’s Chief Information Security Officer, or designee Your agency’s Information Security Officer (ISO)	Your agency’s Information Security Officer (ISO)
Privacy	Your agency’s Chief Privacy Officer
Budget / Finance	Your agency’s Chief Financial Officer		Financial Point-of-Contact for this project
Legal	Your agency’s Assistant Attorney General (AAG)		Your agency’s Procurement Officer
Legislative Affairs	Your agency’s Legislative Affairs representative
Communications / Public Affairs	Your agency’s Comms/Public Affairs representative	Your agency’s Comms/Public Affairs representative, for more frequent involvement on higher-profile projects	Communications Specialists to support refining and approving public-facing announcements
Executive Leadership	Your agency Secretary, Deputy Secretary, or Chief of Staff		Your agency Chief of Staff or Portfolio Officer

Required worksheets

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

Worksheet	Link
Stakeholder Strategy worksheet	Stakeholder Strategy Worksheet

Acceptance criteria

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

#	Criterion	How we’ll assess this
1	Strategy uses required worksheet	We’ll review your submission to ensure that it uses the required worksheet shared in the section above
2	Includes relevant stakeholders across all relevant subject areas	We’ll review your lists of stakeholders across engagement levels to ensure that the relevant project areas are met (eg, Program Ownership, Technology Infrastructure, Data Management, etc)
3	Stakeholders have appropriate level of seniority and/or relation to project	We’ll consider the relevance of the stakeholders included to ensure appropriate levels of seniority and subject matter expertise
4	Stakeholders are included to represent all necessary system and data integrations	We’ll review the system and data integrations listed in your implementation plan to ensure that you’ve included stakeholders from the organizations that manage those systems and data sources
5	Accurate email addresses and phone numbers are included for all stakeholders	We’ll review the email address columns for email addresses and phone numbers for completeness
6	Stakeholders have agreed to participate at the their assigned engagement levels	We’ll contact stakeholders to confirm their awareness of being included and understanding of the time commitment and responsibility at their level of engagement

Staffing and Leadership Strategy

To be approved for MITDP status, your staffing strategy must meet the MITDP staffing requirements, which includes having a UX Lead, Technical Product Manager, and a Technical Lead / Architect.

Guidance for completing this step

For this section of your Launchpad, use the worksheet linked below to identify your project sponsor, project leadership team, and project core team members and open positions. Your strategy should reflect your staffing plans through the end of your 90-Day Build. At the end of that period, we will discuss changes in staffing based on your experiences in producing the 90-Day Build.

Required roles across all phases

All projects must have staff assigned to the following roles at all times. For smaller projects, the same member of the Core Team may be able to fill more than one role.

Name of role	Description	Engagement level	Allocation details
Project Sponsor	Senior executive responsible for supporting the project team in clearing blockers and coordinating across stakeholder groups.	Advisory Team	Required for entire duration of the project’s time as an MITDP
Project Lead	Responsible for leading the project day-to-day, overseeing prioritization, staffing, contract management, and risk mitigation. For smaller projects, this role can be filled by the Design Lead, Product Management Lead, or Technical Lead.	Core Team (100% allocation to the project following prep phase)	Required for the entire duration of the project’s time as an MITDP
User Experience (UX) Lead	Directs the work of understanding what your users need and designing better content, tools, and processes to meet those needs	Core Team (100% allocation to the project after prep)	Required for the entire duration of the project’s time as an MITDP
Technical Product Manager	Directs the work of prioritizing features based on iterative feedback from users, stakeholders, and technical experts	Core Team (100% allocation to the project after prep)	Required for the entire duration of the project’s time as an MITDP
Technical Lead / Architect	Directs the work of building and testing scalable, secure, and sustainable technology that can adapt & grow with changing user needs	Core Team (100% allocation to the project after prep)	Required for the entire duration of the project’s time as an MITDP

Required roles for the Delivery phase and Transition phase

All projects in the delivery or transition phases must assign staff for the following roles to support delivery management and quality assurance. These roles are optional at the start of the project, but are required to be added following the 90-Day Build.

Name of role	Description	Engagement level	Allocation details
Delivery Manager	Supports the day-to-day performance of the team, managing logistics, coordination across sub-teams, and continuous delivery	Core Team (100% allocation to the project)	Required during Delivery phase and Transition phase (optional during other phases)
Quality Assurance (QA) Lead	Directs the work of testing and monitoring the quality of the product, including the data it produces and its underlying infrastructure	Core Team (100% allocation to the project)	Required during Delivery phase and Transition phase (optional during other phases)

Additional roles to consider for your Core and Support teams

The following roles may be helpful to consider based on the needs of your project.

Note that if a team member is assigned to your Core Team, their allocation following the Prep phase must be at least 80%, except in rare circumstances. This is critical for project health, allowing all members of the Core Team to collaborate throughout each day, testing and learning quickly with minimal scheduling conflicts.

If a team member is unable to commit to an 80% allocation, they are likely a better fit for your Support Team.

Roles in Design and User Research

Staff in design and user research help your team understand what your users need and design better content, tools, and processes to meet those needs.

Name of role	Description
User Researcher	Plans, conducts, and analyzes research to understand user needs, motivations, and behaviors. Their findings inform design decisions and product strategy, ensuring the team is solving the right problems for the right people.
Service Designer	Supports the entire end-to-end user experience across all channels, touchpoints, and over time. Service Designers map out complex processes, coordinate across different services, and ensure a cohesive, efficient, and user-friendly service delivery system.
Product Designer	Supports the user interface (UI) and user experience (UX) of the digital product. Product Designers create wireframes, interactive prototypes, and interface designs to ensure the product is intuitive, accessible, and solves user problems effectively.
Content Strategist	Supports the content of the product, ensuring it is clear, concise, on-brand, and meets user needs. This includes defining tone and voice, creating content guides, and writing/editing user interface copy, error messages, and documentation.
Visual Designer	Supports all visual elements of the product, including branding, color palettes, typography, and visual hierarchy. Visual Designers ensure the product is visually appealing and that the design system is consistently applied to support the user experience.

Roles in Product Management & Policy

Staff in product management and policy help your team prioritize features based on iterative feedback from users, stakeholders, and technical experts.

Name of role	Description
Product Manager	On larger, more complex projects, Product Managers support the Product Management Lead in defining and planning areas of product functionality based on feedback from users, in collaboration with user researchers, designers, and engineers.
Business Relationship Manager	Acts as the primary liaison between the product delivery team and key agency and program stakeholders. Business Relationship Managers ensure project alignment with broader organizational goals, manage stakeholder expectations, and communicate project status.
Policy Analyst	Analyzes and interprets existing policies, laws, and regulations to ensure solutions are compliant and aligned with legislative intent. Policy Analysts work with designers and product managers to translate complex policy requirements into clear, functional solutions, and advise on policy implications for design, data usage, and program outcomes.

Roles in Engineering and Quality Assurance

Staff in engineering and quality assurance (QA) help build and test scalable, secure, and sustainable technology that can adapt & grow with changing user needs

Name of role	Description
Software Engineer	Leads development of both the frontend (user interface) and the backend (server-side logic, databases, and APIs) of the application, with the ability to support all aspects of the software development lifecycle, from system architecture and data models to user interface implementation, ensuring seamless integration between all layers of the system.
Front-End Engineer	Supports development of the front-end elements of software, focusing on the visual and interactive elements that users directly interact with in their web browser or application. Front-End Engineers work closely with Product Designers, Visual Designers, and Accessibility Specialists to ensure a responsive, accessible, and high-performance user experience.
DevOps Engineer	Designs and maintains systems and processes for development operations (DevOps), including development pipelines and release automation to support continuous integration and continuous delivery (CI/CD).
Software Reliability Engineer	Supports availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of production systems. Software Reliability Engineers (of SREs) apply software engineering principles to operations to ensure the product is scalable, robust, and maintains the required service levels.
QA Engineer	Designs, develops, and maintains automated testing frameworks and processes across production systems. QA Engineers work closely with Software Engineers to write tests that ensure new features meet functional, performance, security, and accessibility standards before and after deployment.
QA Analyst	Performs and oversees a range of manual, automated, and exploratory testing to ensure the product is free of defects and meets the specified requirements and user needs. QA Analysts create test plans, document bugs, and validate fixes.

Roles in Data Engineering & Analysis

Staff in data engineering in analysis help access, analyse, visualize, and learn from data across disparate systems, often navigating complexity around data structures, data quality, and access requirements.

Name of role	Description
Data Engineer	Develops pipelines to extract, transform, and load data for different purposes, collaborates with software engineers and product managers to design database schemas based on program and technical requirements, and collaborates with QA staff to ensure data quality across systems. Defines data dictionaries from a technical perspective, including data tagging and transformations to support new processes, automations, and ways of working.
Data Scientist	Designs and implements statistical models, machine learning algorithms, and advanced analytical techniques to generate actionable insights, predict outcomes, and optimize performance for the project's core problems.
Data Analyst	Collects, cleans, and interprets data from various sources; tracks and reports on key performance metrics (KPIs) and success criteria; and translates complex data into clear, understandable reports and visualizations for stakeholders and program leadership. Defines data dictionaries from a content and business perspective, including data tagging and supporting ongoing processes for organization and documentation.

Roles in related specializations

Staff in procurement strategy, accessibility, and security have specialized skills to support project delivery.

Name of role	Description
Procurement Strategist	Develops and manages strategies for contracting with vendors for services, staffing, and technology, including market research, development of RFIs and RFPs, vendor selection, vendor management, and contract negotiation, ensuring compliance with state regulations and alignment with the project's goals for iterative, user-centered delivery.
Accessibility Analyst	Ensures that all content and interfaces are accessible for all users, including alignment with relevant state and federal accessibility standards. Conducts accessibility audits and user testing, and collaborates directly with interface designers, content strategists, front-end engineers, and product managers to prioritize and address accessibility issues across the system.
Security Analyst	Implements and manages security controls throughout the system design and development lifecycle, conducts risk assessments, monitors for vulnerabilities, and ensures the project's system, data, and architecture considerations meet all state and federal security policies.

Required worksheets

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

Worksheet	Link	Notes
Staffing & Leadership Strategy for New Projects	Staffing & Leadership Strategy (new projects)	Use this worksheet if your project is in Discovery, Planning, or Procurement
Staffing & Leadership Strategy for Existing Projects	Staffing & Leadership Strategy (existing projects)	Use this worksheet if your project is in Implementation and Delivery

Acceptance criteria

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

#	Criterion	How we’ll assess this
1	Staffing strategy completed using a required worksheet	We’ll review your submission to ensure that it uses the required worksheet shared in the section above
2	Project has identified a project sponsor that is prepared to fulfill their responsibilities	We’ll reach out to your Project Sponsor (if we haven’t talked to them already) to ensure that they understand your Implementation Strategy and will be allocated 100% to the project following the Prep phase
3	Staffing strategy includes UX lead, Product Management Lead, Technical Lead and related staff with experience in iterative, user-centered development for the duration of the project	We’ll review your submission to ensure that it includes staff in all necessary areas to deliver on your Implementation Strategy
4	Plans for staff acquisition will be able to bring in the right skillsets and backgrounds in a timeframe that is reasonable and achievable	We’ll review your plans for recruiting and hiring staff to ensure that they are reasonable, achievable, and limit potential conflicts of interest
5	Plans for hiring staff as PINs, Contractual PINs, and/or vendor employees ensures the State is building expertise that will remain after initial implementation and can make decisions in the best interests of the State	We’ll review your considerations for different hiring pathways, with particular attention to any conflicts of interest or potentially challenging incentive structures that would prevent effective collaboration as an iterative, user-centered delivery team
6	Staffing strategy has the right balance of skillsets to work together effectively, including strategic choices around how makeup of the team will change over time	We’ll review your strategy to ensure that it includes the right combination of staff to support design, product management, engineering, quality assurance, and related areas across different stages of your Implementation Strategy
7	Staffing strategy ensures the team is lean and has the right number of staff	We’ll review your response to ensure that staffing is right-sized each stage of work and prioritizes critical roles for a lean Core Team that can deliver value quickly and effectively
8	Staffing strategy demonstrates a commitment to staffing a dedicated, focused team for this effort	We’ll review your response to ensure that all members of the Core Team will be allocated at 100% once you begin building. This is critical for project health, allowing all members of the Core Team to collaborate effectively throughout each day, testing and learning quickly with minimal scheduling conflicts.

Assessment of Key Risks

Your risk assessment should focus on significant risks that could lead to project failure, meaning that the project does not solve the core problems or deliver the success conditions you’ve identified. Notably, these are different from the types of risks specific to maintaining a project on-time and on-budget. We want to empower your team to be iterative and user-centered, which means that your budget or timelines may need to change based on what you learn over the course of your project. (Which can be a good thing if it means that your project will be more successful!)

Once your Launchpad is approved, we will expect you to be monitoring these risks, as described in your risk assessment. We will ask for periodic updates and will report publicly on the risks you’ve identified (with the option to redact sensitive risks).

Guidance for completing this step

To complete this section of your Launchpad, you will use the Key Risks worksheet to list out your project’s likely risks and include information about likelihood, impact, mitigation strategies, and warning signs. The template instructs you to consider the following prompt:

For each significant risk the team thinks of, fill out the table in the template. There is no maximum number of risks to include.

We may review these risks with your stakeholders as part of the MITDP approval process, to ensure that your team and all of its major stakeholders are aligned on what key risks exist and how we plan to monitor and mitigate over time.

You may find it helpful to consider the following potential risk sources, which are also included in the “Category” dropdown within the Key Risks worksheet.

• Technology Implementation
• Procurement / Contracting
• Privacy & Security
• Infrastructure & Integrations
• Data Management
• Stakeholder availability
• Staffing & Expertise
• Prioritization & Product Management
• Budget & Funding
• Timelines & Milestones
• Legal & Policy
• Legislative Priorities
• Change Management
• External Dependencies

Required worksheets

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

Worksheet	Link
Key Risks Worksheet	Key Risks

Acceptance criteria

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

#	Criterion	How we’ll assess this
1	Key risks are submitted using required worksheet	We’ll review your submission to ensure that it uses the required worksheet shared in the section above
2	Submission includes likely critical risks across categories	We’ll review your key risks across categories to ensure that all likely areas are included
3	Submission does not include risks that are insignificant or unnecessary for this context	We’ll review your key risks to ensure that all items could cause project failure and are not lower-level concerns or issues related to maintaining perfect alignment with predicted schedule and spending
4	Each key risk includes a response plan that is reasonable and achievable	We’ll review your responses under the heading “How you’ll prevent this from happening” to assess whether it includes reasonable and achievable methods of preventing the key risk from occurring
5	Each key risk includes at least one (1) warning sign or leading indicator, including a plan for how to monitor for that warning sign over time	We’ll review each list of warning signs and plans for monitoring those signs over time to assess if all likely warning signs are included and if the plans for monitoring those signs are reasonable and achievable
6	Each key risk includes a contingency plan that is reasonable and achievable	We’ll review your responses for contingency plans to assess whether they are reasonable and achievable
7	Alignment with key stakeholders	We’ll review your documentation of key risks with the stakeholders on your Advisory Team, as well as your agency’s CIO and executive leadership to ensure that all key risks have been identified and have been prioritized appropriately

Cost Estimate

Your cost estimate will change over time as you learn more and contracts are awarded.

Guidance for completing this step

To complete this section of the Launchpad, you will need:

1. A list of anticipated project costs

2. Supporting information on how you arrived at the cost estimates

With those, fill out the Cost Estimate worksheet. This worksheet has four columns:

1. Expense Category

2. Details / What It Includes

3. Notes / Open Questions

4. Estimated Cost

Expense Category

Provide a high level category for each planned expense by selecting from the dropdown.

Options include:

• Staff / Services - includes expenses related to;

  • Required Project Staff roles (Project Lead, Technical Product Manager, Technical Lead / Architect, User Experience (UX) Lead, QA Lead and Delivery Manager)

  • Other project management staffing needs

  • Professional services (people related expenses) for software development / implementation / integration

• Technology / Tools - includes expenses related to;

  • software licenses for platforms, systems, and tools

  • hardware required to implement your solution

• Other - all other anticipated project expenses

Details / What It Includes

Provide a clear and specific description of the expense. (e.g., Full-Time Project Manager, 10-inch Tablet for Field Work, Annual SaaS Subscription).

Use this field to indicate where your estimate came from or how you developed your estimate and what existing contract(s) you plan to leverage, if known.

Notes / Open Questions

Document any factors, assumptions, or uncertainties related to the cost. (e.g., Assumes a 40-hour work week, Pricing pending final vendor quote, Need approval for this line item)

Estimated Cost

The forecasted dollar amount for this specific line item.

Required worksheets

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

Worksheet	Link
Cost Estimate worksheet	Cost Estimate

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 shared in the section above
2	Includes relevant expense category for each line item	We’ll review your response to Expense Category to ensure it occurs as a reasonable categorization of the expense
3	Sufficient details are provided for each line item that explains what it is that is needed	We’ll review your response to Details / What It Includes to ensure it is reasonable and sufficiently describes what is needed and what it includes
4	Sufficient details are provided for each line item that explains how it will be used to solve the core problem	We’ll review your response to Details / What It Includes to ensure it explains how it will be used to solve the core problem
5	Sufficient details are provided for each line item that explains where your estimate came from or how you developed your estimate	We’ll review your response to Details / What It Includes to ensure it explains where your estimate came from or how you developed your estimate
6	Sufficient details are provided for each line item that explains what existing contract(s) you plan to leverage, if known	We’ll review your response to Details / What It Includes to ensure it explains if and what existing contract(s) you plan to leverage

Project Vitals

Guidance for completing this step

For this section of the Launchpad, you will complete the Project Vitals worksheet, which walks you through providing your agency and a project name, identifying your key contacts, describing your elevator pitch for the project and whether the project is necessary to allow the state to fulfill legal requirements, often state or federal executive orders, regulations or legal judgements.

You will need to provide:

1. AGENCY - The full name of the State Agency submitting the project.

2. PROJECT NAME - The official, internal name of the project.

3. Submitter (Name/Email) - The name and email address of the person completing and submitting the Project Vitals.

4. CIO (Name/Email) - The name and email address of the Agency's Chief Information Officer.

5. CFO (Name/Email) - The name and email address of the Agency's Chief Financial Officer.

6. Project Financial Contact (Name/Email) - The name and email address of the key person responsible for the project's budget and financial tracking.

7. Submitter Relationship to Project - A brief explanation of the Submitter's role or connection to the project.

8. Names and email addresses of any additional stakeholders who should receive official communications.

9. A list of any other agencies involved in the project and a description of their involvement.

10. A high-level summary of the project's purpose (what problem needs to be solved), value (what MD residents, and how many, will be positively impacted) and objective (expected outcome).

11. If applicable, the specific details of the legal requirement (e.g., citation, executive order, regulation, or legal judgment) mandating the project.

Required worksheets

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

Worksheet	Link
Project Vitals Worksheet	Project Vitals

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 shared in the section above
2	Elevator pitch is provided, is 200 words or less, and clearly communicates the project's purpose, value and objective	We’ll review your elevator pitch to ensure it sufficiently explains the project's value and objective

Go to Launchpad Overview Go to Launchpad Stage 1