Unsolicited Proposal for a Microconsulting Services Marketplace Platform

1.0 Basic Information

2.0 Technical Information

2.1 Title

Microconsulting Services Marketplace Platform (or Expertise-as-a-Service Platform)

2.2 Abstract

Government managers and teams are modern knowledge workers (educated, experienced, adaptable) who are capable of performing their jobs superbly. Sometimes, however, they lack specific skills/knowledge in only 1–2 areas for a given task or project. Given the nature of this task or project, it might not be possible or practical to fill those gaps through extensive training. In addition, access to internal resources with such know-how might not be available, and engaging an outside firm in a full-blown consulting engagement would simply be overkill (i.e., a waste of taxpayer resources). Microconsulting is an emerging consulting format designed to solve this problem. It features an individual or small team who produces an immediate deliverable on a specific topic for a low cost. This differs from traditional consulting, which typically features large teams who work over an extended period and produce a variety of deliverables on a range of topics for a high cost. We propose constructing a software tool that will enable government workers to acquire microconsulting services using the micro-purchase authority (FAR 13.2) and the private-sector-temporaries authority (FAR 37.112). (See our preannouncement for more information.)

2.3 Objectives of the effort

The overarching goal of the proposed effort is to develop a vibrant, digitally-powered marketplace through which government personnel and industry experts fluidly engage in microconsulting projects (the “product”). Toward that end, the main objectives are to:

• Understand the context of the proposed products’s use (e.g., user needs, regulatory constraints), validate the problem that the product’s intended to solve exists, and validate that the product idea solves the problem through customer experiments
• Establish the direction of the product, including a list of prioritized features and a defined minimum viable product (MVP)
• Build a working prototype that meets the main user needs and evaluate its usefulness and usability
• Build a fully working product, test it with a larger subset of users, and prepare for live launch
• Make the product available to all users, and operate and maintain with the goal of continuously improving

2.4 Method of approach

Our proposed approach is designed to increase the government’s probability of project success by featuring the following key elements, which are detailed in the sections that follow:

• Modern digital delivery practices
• Cross-functional team
• Agile delivery phases
• Agile artifacts
• Modern technology stack
• Project management
• Open transition
• Deliverables

2.4.1 Modern digital delivery practices

In alignment with the U.S. Digital Services Playbook, we intend to integrate proven practices from various digital delivery disciplines. Effective use of these multi-disciplinary practices — in an integrated fashion — yield products that are highly valuable, adaptable, reliable, timely, and cost-efficient.

Note: The key practices listed here are the ones that we most anticipate using for this project. There are many additional practices that aren’t listed, but will be incorporated as necessary.

2.4.2 Cross-functional team

We plan to deploy a multi-disciplinary team of talented digital experts who, as a collective whole, possess the critical know-how necessary to ship an amazing product. Talented, cross-functional teams produce superior results. The roles that we propose include:

• Project Manager/Agile Coach. Responsible for driving the overall success of the project in collaboration with the government product owner, drawing on expertise in agile project management practices, agile coaching at the organizational and team levels, project status and progress reporting, risk/issue management, stakeholder management, continuous improvement, and contract administration.
• Product Strategist. Responsible for advising the government product owner on shipping the right product, leveraging expertise in lean-agile product development, product strategy, product planning, metrics & KPIs definition, product requirements gathering and analysis, product requirements documentation, product requirements prioritization, product specifications definition, product testing, product analytics, and stakeholder management.
• User Experience Designer/User Interface Designer. Responsible for designing a compelling experience for users of the product, drawing on expertise in user research, user modeling, conceptual modeling, design specifications documentation, interaction design, interface design, information architecture, content development, visual design, usability testing, participatory design, iterative design, and design tools.
• Fullstack Engineer. Responsible for creating a usable, adaptable, reliable, and secure product, leveraging expertise in system architecture, front-end development, back-end development, agile software development practices and tools, DevOps practices and tools, open source software, APIs, cloud computing, federal security standards, and Section 508 compliance.

Note: These are role descriptions, not individual job descriptions. For the User Experience Designer/User Interface Designer and the Fullstack Engineer roles, it’ll likely take more than one person to completely perform each.

2.4.3 Agile delivery phases

We plan to organize the work into distinct, logical, overarching agile delivery phases that are based upon a proven framework popularized by the UK’s Government Digital Service. A phased approach offers several advantages, including: (a) a construct for organizing the overall work, including what is to be done, by whom, and when; (b) a common, intuitive view of the project that gives everyone visibility into status and progress; and (c) frequent, logical breakpoints where government decision-makers can assess the state of the project, and decide whether to proceed or pivot.

2.4.3.1 Kickoff Phase

During the Kickoff Phase, Skylight will work with the government to arrive at a shared understanding of the project, including how it’ll be delivered and how the two parties will work together collaboratively.

With the government’s approval, Skylight will prepare and execute a plan for a formal kickoff meeting, the purpose of which is to:

• Co-create an initial product vision.
• Build a shared understanding of how the project will be delivered.
• Develop a working relationship between the government and Skylight through team-building exercises such as journey lines and market of skills.
• Create the space for creative and innovative thinking through liberating-structure exercises such as TRIZ.
• Establish initial standards, conventions, and guidelines related to the project, product, and team.
• Finalize the plan for the Discovery Phase.
• Clarify any questions, concerns, or uncertainties.

Key outputs include:

• Initial Product Vision Statement
• Project Data Sheet (a single-page summary of project management information such as scope, schedule, resources, and risks & issues)
• Agile Roles & Responsibilities Matrix
• Team Competence Matrix (makes the skills of the team visible to everyone, which promotes cross-collaboration)
• Standards, Conventions, and Guidelines:
  • Agile Team Working Agreement
  • Story Definition and Acceptance Criteria Format
  • Product Roadmap Format
  • Release Plan Format
  • Product Backlog Format
  • Release Monitoring Format
  • Iteration Monitoring Format
  • Task Board Format
  • Impediments Format
  • Iteration Metrics Format
  • Performance Indicators Format
  • Coding Standards and Commenting Standards
  • Code Review Checklist
  • Iteration-level Definition of Done
  • Release-level Definition of Done
  • Stakeholder Communications Plan Format
• Discovery Phase Plan

2.4.3.2 Discovery Phase

During the Discovery Phase, Skylight will work with the government to understand the context of the envisioned product’s use, validate the problem that the product’s intended to solve actually exists, and validate that the product idea solves the problem through customer experiments.

Key activities will include:

• Conduct user research — find out who the users are, what their needs are, and how those needs are or aren’t being met and analyze and synthesize findings.
• Analyze the project environment, including business needs, stakeholders, laws, policies, and existing systems and technology.
• Determine whether the envisioned product solves a real problem, drawing on the results from the user research.
• Design and conduct an experiment with real customers to validate that the envisioned product solves the problem. (Google Design Sprint could be an option here.)
• Develop a domain model (software engineering technique for organizing and structuring knowledge of the problem space).
• Finalize the plan for the Framing Phase.

Key outputs will include:

• User Research Report
  • Raw Data (e.g., interview notes)
  • User Personas
  • Experience Map
  • Findings and Recommendations
  • Prioritized User Needs
• Project Environment Analysis
  • Prioritized Business Needs
  • Stakeholder Map
  • Legal and Policy Constraints
  • Technical Constraints
• Product Validation Results (lessons learned, design questions)
• Domain Model
• Updated Project Data Sheet
• Framing Phase Plan

Note: At this stage, if it’s determined that there isn’t a valid problem to solve, or a digital platform isn’t the appropriate solution to solve the problem, it may be necessary to terminate the project.

2.4.3.3 Framing Phase

During the Framing Phase, Skylight will collaborate with the government to establish the direction of the product.

Key activities will include:

• Update the product vision statement, based on what was learned during the Discovery phase.
• Develop a product roadmap, which communicates how the product is likely to evolve across several major releases.
• Develop a product backlog, which includes writing, sizing, estimating, and prioritizing stories.
• Define the MVP, and adjust the product backlog as necessary (e.g., reprioritizing items).
• Create a product release plan that communicates which stories are targeted for delivery over the next three months based on the team’s speculated delivery capacity.
• Define the performance measurement system, including performance indicators and metrics related to the user experience, product, and infrastructure.
• Finalize the plan for the Alpha Phase.

Key outputs will include:

• Updated Product Vision Statement
• Product Roadmap
• Prioritized Product Backlog
• Product Release Plan
• Performance Measurement System
• Alpha Phase Plan

2.4.3.4 Alpha Phase

During the Alpha Phase, Skylight will build a working prototype that meets the main user needs and will evaluate how useful and usable that prototype is.

Key activities will include:

• Conduct “Iteration Zero” activities, which includes developing the style guide and design pattern library, defining the high-level architecture, and setting up the initial infrastructure.
• Develop a working prototype iteratively, integrating lean validation and UX design practices (e.g., user research, usability testing) continuously throughout the process.
• Continuously collect, monitor, and analyze performance indicator and metrics data, and derive insights from that data to make informed product decisions.
• Continuously update/refine project artifacts (e.g., product roadmap, product backlog, product release plan, domain model), as necessary.
• Finalize the plan for the Beta Phase.

Key outputs will include:

• Iteration Zero Artifacts
  • Style Guide
  • Design Pattern Library
  • High-level Architecture
  • Initial Infrastructure
• Working Prototype
• Updated Project Artifacts
• Beta Phase Plan

2.4.3.5 Beta Phase

During the Beta Phase, Skylight will build a fully working product, test it with a larger subset of users, and continuously improve it until it’s ready to go live.

Key activities will include:

• Develop and release the product iteratively, integrating lean validation and UX design practices continuously throughout the process.
• Continuously collect, monitor, and analyze performance indicator and metrics data, and derive insights from that data to make informed product decisions.
• Continuously update/refine project artifacts, as necessary.
• Prepare and plan for the Live Phase, making sure the system meets all the necessary functional, nonfunctional, security, and compliance requirements.

Key outputs will include:

• Production-ready Product
• Updated Project Artifacts
• Live Phase Plan

2.4.3.6 Live Phase

During the Live Phase, Skylight will make the product live and available to all users in a production environment, and operate and maintain it with the goal of continuously improving its value and quality.

Key activities will include:

• Release the product to a production environment.
• Execute user-growth activities, including marketing, outreach, and publicity.
• Operate and maintain the product.
• Develop and release product improvements iteratively, integrating lean validation and UX design practices continuously throughout the process.
• Continuously collect, monitor, and analyze performance indicator and metrics data, and derive insights from that data to make informed product decisions.
• Continuously update/refine project artifacts, as necessary.

Key outputs will include:

• Live Product
• Updated Project Artifacts

2.4.4 Agile artifacts

One of agile’s core values is “working software over comprehensive documentation.” This doesn’t mean that documentation isn’t an important part of an agile project. It’s important. Unlike traditional approaches to product delivery, however, agile doesn’t view documentation as the primary measure of progress. While our approach does rely on the creation and maintenance of a number of artifacts, the most important one above all is the early and frequent delivery of working software that’s driven and refined through continuous engagement with end users and stakeholders.

2.4.5 Modern technology stack (it takes a village)

Working with a modern technology stack is one of the core principles of the U.S. Digital Services Playbook. Our proposed technology stack, which will likely evolve as we learn more about the optimal technical approach, includes:

• Frontend: HTML5, CSS3, SASS, U.S. Web Design Standards, JavaScript, React/Immutable.js/Redux
• Backend: Rails RESTful JSON API, Puma, PostgreSQL
• Infrastructure: cloud.gov, Sentry
• Security: SSL, OAuth, JSON Web Tokens
• Testing: Jest, Nightmare, RSpec, Shoulda, FactoryGirl
• Code Quality: HTMLProofer, AccessLint, Code Climate, Tenable
• Continuous Integration/Delivery: Travis CI
• Source Code Management: Git, GitHub
• Analytics: Google Analytics, Heap
• Project Management: JIRA

Note: We would prefer to use Docker for containerization, but cloud.gov’s support for Docker images is currently limited.

2.4.6 Project management

Skylight will provide a project manager to serve as the primary point of contact for the government’s program office in order to facilitate the successful planning and execution of this proposed project.

The Skylight project manager and team will collaborate closely with the government’s assigned product owner on all aspects of the product.

When issues arise that directly affect Skylight’s ability to perform, we will provide written, timely notification (within 24 hours of any anticipated or known impact) to the contracting officer’s representative (COR) and the product owner.

During the Kickoff, Discovery, and Framing Phases, we will provide a weekly status report that includes the status of deliverables, work completed, planned actions, and open impediments. This is a more traditional approach of reporting project status. During the Alpha, Beta, and Live Phases, we recommend leveraging the artifacts that are continually created or updated over the course of an iteration to serve as the status report. These artifacts include, but are not limited to: Performance Indicators, Release Plan, Release Monitoring, Iteration Metrics, Iteration Monitoring, Task Board, and Impediments.

2.4.7 Open transition

Our aim is to maintain the project in a transferable state at all times in order to mitigate any disruption associated with handing it over to another party.

First, we strongly recommend that the government allow the project, including source code, to be developed in the open public from the outset. Such open access to the project’s assets will greatly reduce the amount of time it takes another party to ramp-up their knowledge.

Second, we will employ agile documentation best practices such as preferring executable specifications over static documents, treating documentation as a requirement (as part of the “definition of done” for each story), and keeping documentation as simple and concise as possible. Such practices will allow us to mitigate at least one factor that often contributes to project failure — heavy documentation — while at the same time capturing essential project and product knowledge.

Third, through the relentless pursuit of sound technical practices such as automated deployments, we will effectively reduce any risk of operational lock-in.

And, last, as part of the contract agreement, we will insist that all deliverables, products, licenses, designs, data, documentation, tests, user research notes, source code, configuration settings and files, and other assets developed throughout the project be the property of the U.S. Government and committed to the public domain. This will fully mitigate any potential issues around data rights and ownership of deliverables.

2.4.8 Deliverables

The proposed deliverables for this effort include:

2.5 Key personnel

We propose a cross-functional team of six people in total who will perform the roles described in Section 2.4.2. Given the critical importance of each distinct role, here are the proposed key personnel for each one:

All proposed personnel have significant experience and demonstrated expertise with the modern digital delivery practices and technology stack outlined in Sections 2.4.1 and 2.4.5, respectively.

Note: Given the constraints of operating as a new startup (e.g., depth of resources), we can’t guarantee the availability of the proposed key personnel due to the uncertain nature of when this proposal might result in a contract award. In other words, they should be treated as representative of the types of talent that we will supply. Our startup constraints also mean that we can’t fully provide alternates for each key individual listed above.

2.6 Agency support

What we’ll need from the government in order to make this a success:

• A dedicated government product owner who is fully supported by influential executive project sponsors and wholly empowered to make product decisions (see Play #6 in the U.S. Digital Services Playbook).
• Determination to work in new ways such as building in the open, focusing on user needs first and foremost, and developing software using lean and agile methods.
• Continuous engagement from your security personnel to help ensure security is built into the product at every step of the development process.
• An interagency agreement with 18F for use of cloud.gov (recommended). (We’re assuming that the proposed product will not be rated above a FISMA moderate impact level.)
• Ability to use Mac computers in delivering work.
• Access to facilities and equipment (including necessary credentials).

Note: Prior to the award of the contract, we would expect to confer with the contracting officer which equipment necessary to perform the work should be government furnished or contractor furnished.

2.7 Business impact

We believe that a microconsulting services marketplace platform, which leverages the micro-purchase and private-sector-temporaries authorities, could be transformative for a number of reasons:

• Agency knowledge workers could rapidly acquire expert advice from industry experts on a specific topic for a relatively low cost, thereby reducing unnecessary delay and expense to government projects caused by traditional procurement actions.
• Traditional government contracting scoping models could be significantly streamlined in favor of highly-focused, short-turnaround, low-cost engagement models, thereby increasing innovation and competition in the services marketplace.
• The government could test out the capabilities of a firm before engaging in a larger body of work (that is, “try before buying”), thereby reducing procurement risk.
• Past performance could be take into account without any formal rating system, thereby introducing the kind of robust use of past performance found in the commercial world. (Source: Dr. Steve Kelman.)
• The government could tap into the “gig economy,” thereby increasing access to a wider pool of talent, as well as increasing economic opportunities for non-traditional players.

The following storyboard illustrates one potential use case for a microconsulting services marketplace platform:

3.0 Supporting Information

3.1 Proposed cost

Please see the email Excel attachment, “Microconsulting Services Marketplace Platform Cost Model,” for a full breakdown and basis for the costs.

3.2 Proposal validity period

This proposal is valid for 12 months from the date of submission.

3.3 Contract type

The recommended contract type is time & materials (T&M), which is appropriate given the uncertain nature of the scope of work. The government may wish to pair the T&M contract with a not-to-exceed ceiling and fixed delivery timeframe. In effect, the government would be acquiring a fixed team for a fixed period of time. The scope would be bounded by a product vision statement, and the government product owner would direct the efforts of the team to produce the most valuable product with the given resources and the given amount of time.

Our proposed approach provides the government immediate and frequent visibility into contract performance. If the government is unsatisfied for any reason, it always reserves the right to terminate for convenience.

3.4 Period of performance

We propose a total period of performance of 27 months, with one base period and four option periods.

3.5 Organizational information and facilities to be used

3.5.1 Brief overview of Skylight

Skylight is a new digital consultancy based out of Sarasota, Florida. Our mission is to make government work in a digital world using design, technology, and procurement. We’re currently comprised of 8 people, most of whom are former Presidential Innovation Fellows. Together, we’ve co-founded and scaled 18F, built and sold technology startups, created standards that power the internet, and more. Given our unique blend of government and commercial expertise, agencies rely on us to solve their toughest digital challenges.

3.5.2 Previous experience

As an entity, we’re new, but the individuals on our team possess decades worth of experience delivering similar digital products and platforms, which have required great user experiences, enduring solution architectures, and sustained user growth.

3.5.3 Relevant past performance

The following Skylight case studies highlight our ability to deliver successful digital products and platforms: TalkTo, Carrot, and Maalka. These examples are highly relevant, particularly in terms of the modern digital delivery practices and technologies employed.

3.5.4 Facilities to be used

We recommend executing the project offsite with onsite travel as necessary.

3.6 Misc. statements

To the best of our knowledge and belief, Skylight and our teaming partner have no organizational conflict of interest (OCI) with regards to the proposed work. We will execute our standard OCI practices (e.g., nondisclosure agreements, no-bidding on contracts where a conflict might exist) in order to mitigate any potential issues.

Although we defer to the government’s judgment, we don’t not believe that the nature of the proposed work requires a security clearance beyond the Public Trust Security Clearance.

The proposed work doesn’t not have any material environmental impact.

3.7 Contacts made

We haven’t directly contacted any agency official regarding this proposal. All electronic submissions of this proposal were sent to each agency’s designated email address.