diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..3e164f1 --- /dev/null +++ b/.gitignore @@ -0,0 +1,2 @@ +_site +.DS_Store \ No newline at end of file diff --git a/_pages/primers/modular-contracting.md b/_pages/primers/modular-contracting.md index b32c4bc..3ad5d64 100644 --- a/_pages/primers/modular-contracting.md +++ b/_pages/primers/modular-contracting.md @@ -3,19 +3,18 @@ title: Modular Contracting --- As described in the [FAR](https://www.acquisition.gov/sites/default/files/current/far/html/Subpart%2039_1.html#wp1096828), modular contracting is, -> intended to reduce program risk and to incentivize contractor performance while meeting the Government’s need for timely access to rapidly changing technology. -> When using modular contracting, an acquisition of a system of information technology may be divided into several smaller acquisition increments that— - -> 1. Are easier to manage individually than would be possible in one comprehensive acquisition; - -> 2. Address complex information technology objectives incrementally in order to enhance the likelihood of achieving workable systems or solutions for attainment of those objectives; - -> 3. Provide for delivery, implementation, and testing of workable systems or solutions in discrete increments, each of which comprises a system or solution that is not dependent on any subsequent increment in order to perform its principal functions; - -> 4. Provide an opportunity for subsequent increments to take advantage of any evolution in technology or needs that occur during implementation and use of the earlier increments; and - -> 5. Reduce risk of potential adverse consequences on the overall project by isolating and avoiding custom-designed components of the system. +
+

intended to reduce program risk and to incentivize contractor performance while meeting the Government’s need for timely access to rapidly changing technology.

+

When using modular contracting, an acquisition of a system of information technology may be divided into several smaller acquisition increments that—

+
    +
  1. Are easier to manage individually than would be possible in one comprehensive acquisition;
  2. +
  3. Address complex information technology objectives incrementally in order to enhance the likelihood of achieving workable systems or solutions for attainment of those objectives;
  4. +
  5. Provide for delivery, implementation, and testing of workable systems or solutions in discrete increments, each of which comprises a system or solution that is not dependent on any subsequent increment in order to perform its principal functions;
  6. +
  7. Provide an opportunity for subsequent increments to take advantage of any evolution in technology or needs that occur during implementation and use of the earlier increments; and
  8. +
  9. Reduce risk of potential adverse consequences on the overall project by isolating and avoiding custom-designed components of the system.
  10. +
+
## Definition diff --git a/_site/about/index.html b/_site/about/index.html deleted file mode 100644 index a88e7ad..0000000 --- a/_site/about/index.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - About - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

About

-

Announced in March 2016 by the Office of Federal Procurement Policy (OFPP), the Digital Acquisition Accelerator is a pilot program aimed at helping agencies accelerate the adoption of digital acquisition practices. It’s funded by the General Services Administration, and is managed and delivered by 18F and the Presidential Innovation Fellows. Its purpose is to complement, not replace, the creation of an Acquisition Innovation Lab, per the OFPP memo.

- -

This Accelerator program is currently running as a pilot, which means we’re still learning how best to design it. Toward this end, we’ve broken it into two phases—alpha and beta.

- -

During the alpha phase, which we expect to complete toward the end of 2016, we’re working with two agencies — the U.S. Department of the Treasury and the Federal Bureau of Investigation (FBI). These agencies will work on the following products:

- -

Treasury

- -
    -
  • Certificate of Label Approval (COLA) Registry modernization, Alcohol and Tobacco Tax and Trade Bureau (TTB)
  • -
  • IRS Auction site (auction.gov) modernization, Internal Revenue Service (IRS)
  • -
- -

Federal Bureau of Investigation

- -
    -
  • National Virtual Translation Center (NVTC) redesign
  • -
  • Mobile tagging and scanning of crime scenes
  • -
- -

Learn more about the accelerator at https://pages.18f.gov/digitalaccelerator/, or on our blog at https://18f.gsa.gov/tags/digital-acquisition-accelerator/

- - -

Leave a comment on this page

- - -
-
-
- - - diff --git a/_site/case-study/index.html b/_site/case-study/index.html deleted file mode 100644 index 9c2117a..0000000 --- a/_site/case-study/index.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Case Study: HHS Buyer’s Club - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Case Study: HHS Buyer’s Club

-

“The HHS Buyers Club is a HHS IDEA Lab sponsored project focused on addressing a critical problem in government: modernizing federal acquisition of information technology (IT) and related services. Given the expansion and impactful role of digital services throughout government, there are many opportunities to improve existing acquisition methods that are used to support government services, thereby directly benefiting the public.

- -

Purpose of HHS Buyers Club

- -

Current government acquisition and procurement methods are no longer appropriate for modern software development practices. It has been widely recognized that government access to and use of technologies that support data and information management are lagging behind the private sector. According to the 2013 Chaos Manifesto from the Standish Group, out of all IT projects in excess of $10 million, 52% were found to be challenged and 48% failed.. Innovative strategies to leverage federal acquisitions processes are needed to seek better value and outcomes for the services we provide the public.

- -

Current federal acquisitions approaches reflect unnecessary operational and cultural barriers to success (planning, evaluation, award, and implementation), including but not limited to the lack of true end user and stakeholder engagement from cradle to grave in a manner that maximizes value while minimizing spend. We’re not implementing new regulations or any new statutes but rather emphasizing new strategies allowed under the FAR or other approved legislation. Acquisition cycles are longer than IT development cycles, creating an unnecessary, lengthy, and outdated way of performing mission needs. Acquisitions require agility, both in terms of planning and implementation.”

- -

Learn more about the HHS Buyer’s Club.

- - -

Leave a comment on this page

- - -
-
-
- - - diff --git a/_site/glossary/index.html b/_site/glossary/index.html deleted file mode 100644 index 8e98acd..0000000 --- a/_site/glossary/index.html +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Glossary - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Glossary

-

Agile

- -
    -
  • Epic: A large or high level user story that can be broken down into a number of smaller stories. (NOTE: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/working-with-epics)
  • -
  • Product Backlog: a prioritized list of items for the development team to deliver. The most important items are shown at the top of the product backlog so the team knows what to deliver first. (NOTE: https://www.atlassian.com/agile/backlogs) Items are often in the form of user stories.
  • -
  • Product Owner: The member of a scrum team who is responsible for what the team produces and the order in which it’s produced. The Product Owner is charged with making sure that the team produces something that is of value to users and customers.
  • -
  • Retrospective: At end of each sprint, a retrospective is held which allows the team to reflect and adjust practices. Any team member can voice a problem or propose a solution.
  • -
  • Scrum Master: The servant leader of the team who facilitates, removes impediments, and generaly ensures that the team is working well without managing them directly.
  • -
  • Sprint: A short period of time (usually two weeks) during which the team produces some items of customer value. Valuable feedback is sought from users and customers at the end of each sprint.
  • -
  • Sprint planning: The team’s process of understanding and committing to a set of value to produce during the upcoming sprint. .
  • -
  • Standups: the team meets daily for short meetings which are typically held standing up, face-to-face to encourage brief sessions. This is not a status meeting, it is a meeting for team self-organization around the work of the day. Team members plan for the most efficient and productive day for the team. Long answers and discussions should have follow-up in smaller groups after the standup meeting.
  • -
- -

Human-Centered Design

- -
    -
  • Design Thinking. A human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.
  • -
  • Frameworks. Visual representations of a system used to highlight key relationships and develop strategy.
  • -
  • Prototype. Quickly created, representations of a product, program, or service to test a hypothesis or assumption about the usability and/or functionality of a feature or set of features.
  • -
- -

Lean Startup

- -
    -
  • Actionable Metrics: Metrics used to help determine outcomes of experiments and better understand product performance. These metrics tie “specific and repeatable actions to observed results.
  • -
  • Innovation Accounting: An accounting method to figure out if a startup is making a progress before there is enough gross numbers for traditional accounting to kick in. It is a way to define, measure, and communicate outcomes to stakeholders.
  • -
  • Minimum Viable Product: As Ash Maurya states, a Minimum Viable Product is the smallest thing you can build that delivers a customer value (and as a bonus captures some of that value back).
  • -
  • Pivot: A structured course correction taken by an organization designed to test a new fundamental hypothesis about the product, strategy, and engine of growth.
  • -
  • Validated Learning: Determining pivot or preservere decision using actionable metrics from experiments.
  • -
- -

Modular Contracting

- -
    -
  • Increments. Useful sub-segments of a larger contract that are used to develop and implement discrete products and capabilities related to a larger system.
  • -
  • Modular architecture. A system consisting of discrete but connect components (or modules) that can be replaced, reused, or added to without affecting the rest of the system.
  • -
- -

Open Innovation

- -
    -
  • Challenges and Prize Competitions. With a challenge and prize competition, a “seeker” poses a problem or question to the public and “solvers” respond and submit solutions. An agency pays only for those solutions that meet the criteria and are chosen as winners. (NOTE: https://www.challenge.gov/about/) Success in these competitions depend on the skill, judgement, and knowledge of the participants and does not wholly rely on chance.
  • -
  • Citizen Science. When the public participates voluntarily in the scientific process with the federal government and nongovernmental organizations, addressing real-world problems in ways that may include formulating research questions, conducting scientific experiments, collecting and analyzing data, interpreting results, making new discoveries, developing technologies and applications, and solving complex problems. (NOTE: https://www.citizenscience.gov/about/)
  • -
  • Crowdsourcing. When organizations submit an open call for voluntary assistance from a large group of individuals for online, distributed problem solving. (NOTE: https://www.citizenscience.gov/about/)
  • -
  • Hackathons. An event of any length of time where people, usually from varying disciplines, come together to solve problems to a specific topic.
  • -
  • Open Source. Denotes software whose source code is made freely available and can be modified and redistributed. The full defintion for open source can be found here https://opensource.org/osd-annotated.
  • -
- - -

Leave a comment on this page

- - -
-
-
- - - diff --git a/_site/index.html b/_site/index.html deleted file mode 100644 index b175088..0000000 --- a/_site/index.html +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Overview - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Overview

-

We are all in this together on this beautiful journey into digital acquisitions. The goal of this guide to to do one thing: make you a smarter government buyer of digital products and services. Digital acquisitions aren’t different from other acquisitions per se, it’s just a different domain speciality. From a broad perspective it is simply buying products and services related to software. Note that is guide focuses on digital acquisitions of custom software solutions but many of principles can be applied in various contexts. There are five main things that will make you a smarter buyer of digital products and services:

- -
    -
  1. Staying up to date on modern digital practices
  2. -
  3. Building the right team
  4. -
  5. Understanding the true needs of your program teams and agency
  6. -
  7. Writing better solicitations to attract a better vendor pool
  8. -
  9. Avoiding known landmines
  10. -
- -

It starts with changing your mindset and thinking a bit differently during each phase of the process. This guide breaks up digital acquisition process into five phases: Ignition, Inception, Procurement, Delivery, and Landing. In each phase, we’ll talk about the goals, activities, outputs, and desired outcomes to help you get what your agency and users really need: better digital products and services.

- -

In this guide you will find information about: -- Digital Acquisition Process -- Primers on Modern Digital Practices -- Related Case Studies -- Digital Acquistion Accelerator

- -

Background

-

Here is a great collection of resources that will help you understand digital acquisitions (in case you need it!).

- - - -

Acquisitions is defined by the Federal Acquisitions Regulation (FAR) as the:

- -
-

“means the acquiring by contract with appropriated funds of supplies or services (including construction) by and for the use of the Federal Government through purchase or lease, whether the supplies or services are already in existence or must be created, developed, demonstrated, and evaluated.

- -

Acquisition begins at the point when agency needs are established and includes the description of requirements to satisfy agency needs, solicitation and selection of sources, award of contracts, contract financing, contract performance, contract administration, and those technical and management functions directly related to the process of fulfilling agency needs by contract.” A short definition provided by the Federal Acquisition Institute explains acquisitions as “including traditional contracting functions, requirements definition, assessment and oversight of contract performance, and technical and management direction.”

-
- -

This is one of the key tools the federal government has at its disposal to get things done so it’s pretty important. In the past, federal IT acquisitions have not gone so well because:

- -
    -
  • There are a limited number of people in the workforce that understand both IT and Procurement which leads to a detrimental skills gap.
  • -
  • The “status quo” approach to large, multiyear, waterfall-based, extended requirement gathering, year-long competitions does not move at the same speed as technology.
  • -
  • Companies with creative solutions to many of the Government’s tech problems are finding it challenging to do business with the Government due to high barriers to entry, lack of customer facing tools, complex acquisition processes, and communication confusion on how to identify the available opportunities. [Source]
  • -
- -

In this guide, we hope to help you understand how building cross-functional teams that understand and appreciate human-centered design methodologies, modern digital practices, and how thinking in terms of outcomes rather than requirements could transform digital acquisitions at your agency. We will also help you understand the open innovation movement and how it can apply to some of your digital projects to boot!

- -

Now that we have our background information out of the way, let’s talk about how you can lower your risks by avoiding some known landmines. These are all things that haven’t worked well for us when it comes down to digital acquisitions and you would be better off to avoid them (or at least use them carefully.

- -

- -

Landmine #1

- -

Large, monolithic contracts

- -

These, simply put, do not work well for digital products and services. The Standish Group points out that you are only giving yourself a six percent chance of success when you start these types of projects. Also, technology moves fast and if you want your agency to be able to respond quickly in an ever changing landscape, you will need to avoid this at all costs.

- -

Landmine #2

- -

Writing too-large RFPs

- -

You may not remember this but there was a time when airplanes did not exist. And they did. In 1907 the US Army wanted to acquire one of these, mind you that airplanes were so cutting edge at the time that they weren’t even called airplanes, they were called “heavier than air flying machines.” Guess how many pages the solicitation was for this piece of technology? 50 pages? 20 pages? No, it was 2 pages! You do not need 100 page RFPs to acquire the best digital solutions for your agency. Often, all this does is encourage some of your best potential vendors to not respond. The length of these types of RFPs are typically driven by the old requirements gathering mindset combined with bloated legalese where the concern is more about oversight and liability versus product quality and project success. These long RFPs take too much time for your agency to write, too much time from vendors to respond to it, and discourage good vendors from bidding… there are very few good outcomes when this happens. Instead, work internally to develop a sound problem statement and product vision. Think in terms of objectives and user stories. Indeed, modern agile development methods pay careful attention to alternative ways of specifying and achieving desired outcomes for product development.

- -

Landmine #3

- -

Only having “acquisitions” people involved in the acquisitions process

- -

Remember that acquisitions is more than just buying and because of this, it is important to bring key expertise, like policy, law, engineering, design, and security, to the table early in the acquisitions process to ensure the project’s success. Leveraging the expertise of a cross-functional team will help make sure your agency is solving the problems for your end users.

- -

Landmine #4

- -

Not being open to change

- -

The world moves fast and technology moves even faster. You have to be willing to adapt, course correct, and try new things to get the best digital products and services for your teams. The goal is to get better outcomes, not just contracts. No matter what your experience has been until now, you can learn and apply new techniques to make acquisitions more effective, more efficient and hopefully more joyful (yes, joyful… more on this later). Being open to change means shifting the focus from a “no we can’t” to a ‘how might we” context. It allows you to solve the problems as they arrive and based on any given context, known or unknown.

- -

Landmine #5

- -

Forgetting that people, not contracts, manage projects

- -

It is important to have a product owner that works with the vendor until the period of performance is complete. Often, a contracting officer may work really hard to be sure that every possible clause that may or may not be needed is included within the contract. This is fine, but it often overlooks the reality that over the life of the contract, new ideas will be formed and business strategy may shift so it is important to have someone from your agency working hand in hand with the vendor to help make rapid decisions that still align with organizational goals. Relying too heavily on contract clauses to solve every problem that may arise over the period of performance is an untenable expectation. It is important that you are allotting time for a resource in your agency to be a product owner to ensure the outcome has a greater chance of success.

- -

Avoiding these common landmines are the first steps in transforming digital acquisitions at your agency.

- - -

Leave a comment on this page

- - -
-
-
- - - diff --git a/_site/primers/agile/index.html b/_site/primers/agile/index.html deleted file mode 100644 index 42033f2..0000000 --- a/_site/primers/agile/index.html +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Agile - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Agile

-

Definition

- -

When most people think of “agile” they tend to think of specific agile methodologies like Scrum or eXtreme Programming. Agile is really a philosophical approach to software development centered around a few core principles:

- -
    -
  1. People over process
  2. -
  3. Working software (i.e., delivered value) over documentation
  4. -
  5. Collaboration with users and customers
  6. -
  7. Responding to changes in requirements
  8. -
- -

Specific methodologies such as Scrum, eXtreme Programming, and in some cases Kanban offer detailed implementations of the principles of agility. Agile development involves a iterative approach to software delivery, where software is built increpentally from the start of the project, rather than trying to deliver it all at once near the end.

- -

Key Resources

- - - -

Key Terms

- -
    -
  • Product Backlog: a prioritized list of items for the development team to deliver. The most important items are shown at the top of the product backlog so the team knows what to deliver first. Items are often in the form of user stories.
  • -
  • Epic : A large or high level user story that can be broken down into a number of smaller stories.
  • -
  • Product Owner: The member of a scrum team who is responsible for what the team produces and the order in which it’s produced. The Product Owner is charged with making sure that the team produces something that is of value to users and customers.
  • -
  • Retrospective: At end of each sprint, a retrospective is held which allows the team to reflect and adjust practices. Any team member can voice a problem or propose a solution.
  • -
  • Scrum Master: The servant leader of the team who facilitates, removes impediments, and generaly ensures that the team is working well without managing them directly.
  • -
  • Sprint: A short period of time (usually two weeks) during which the team produces some items of customer value. Valuable feedback is sought from users and customers at the end of each sprint.
  • -
  • Sprint Planning: The team’s process of understanding and committing to a set of value to produce during the upcoming sprint. .
  • -
  • Standups: the team meets daily for short meetings which are typically held standing up, face-to-face to encourage brief sessions. This is not a status meeting, it is a meeting for team self-organization around the work of the day. Team members plan for the most efficient and productive day for the team. Long answers and discussions should have follow-up in smaller groups after the standup meeting.
  • -
  • User Story: A short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template: As a , I want so that .
  • -
  • Velocity: The sum of effort estimates associated with the user stories accepted by the Product Owner during a sprint.
  • -
- -

History

- -

So what does skiing have to do with agile principles? Much more than you would think. The Agile Manifesto was created from February 11-13, 2001 at the Ski Bird Lodge in the Wasatch mountains of Utah (fun fact: other discussed choices for this meeting were Chicago, IL and Anguilla. Chicago was thought to be too cold without enough fun things to do and Anguilla too hard to get to). The Manifesto for Agile Software Development, more commonly referred to as the Agile Manifesto, was born from this fateful meeting of the minds. The manifesto, in full, is as follows:

- -
-

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

- -

Individuals and interactions over processes and tools

- -

Working software over comprehensive documentation

- -

Customer collaboration over contract negotiation

- -

Responding to change over following a plan

- -

That is, while there is value in the items on the right, we value the items on the left more.

-
- -

This manifesto led to 12 principles that guide the agile development process:

- -
    -
  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. -
  3. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  4. -
  5. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  6. -
  7. Business people and developers must work together daily throughout the project.
  8. -
  9. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  10. -
  11. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  12. -
  13. Working software is the primary measure of progress.
  14. -
  15. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  16. -
  17. Continuous attention to technical excellence and good design enhances agility.
  18. -
  19. Simplicity–the art of maximizing the amount of work not done–is essential.
  20. -
  21. The best architectures, requirements, and designs emerge from self-organizing teams.
  22. -
  23. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  24. -
- -

Common Questions About Agile

- -

Q: What’s the difference between Agile and Waterfall?

- -

A: The so-called Waterfall methodology is a plan-driven approach to software development that requires much analysis, planning, and risky project and product assumptions to be in place before doing actual development. It is inflexible, hostile to change, and has a long history of delivering poor project results. Agile is a new, empirically-based approach that emphasizes frequent interaction with users and an iterative approach to creating a customer solution. Agile embraces change during a project, lowers risk, and generally improves the ROI of software development investments.

- -

Q: What’s the difference between Agile and Lean?

- -

A: Lean manufacturing is the public version of the Toyota Production System, developed in the years following WWII in Japan with important contributions from American pioneer W. Edwards Deming. Lean is a method of organizational and process improvement aimed at removing waste from the process of building value for customers. Lean rests on the twin pillars of Respect for People and Continuous Learning. Agile has its conceptual roots in Lean but focuses most specifically on software development and provides a framework for a different cultural approach.

- -

Q: What’s the difference between Scrum or Kanban or Extreme Programming (XP)?

- -

A: Scrum and eXtreme Programming are two Agile methodologies that provide very specific direction on how to build software in a way that is consistent with Agile principles. Kanban is a method of process management and improvement that comes from Lean. Each of them provides a disciplined approach to the process of software development and all of them come from a different fundamental framework than Waterfall.

- -

Deeper Dive

- - - - - -
-
-
- - - diff --git a/_site/primers/human-centered-design/index.html b/_site/primers/human-centered-design/index.html deleted file mode 100644 index f439797..0000000 --- a/_site/primers/human-centered-design/index.html +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Human-Centered Design (HCD) - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Human-Centered Design (HCD)

-

Definition

- -

The short version is that human centered design is about solving problems for (wait for it), humans. As IDEO puts it:

- -
-

It’s a process that starts with the people you’re designing for and ends with new solutions that are tailor made to suit their needs. Human-centered design is all about building a deep empathy with the people you’re designing for; generating tons of ideas; building a bunch of prototypes; sharing what you’ve made with the people you’re designing for; and eventually putting your innovative new solution out in the world.

-
- -

Human-centered design consists of three phases. In the Inspiration Phase you’ll learn directly from the people you’re designing for as you immerse yourself in their lives and come to deeply understand their needs. In the Ideation Phase you’ll make sense of what you learned, identify opportunities for design, and prototype possible solutions. And in the Implementation Phase you’ll bring your solution to life, and eventually, to market. And you’ll know that your solution will be a success because you’ve kept the very people you’re looking to serve at the heart of the process.

- -

Key Resources

- -
    -
  • Learn more about Human Centered Design at IDEO
  • -
- -

Key Terms

- -
    -
  • Design Thinking. A human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.
  • -
  • Frameworks. Visual representations of a system used to highlight key relationships and develop strategy.
  • -
  • Prototype Quickly created, representations of a product, program, or service to test a hypothesis or assumption about the usability and/or functionality of a feature or set of features.
  • -
- -

History

- -

Human Centered Design was popularized in the 1990s by the Standford d.school and the design company IDEO. HCD was an evolution of participatory and cooperative design which is built upon various disciplines like anthropology, sociology, and psychology. The principles of human centered design are:

- -
    -
  1. Focus on Human Values. Empathy for the people you are designing for and feedback from these users is fundamental to good design
  2. -
  3. **Craft Clarity. **Produce a coherent vision out of messy problems. Frame it in a way to inspire others and to fuel ideation.
  4. -
  5. Embrace Experimentation. Prototyping is not simply a way to validate your idea; it is an integral part of your innovation process. We build to think and learn.
  6. -
  7. Be Mindful Of Process. Know where you are in the design process, what methods to use in that stage, and what your goals are.
  8. -
  9. Bias Toward Action. Design thinking is a misnomer; it is more about doing that thinking. Bias toward doing and making over thinking and meeting.
  10. -
  11. Radical Collaboration. Bring together innovators with varied backgrounds and viewpoints. Enable breakthrough insights and solutions to emerge from the diversity.
  12. -
- -

Common Questions About HCD

- -

Q: What’s the difference between Design Thinking and HCD?

- -

A: Technically speaking, design thinking is simply thinking and creating like a designer, though it may or may not be centered on the people for whom you’re designing since there are many design methodologies. However, in practice, we use the terms interchangeably and most people mean “human-centered design” when they say “design thinking” and mean “design thinking” when they say “human-centered design.” We will use the terms interchangeably as well.

- -

Deeper Dive

- - - - - -
-
-
- - - diff --git a/_site/primers/index.html b/_site/primers/index.html deleted file mode 100644 index e9851bf..0000000 --- a/_site/primers/index.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Primers - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Primers

-

Understanding these five practices and concepts can help improve the digital acquisition capability of your teams. These are:

- - - - -

Leave a comment on this page

- - -
-
-
- - - diff --git a/_site/primers/lean-startup/index.html b/_site/primers/lean-startup/index.html deleted file mode 100644 index 85d9920..0000000 --- a/_site/primers/lean-startup/index.html +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Lean Startup - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Lean Startup

-

Definition

- -

Lean methodology can be summed up as the process of creating more value for customers and reducing waste. Lean Startup is a methodology, coined by Eric Reis, to shorten their product development cycle by using hypothesis driven experimentation and continous improvment through iterative product releases and validated learning. The distinct characteristics of lean startup are experimentation (instead of elaborate planning), customer feedback (instead of intuition), and iterative design (instead of doing big design up front). This is the crux of the build-measure-learn loop.

- -

Key Resources

- - - -

Key Terms

- -
    -
  • Actionable Metrics: Metrics used to help determine outcomes of experiments and better understand product performance. These metrics tie “specific and repeatable actions to observed results.
  • -
  • Innovation Accounting: An accounting method to figure out if a startup is making a progress before there is enough gross numbers for traditional accounting to kick in. It is a way to define, measure, and communicate outcomes to stakeholders.
  • -
  • Minimum Viable Product: As Ash Maurya states, a Minimum Viable Product is the smallest thing you can build that delivers a customer value (and as a bonus captures some of that value back).
  • -
  • Pivot: A structured course correction taken by an organization designed to test a new fundamental hypothesis about the product, strategy, and engine of growth.
  • -
  • Validated Learning: Determining pivot or preservere decision using actionable metrics from experiments.
  • -
- -

History

- -

When you hear Lean [insert noun] you can thank our friends over at Toyota. Taiichi Ohno started working as an engineer at Toyota motor company in 1943 and is considered the father of the Toyota Production System (TPS), also known as just-in-time production. His system was devised to eliminate the eight common forms of waste.

- -

This philosophy has been applied to other industries such as Lean Thinking, Lean UX, Lean Startup, Lean Product Design, etc. These are all just lean principles applied to different contexts. The Lean processes are to help you when you are refining a process or find solutions when the product, customer, or business models are not well defined.

- -

Lean Startup was coined by Eric Ries which is a principled approach to new product development. His work was influenced by Steve Blank’s The Four Steps to Epiphany and it is built upon 5 core principles:

- -
    -
  1. Entreprenueurs are everwhere - and you may be one of them.
  2. -
  3. Entrepreneurship is management -
  4. -
  5. Validated learning - results from running experiments that can test elements of a product vision.
  6. -
  7. Innovation accounting - method of measuring progress, setting up milestones, and prioritizing work when developing
  8. -
  9. Build-measure-learn - the process of turning ideas into products bsed on customer feedback.
  10. -
- -

Common Questions About Lean Startup

- -

Q: How do I decide between using Agile, Lean, and Lean Startup methods?

- -

A: Salim Virani explains it best as, “Agile usually fits better into existing businesses as a way to improve product development when the customer and the need is known. Lean usually makes more sense when a process needs to be improved and managed for effectiveness. Lean Startup usually makes the most sense when the customer, the product, or the ways to grow the business are not well-established.”

- -

Deeper Dive

- - - - - -
-
-
- - - diff --git a/_site/primers/modular-contracting/index.html b/_site/primers/modular-contracting/index.html deleted file mode 100644 index a539dbb..0000000 --- a/_site/primers/modular-contracting/index.html +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Modular Contracting - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Modular Contracting

-

As described in the FAR, modular contracting is, -> intended to reduce program risk and to incentivize contractor performance while meeting the Government’s need for timely access to rapidly changing technology.

- -
-

When using modular contracting, an acquisition of a system of information technology may be divided into several smaller acquisition increments that—

-
- -
-
    -
  1. Are easier to manage individually than would be possible in one comprehensive acquisition;
  2. -
-
- -
-
    -
  1. Address complex information technology objectives incrementally in order to enhance the likelihood of achieving workable systems or solutions for attainment of those objectives;
  2. -
-
- -
-
    -
  1. Provide for delivery, implementation, and testing of workable systems or solutions in discrete increments, each of which comprises a system or solution that is not dependent on any subsequent increment in order to perform its principal functions;
  2. -
-
- -
-
    -
  1. Provide an opportunity for subsequent increments to take advantage of any evolution in technology or needs that occur during implementation and use of the earlier increments; and
  2. -
-
- -
-
    -
  1. Reduce risk of potential adverse consequences on the overall project by isolating and avoiding custom-designed components of the system.
  2. -
-
- -

Definition

- -

As defined in Clinger-Cohen legislation and Executive Order, modular contracting is an acquisition strategy that breaks a large “grand design” program into discrete components that are easier to manage. It provides for the delivery, implementation, and testing of a workable system or solution in discrete increments or modules. Per FAR 39.002, modular contracting “means use of one or more contracts to acquire information technology systems in successive, interoperable increments.”

- -

Key Resources

- - - -

Key Terms

- -
    -
  • Increments. Useful sub-segments of a larger contract that are used to develop and implement discrete products and capabilities related to a larger system.
  • -
  • Modular architecture. A system consisting of discrete but connect components (or modules) that can be replaced, reused, or added to without affecting the rest of the system.
  • -
- -

History

- -

Kodak Eastman is credited with kicking off the trend of IT Outsourcing In 1989 when it entered into a contract with IBM for a 10 years totalling $250 million dollars for data center and PC support. Many other entities, including federal agencies, entered into similarly structured contracts with differing results. By 1996, the Clinger-Cohen Act wanted to modernize IT in the Federal Government and modular procurement was one piece to this modernization.

- -

Modular contracting is contained within FAR Part 39, and provides that by structuring contracts in this way versus single award, high dollar value, long term contracts that several smaller acquisition increments:

- -
    -
  1. Are easier to manage individually than would be possible in one comprehensive acquisition;
  2. -
  3. Address complex information technology objectives incrementally in order to enhance the likelihood of achieving workable systems or solutions for attainment of those objectives;
  4. -
  5. Provide for delivery, implementation, and testing of workable systems or solutions in discrete increments, each of which comprises a system or solution that is not dependent on any subsequent increment in order to perform its principal functions;
  6. -
  7. Provide an opportunity for subsequent increments to take advantage of any evolution in technology or needs that occur during implementation and use of the earlier increments; and
  8. -
  9. Reduce risk of potential adverse consequences on the overall project by isolating and avoiding custom-designed components of the system.
  10. -
- -

Deeper Dive

- - - - -
-
-
- - - diff --git a/_site/primers/open-innovation/index.html b/_site/primers/open-innovation/index.html deleted file mode 100644 index 3c4c880..0000000 --- a/_site/primers/open-innovation/index.html +++ /dev/null @@ -1,131 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Open Innovation - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Open Innovation

-

Definition

- -

The core of open innovation is that agencies can and should activate a broad network of solvers with diverse skill sets to accelerate internal innovation. It is a call for collaboration among agencies and the public noting that shared knowledge and resources will better help solve some of the tougher technology problems we face as a country. Crowdsourcing and competitions are common methods used to spur open innovation.

- -

One of the goals of open innovation is to create a more open government to increase transparency, collaboration, and participation between the government and its citizens. To date, the open innovation portfolio currently consists of Challenge.gov, Citizenscience.gov, Open Opportunities, and the Innovation Lab/Toolkit (Due FY17).

- -

Key Resources

- - - -

Key Terms

- -
    -
  • Challenges and Prize Competitions. With a challenge and prize competition, a “seeker” poses a problem or question to the public and “solvers” respond and submit solutions. An agency pays only for those solutions that meet the criteria and are chosen as winners. Success in these competitions depend on the skill, judgement, and knowledge of the participants and does not wholly rely on chance.
  • -
  • Citizen Science. When the public participates voluntarily in the scientific process with the federal government and nongovernmental organizations, addressing real-world problems in ways that may include formulating research questions, conducting scientific experiments, collecting and analyzing data, interpreting results, making new discoveries, developing technologies and applications, and solving complex problems.
  • -
  • Crowdsourcing. When organizations submit an open call for voluntary assistance from a large group of individuals for online, distributed problem solving.
  • -
  • Hackathons. An event of any length of time where people, usually from varying disciplines, come together to solve problems to a specific topic.
  • -
  • Open Source. Denotes software whose source code is made freely available and can be modified and redistributed. The full defintion for open source can be found here.
  • -
- -

History

- -

Dr. Henry Chesbrough is credited with originating the theory and coining the term “open innovation.” He defines open innovation as “the use of purposive inflows and outflows of knowledge to accelerate internal innovation, and expand the markets for external use of innovation, respectively.” In 2003, his book “Open Innovation: The New Imperative for Creating and Profiting from Technology” he popularized idea but the concept can be traced as far back as the 1714 Longitude Act. As the Longitude Prize states, “in 1714 the British Government offered, by Act of Parliament, £20,000 for a solution which could find longitude to within half a degree (equivalent to 2 minutes of time), and a group later known as the Board of Longitude was set up to assess submissions and offer rewards.” This was an important step in showing the effectiveness of open innovation.

- -

Since those days, open innovation has been used in the federal government by agencies such as NASA, U.S. Agency for International Development (USAID), and the National Science Foundation (NSF). Also, Challenge.gov has supported over 80 agencies by launching 640+ competitions and awarding over $220 million since 2010. Citizenscience.gov supports a community of practice for nearly 300 federal practicinors who share skills, resources and experiences to improve public participation across the government while open opportunities is a platform that crowdsources federal employees to collaborate across agency initiatives.

- -

Common Questions About Open Innovation

- -

Q: What’s the difference between challenges, citizen science, and competitions?

- -

A: See https://www.digitalgov.gov/2015/12/16/challenges-crowdsourcing-citizen-science-whats-the-dif/

- -

Q: What’s the difference between Open Innovation and Open Source?

- -

A: See http://www.idexlab.com/blog/open-source-vs-open-innovation

- -

Deeper Dive

- - - - - -
-
-
- - - diff --git a/_site/process/delivery/index.html b/_site/process/delivery/index.html deleted file mode 100644 index 4f15ba7..0000000 --- a/_site/process/delivery/index.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Delivery - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Delivery

-

Coming soon

- - - -
-
-
- - - diff --git a/_site/process/ignition/index.html b/_site/process/ignition/index.html deleted file mode 100644 index 673d047..0000000 --- a/_site/process/ignition/index.html +++ /dev/null @@ -1,240 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Ignition - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Ignition

-

As an agency is paramount that you build the right digital acquisitions team and provide them with the right training. Your teams should be cross-functional and have a fundamental understanding of agile, lean, human-centered design, and open innovation. It is important to think of this learning as foundational and continuous. Technology changes fast and your team will have to learn to keep pace with it to maintain the market expertise necessary to make smart at digital acquisition decisions.

- -

Key activities include:

- -
    -
  • Identifying Key Roles
  • -
  • Training
  • -
- -

At the end of this phase you should have:

- -
    -
  • A cross functional team to work on the digital acquisition
  • -
  • Identified gaps in skills on the team and a plan to address them
  • -
  • Provided training and resources to get the team up to speed on the fundamentals of digital
  • -
- -

We have created introductory primers on agile, lean, human-centred design, and open innovation to help you and your team become more familiar with those concepts. We have also identified roles and skills that would be helpful to have on your cross-functional teams.

- -

Why Build Cross-Functional Teams?

- -

Avengers assemble! All acquisitions are hard work but with the right team gathered, it becomes so much easier. Using cross-functional teams will help. A cross-functional team is one which has all of the skills necessary to deliver a small unit of completed value. Cross-functional teams will help your agency make decisions quicker, deliver work sooner and with fewer defects, improve communication flow on projects, and promote knowledge sharing. This has worked across agencies like HHS, USDS, and 18F to improve their digital acquisition capacity.

- -

Some of the key roles for a digital acquisitions team are:

- - - -

Some of the super powers needed to ensure the best chance of success are:

- -
    -
  • Have experience or willingness to participate fully in collaborative cross-functional teams
  • -
  • Enjoy decision-making
  • -
  • Have experience in collaborative problem-solving and thinking in teams
  • -
  • Be familiar with, or curious about, lean and agile methods
  • -
  • Be willing to engage and learn
  • -
  • Be comfortable with periods of ambiguity
  • -
  • Enjoy delivering on timelines
  • -
  • Willing to teach, coach, and learn from teammates and peers
  • -
- -

You should also look for these types of skills in each role when assembling your cross-functional team.

- -

A special note about cross-functional teams: *individuals can serve in multiple roles depending on their skillset. Your core team should have many of these skills but feel free to pull in extra help from around your agency when necessary to further support your team. Use this as a guide to choosing team members for the digital acquisitions pilots. *

- -

Architect / Engineer

- -
    -
  • Be familiar with Agency alternatives and options for system deployment
  • -
  • Participate in code review, architecture discussions, and feature prioritization.
  • -
  • Work with other members of the distributed team to identify and solve complex technical, cultural, and organizational issues.
  • -
  • Participate in or lead (as appropriate) an open dialogue with representatives from stakeholder groups in implementing modern development standards, including transparency, user-centered design, and agile methodologies; understand and communicate the “why” of these standards, not just the “what.”
  • -
  • Use usability research, analytics, and other metrics to influence project planning and design.
  • -
  • Deliver projects that are easy to deploy, update, and monitor by ensuring the tooling for this is present early in the project development cycle
  • -
- -

User Research and Experience Design

- -
    -
  • Create a product user research plan using modern interaction design patterns and best practices, understanding that there are exceptions to every rule.
  • -
  • Clearly explain user-centered design methods and their value to non-designers, including newcomers to the idea of iterative design.
  • -
  • Collaborate on cross-functional teams using agile or lean sprints while guiding them toward a strategic vision.
  • -
  • Communicate ideas clearly in visual form using wireframes, site maps, flowcharts, storyboards, or other methods to guide development.
  • -
  • Pursue continuing engagement with actual users.
  • -
  • Effectively manage time, whether timelines speed up or hit unexpected slow downs.
  • -
  • Set realistic expectations for recruiting research participants and conducting research clearly and explicitly with collaborators; ask for help before a crisis strikes.
  • -
- -

Product Strategy

- -
    -
  • Build meaningful relationships with clients and help them understand user-centered, iterative approach to understanding the problem and building the solution.
  • -
  • Ensure that the team is solving the right problem and not just a symptom of a problem.
  • -
  • Make sure the vendors and the customers are fully engaged members of the team
  • -
  • Manage expectations with stakeholders.
  • -
  • Use evidence (user research, analytics, and other metrics) to make product decisions, ask “why” a lot, and recognize the difference between “we can’t do that because of bureaucracy” and “we can’t do that because of the law.”
  • -
  • Practice lean and agile as an implementation philosophy approach and apply user-centered design methods to ensure we’re building the right product.
  • -
  • Work with other teams, the agency, and partner organizations to ensure compliance with federal regulations such as Authority to Operate, the Paperwork Reduction Act, and Section 508.
  • -
- -

Acquisition / Procurement

- -
    -
  • Work with the Integrated Project Team to develop contracting vehicles that work well with agile development practices.
  • -
  • Be knowledgeable about innovative and modular contracting practices, the FAR, and the TechFAR, the Digital Service Playbook,and related documents and agile acquisition guidance.
  • -
  • Be willing to adopt, deploy, and manage innovative and modular contracting alternatives within the Agency.
  • -
  • Experience utilizing agile acquisitions or innovative acquisition principles is a plus!
  • -
  • Be trained as a CO, COR, or FAI-PM. FAI-PM/IT or DITAP background is a plus!
  • -
- -

Data Management

- -
    -
  • Participate in code review, architecture discussions, and feature prioritization.
  • -
  • Review designs for ability to securely store and manage the type, volume, and velocity of data to be collected.
  • -
  • Apply API design and deployment (as needed) to ensure that the project will successfully interoperate with other projects.
  • -
  • Advise team on methods for interacting with, and testing interfaces to, existing data stores.
  • -
  • Work with Security Office to ensure that the product conforms to Agency requirements, and to ensure that the product can be meaningfully tested and easily certified.
  • -
- -

Cybersecurity / Operations

- -
    -
  • Work with Security Officers to ensure that the product conforms to Agency requirements, and to ensure that the product can be meaningfully tested and easily certified.
  • -
  • Participate in code review, architecture discussions, and feature prioritization.
  • -
  • Be knowledgeable about possible delivery platforms, and the requirements for deployment, testing, and monitoring on the selected platforms
  • -
  • Deliver projects that are easy to deploy, update, and monitor by ensuring the tooling for this is present early in the project development cycle.
  • -
- -

Policy and Law

- -
    -
  • Be knowledgeable about innovative and modular contracting practices, the FAR, and the TechFAR.
  • -
  • Well versed in Federal Appropriations Law and able to advise in agile acquisitions.
  • -
  • Knowledgeable about Agency-specific regulations.
  • -
  • Be committed to using appropriate contracting approaches that will work well with agile development practices.
  • -
  • Be willing to advise Contracting, the Product Managers and the Project Managers in their interactions with vendors in order to minimize problems.
  • -
  • Available and committed to working in a team/collaborative environment in order to maximize communications and minimize delays while completing a contracting cycle.
  • -
- -

Agile Project Management

- -
    -
  • Establish a shared vision and understanding across the team; ensure all members of the team have a shared understanding of the project’s objectives and goals.
  • -
  • Actively engage with the team at large: take part in cross-project and cross-domain conversation, skill- and knowledge-sharing, and working groups.
  • -
  • Make sure the vendor and the customers are fully engaged members of the team
  • -
  • Brief stakeholders—up, down, and sideways—about the progress of the Pilot.
  • -
  • Determine the size, skills, and roles necessary for a team to deliver the solution for the project, and then help identify those team members.
  • -
  • Focus team efforts toward current goals and priorities.
  • -
  • Revisit and revise project direction based on the outcome of experiments and user-based learning.
  • -
  • Manage QA and testing to make sure the team is building to the right level of quality; establish the bar for quality and the definition of done.
  • -
- -

Once you have decided on a team you will need to determine which areas they could use extra training on.

- -

Team Collaboration

- -

For this process to work, it is going to be important that you move together as a team to move the pilot forward. Here are some ground rules that we have found help with team work:

- -
    -
  • Keep the project first. Push your personal ego and pride to the side and always make decisions based on what would be best for the project.
  • -
  • Be open and transparent. Each team member should understand the process and how decisions are made within the team. Keeping everyone informed and providing mechanisms to integrate new ideas will help improve team dynamics.
  • -
  • Overcommunicate. First, the team should agree on the best way to facilitate communication and second, the team should follow it. The aim here is clarity and by over communicating, the team will be able to push the project forward whether they are in the room together or working asynchronously.
  • -
  • Meet with a purpose. Time is always of the essence so be sure to have a clear agenda and desired outcomes for meetings.
  • -
  • Create a safe space for ideas. Do not be afraid as a team to try something new and be willing to listen to new approaches to solve the problems in front of you.
  • -
  • Appreciate candor. Allowing space for team members to speak directly about what is working and what is not working will help speed up the workflow.
  • -
  • **Value other disciplines. **Each team member will bring something valuable to the team based on their experience and expertise.
  • -
- - - -
-
-
- - - diff --git a/_site/process/inception/index.html b/_site/process/inception/index.html deleted file mode 100644 index 6240c5f..0000000 --- a/_site/process/inception/index.html +++ /dev/null @@ -1,254 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Inception - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Inception

-

Inception, a term adapted from agile development, is a short, days long discovery spike used to define the key inputs needed to create a more informed solicitation for your digital acquisition. The goal of inception is to quickly align your digital acquisitions team around a shared understanding of who the end users are, the problem you are trying to solve, and a vision for how the product will best serve end users and your organization over time. Inception allows your team to create improved solicitations based on prioritized, actionable user stories and focused product objectives. The entire cross-functional team and key stakeholders should be involved for the entirety of the inception phase and this should occur before your contracting officers begin to develop the solicitation.

- -

Key activities include, but are not limited to:

- -
    -
  • Creating proto-personas
  • -
  • Deconstructing the problem
  • -
  • Drafting a problem statement
  • -
  • Capturing assumptions and hypotheses
  • -
  • Identifying the Minimum Viable Product (MVP)
  • -
  • Defining a product vision
  • -
  • Determining a product strategy
  • -
  • User story mapping
  • -
- -

Creating proto-personas

- -

Overview

- -

In order to identify your key users and to ensure alignment among the team during inception, create proto-personas. Proto-personas are:

- -
    -
  • A variation of personas used develop early design hypotheses
  • -
  • An encapsulation of the organization’s beliefs about who is using your product or service and what is motivating them to do so
  • -
  • Used to initiate and reinforce awareness of the end user’s point of view during strategic planning
  • -
- -

It is also important to note that although proto-personas are a valuable tool, they are not:

- -
    -
  • A substitute for heavily researched personas based on feedback from actual users of the product
  • -
  • Validated representations of the organization’s target audience
  • -
- -

If your team or program have already created actual personas (ones based on end user research) for the product, those can be used in place of creating proto-personas for inception.

- -

How-to Guide

- -

Steps for creating proto-personas:

- -
    -
  1. Individually, each team member should spend a few minutes listing out all of the different types of users for the product which come to mind. Everyone should focus on listing end users, people who will actually use the product when it is built.
  2. -
  3. In small groups of 2, each pairing should discuss the users they have identified and list key information about each such as demographics, needs and goals, and behaviors. Each type of user should also have a name and a quick sketch associated with it.
  4. -
  5. Bring the full team back together to discuss each user type the pairings have created. After each have been discussed, narrow the list down to no more than five to focus on for this product. This can be done using dot voting or any other prioritization technique.
  6. -
  7. Once you have prioritized the proto-personas you plan to focus on as a team, determine which attributes would be most important to consider across all user types.
  8. -
  9. For each attribute you choose, rank each of the prioritized proto-personas against that attribute.
  10. -
  11. Document your team’s final output for each of the prioritized proto-personas digitally so that will be easier to share and reuse in future conversations. The final proto-personas should include a name, sketch, key demographic information, needs and goals of that person in relation the product, and list of their behaviors.
  12. -
- -

Resources

- - - -

Deconstructing the Problem

- -

Overview

- -

When developing new products, processes, programs, most agencies are not sufficiently rigorous in defining the problems they are attempting to solve and articulating why those issues are important across the organization and to vendors. Agencies often miss opportunities, waste resources, and end up pursuing innovation initiatives that aren’t properly aligned with their core mission because they have not properly understood the problem.

- -

Problem deconstruction helps focus your team at the beginning of a new project and ensures that you are solving the right problem and tackling it in the right way with your acquisition strategy. In the end, your team should be able to answer the following questions:

- -
    -
  • What is the solvable problem?
  • -
  • Who has the problem or who is the customer?
  • -
  • What form should the final solution take? What is the scope (in time, money, resources, technologies) that can be used to solve the problem?
  • -
  • What barriers and constraints exist to solving this problem?
  • -
- -

How-to Guide

- -

Creating a Problem Statement

- -
    -
  1. Understand your team’s current understanding of the problem by answering the “Campfire Questions”: -
      -
    1. What problem are we solving for our users?
    2. -
    3. Why is solving it important?
    4. -
    5. Why now?
    6. -
    -
  2. -
  3. As a group, draft a problem statement based on the assumptions and current understanding of the problem from your team.
  4. -
  5. Use the CATWOE Analysis to identify the people, processes, and environment that contributes to the problem.
  6. -
  7. If stuck, use the Five Ws (Who, What, When, Where Why) and H to answer fundamental questions about your products.
  8. -
  9. Identify barriers and constraints that may have prohibited to this problem from being solved previously. Barriers are obstructions that can be overcome (like a fence) while constraints are limiting factors that can’t be overcome.
  10. -
  11. Reframe the problem statement to answer these questions: -
      -
    1. What is the solvable problem? This should explain why the team is needed.
    2. -
    3. Who has the problem or who is the customer? This should explain who needs the solution and who will decide the problem has been solved.
    4. -
    5. What form should the final solution take? What is the scope (in time, money, resources, technologies) that can be used to solve the problem?
    6. -
    7. What barriers and constraints exist to solving this problem?
    8. -
    -
  12. -
- -

Resources

- - - -

Developing a Product Vision and Strategy

- -

Overview

- -

In the words of Jim Highsmith, for any project, but particularly those with high uncertainty for which significant requirements changes are anticipated, creating a product vision statement helps teams remain focused on the critical aspects of the product, even when details are changing rapidly. A product strategy describes how all of the product principles, statements of the value a product embodies, fit together. These help your teams maintain the coherence of decisions being made over time within changing circumstances.

- -

How-to Guide

- -

Developing a Product Vision and Strategy

- -
    -
  1. Capture assumptions and hypotheses shared by the team about your product or service. Write down everything you know about the product and reference source of knowledge if possible on sticky notes.
  2. -
  3. Analyze the sticky notes and organize them into groups based. Each group should be given a label.
  4. -
  5. Determine the minimum viable product (MVP) by identifying key features on sticky notes and prioritizing them as a group with an activity like dot voting.
  6. -
  7. Identify success criteria for each of the prioritized features. Success criteria are the factors that help your team determine if the feature is meeting the desired objectives. As a team, identify the success criteria that are both critical and measurable.
  8. -
  9. Identify any challenges and risks associated with the MVP.
  10. -
  11. Design a Product Box which assumes the product will be sold in a shrink wrapped box and your team needs to come up with a product name, graphic, 3-4 key bullet points to “sell” the product, a detailed feature description on the back, and operating requirements.
  12. -
  13. Draft a product vision statement. The vision statement should answer the following: -
      -
    1. For (people served)
    2. -
    3. Who (statement of the need or opportunity to fulfill mission)
    4. -
    5. The (product name) is a (product category)
    6. -
    7. That (key benefit, compelling reason to change)
    8. -
    9. Unlike (existing product)
    10. -
    11. Our product (statement of primary differentiation)
    12. -
    -
  14. -
- -

Resources

- - - -

User Story Mapping

- -

Overview

- -

A user story map is a visualization of the user’s journey through the product that you’re designing. It keeps your users and what they’re doing with the product the focus of your planning, not the features the product has.

- -

User stories are typically organized in a product backlog–a list of prioritized objectives which helps teams understand what features to develop over time. Teams work with the product owner to rank the backlog of user stories. Usually this results in a linear product backlog. which makes it hard to understand and explain to others what the product does. It also adds extra complexity to release planning in Agile. The story map makes it much easier to tell a user’s story.

- -

There’s a formula to build a user story map: users have a vision, which are achieved by goals. Their goals are reached by completing activities, and to complete an activity users must perform tasks. At the top of the whole story map is the users who are at the center of the journey, and the tasks are laid out according to the sequence of time on the X axis, and the priority of the tasks on the Y axis.

- -

[insert image if possible]

- -

How-to Guide

- -

To create a user story map, you will need to have at least four different colors of medium-sized sticky notes, Sharpies, a large blank wall or poster boards. You’ll be making many sticky notes and moving the sticky notes around, so make sure that you have large wall space. Below are the steps to create a user story map:

- -
    -
  1. Capture each proto-personas on separate sticky notes, starting with users that interact with the project the most. Place each of the prioritized personas in a linear line along the X axis on the wall or poster board at the top according to the highest priority to the left, and the lowest on the right side. Multiple personas can be used if they have the same goals at heart.
  2. -
  3. Identify the goals that each user is trying to accomplish. Each goal should be written on a separate color sticky note than the personas, and should be kept at a high level. There may be one or several different goals of that user–make sure you account for all the goals for that user.
  4. -
  5. Under each of the goals list specific tasks of the specific users above. Each of the goals should have several activities to complete the overarching goal. In the diagram below, each of the goals have specific activities that are directly related to and map back to the goals of that user. Activities usually start with an actionable verb followed by a noun.
  6. -
  7. For each activity, identify the tasks that  comprise that activity. Tasks also should start with a verb, but are more descriptive than activities.
  8. -
  9. Determine a release planning strategy by highlighting the features that encompass your MVP.
  10. -
- -

Resources

- - - - - -
-
-
- - - diff --git a/_site/process/index.html b/_site/process/index.html deleted file mode 100644 index e01264c..0000000 --- a/_site/process/index.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Process - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Process

-

The digital acquisitions process can be broken up into different phases which are:

- -
    -
  • Ignition - Building out your team and basic training.
  • -
  • Inception - Developing a product strategy and vision.
  • -
  • Procurement - Planning and executing a procurement plan.
  • -
  • Delivery - Working with vendors to produce the product.
  • -
  • Landing - Capturing results and lessons learned.
  • -
- - -

Leave a comment on this page

- - -
-
-
- - - diff --git a/_site/process/landing/index.html b/_site/process/landing/index.html deleted file mode 100644 index 3ed76f0..0000000 --- a/_site/process/landing/index.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Landing - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Landing

-

Coming soon

- - - -
-
-
- - - diff --git a/_site/process/procurement/index.html b/_site/process/procurement/index.html deleted file mode 100644 index 58eabef..0000000 --- a/_site/process/procurement/index.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - - - Digital Acquisition Playbook - Procurement - - - - - - - - - - - - - - - - - - - - - - Skip to main content - - -
- -
-
-

Procurement

-

Coming soon

- - - -
-
-
- - - diff --git a/_site/stylesheets/fixedsticky.css b/_site/stylesheets/fixedsticky.css deleted file mode 100755 index 57606ea..0000000 --- a/_site/stylesheets/fixedsticky.css +++ /dev/null @@ -1,22 +0,0 @@ -.fixedsticky { - position: -webkit-sticky; - position: -moz-sticky; - position: -ms-sticky; - position: -o-sticky; - position: sticky; -} -/* When position: sticky is supported but native behavior is ignored */ -.fixedsticky-withoutfixedfixed .fixedsticky-off, -.fixed-supported .fixedsticky-off { - position: static; -} -.fixedsticky-withoutfixedfixed .fixedsticky-on, -.fixed-supported .fixedsticky-on { - position: fixed; -} -.fixedsticky-dummy { - display: none; -} -.fixedsticky-on + .fixedsticky-dummy { - display: block; -} \ No newline at end of file diff --git a/_site/stylesheets/fonts/icomoon.eot b/_site/stylesheets/fonts/icomoon.eot deleted file mode 100755 index 1e5ae75..0000000 Binary files a/_site/stylesheets/fonts/icomoon.eot and /dev/null differ diff --git a/_site/stylesheets/fonts/icomoon.svg b/_site/stylesheets/fonts/icomoon.svg deleted file mode 100755 index 3ca6cd7..0000000 --- a/_site/stylesheets/fonts/icomoon.svg +++ /dev/null @@ -1,14 +0,0 @@ - - - -Generated by IcoMoon - - - - - - - - - - \ No newline at end of file diff --git a/_site/stylesheets/fonts/icomoon.ttf b/_site/stylesheets/fonts/icomoon.ttf deleted file mode 100755 index 2b8701e..0000000 Binary files a/_site/stylesheets/fonts/icomoon.ttf and /dev/null differ diff --git a/_site/stylesheets/fonts/icomoon.woff b/_site/stylesheets/fonts/icomoon.woff deleted file mode 100755 index a0bc024..0000000 Binary files a/_site/stylesheets/fonts/icomoon.woff and /dev/null differ diff --git a/_site/stylesheets/fonts/selection.json b/_site/stylesheets/fonts/selection.json deleted file mode 100755 index 9ac7143..0000000 --- a/_site/stylesheets/fonts/selection.json +++ /dev/null @@ -1,152 +0,0 @@ -{ - "IcoMoonType": "selection", - "icons": [ - { - "icon": { - "paths": [ - "M658.286 475.429q0-105.714-75.143-180.857t-180.857-75.143-180.857 75.143-75.143 180.857 75.143 180.857 180.857 75.143 180.857-75.143 75.143-180.857zM950.857 950.857q0 29.714-21.714 51.429t-51.429 21.714q-30.857 0-51.429-21.714l-196-195.429q-102.286 70.857-228 70.857-81.714 0-156.286-31.714t-128.571-85.714-85.714-128.571-31.714-156.286 31.714-156.286 85.714-128.571 128.571-85.714 156.286-31.714 156.286 31.714 128.571 85.714 85.714 128.571 31.714 156.286q0 125.714-70.857 228l196 196q21.143 21.143 21.143 51.429z" - ], - "attrs": [], - "isMulticolor": false, - "width": 951, - "tags": [ - "search" - ], - "grid": 0 - }, - "attrs": [], - "properties": { - "order": 1, - "id": 0, - "prevSize": 28, - "code": 59648, - "name": "search" - }, - "setIdx": 0, - "setId": 2, - "iconIdx": 0 - }, - { - "icon": { - "paths": [ - "M864 0c88.364 0 160 71.634 160 160 0 36.020-11.91 69.258-32 96l-64 64-224-224 64-64c26.742-20.090 59.978-32 96-32zM64 736l-64 288 288-64 592-592-224-224-592 592zM715.578 363.578l-448 448-55.156-55.156 448-448 55.156 55.156z" - ], - "attrs": [], - "tags": [ - "pencil", - "write", - "edit" - ], - "defaultCode": 57357, - "grid": 16 - }, - "attrs": [], - "properties": { - "id": 64, - "order": 9, - "prevSize": 32, - "code": 59653, - "ligatures": "pencil, write", - "name": "pencil" - }, - "setIdx": 1, - "setId": 0, - "iconIdx": 5 - }, - { - "icon": { - "paths": [ - "M992.262 871.396l-242.552-206.294c-25.074-22.566-51.89-32.926-73.552-31.926 57.256-67.068 91.842-154.078 91.842-249.176 0-212.078-171.922-384-384-384-212.076 0-384 171.922-384 384s171.922 384 384 384c95.098 0 182.108-34.586 249.176-91.844-1 21.662 9.36 48.478 31.926 73.552l206.294 242.552c35.322 39.246 93.022 42.554 128.22 7.356s31.892-92.898-7.354-128.22zM384 640c-141.384 0-256-114.616-256-256s114.616-256 256-256 256 114.616 256 256-114.614 256-256 256z" - ], - "attrs": [], - "tags": [ - "search", - "magnifier", - "magnifying-glass", - "inspect", - "find" - ], - "defaultCode": 57786, - "grid": 16 - }, - "attrs": [], - "properties": { - "id": 532, - "order": 2, - "prevSize": 32, - "code": 59782, - "ligatures": "search, magnifier", - "name": "search_big" - }, - "setIdx": 1, - "setId": 0, - "iconIdx": 134 - }, - { - "icon": { - "paths": [ - "M64 192h896v192h-896zM64 448h896v192h-896zM64 704h896v192h-896z" - ], - "attrs": [], - "tags": [ - "menu", - "list", - "options", - "lines", - "hamburger" - ], - "defaultCode": 58031, - "grid": 16 - }, - "attrs": [], - "properties": { - "order": 8, - "id": 1448, - "prevSize": 32, - "code": 59837, - "ligatures": "menu, list3", - "name": "menu" - }, - "setIdx": 1, - "setId": 0, - "iconIdx": 189 - } - ], - "height": 1024, - "metadata": { - "name": "icomoon" - }, - "preferences": { - "showGlyphs": true, - "showQuickUse": false, - "showQuickUse2": true, - "showSVGs": true, - "fontPref": { - "prefix": "icon-", - "metadata": { - "fontFamily": "icomoon" - }, - "metrics": { - "emSize": 1024, - "baseline": 6.25, - "whitespace": 50 - }, - "embed": false, - "autoHost": true - }, - "imagePref": { - "prefix": "icon-", - "png": true, - "useClassSelector": true, - "color": 4473924, - "bgColor": 16777215, - "classSelector": ".icon" - }, - "historySize": 100, - "showCodes": false, - "gridSize": 16, - "quickUsageToken": { - "UntitledProject": "ODg2YTQyMGM3NmI2Yjg0Mzg1NmExYWY1ODliMGFmNzAjMSMxNDUzMzExNDQ4IyMj" - } - } -} \ No newline at end of file diff --git a/_site/stylesheets/images/grey-noise.gif b/_site/stylesheets/images/grey-noise.gif deleted file mode 100644 index 2064b65..0000000 Binary files a/_site/stylesheets/images/grey-noise.gif and /dev/null differ diff --git a/_site/stylesheets/images/landingham.jpg b/_site/stylesheets/images/landingham.jpg deleted file mode 100644 index e75d6fe..0000000 Binary files a/_site/stylesheets/images/landingham.jpg and /dev/null differ diff --git a/_site/stylesheets/images/svg/book.svg b/_site/stylesheets/images/svg/book.svg deleted file mode 100755 index 07020d0..0000000 --- a/_site/stylesheets/images/svg/book.svg +++ /dev/null @@ -1,7 +0,0 @@ - - - - - - - diff --git a/_site/stylesheets/images/svg/cog.svg b/_site/stylesheets/images/svg/cog.svg deleted file mode 100755 index 8ed966f..0000000 --- a/_site/stylesheets/images/svg/cog.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/fire.svg b/_site/stylesheets/images/svg/fire.svg deleted file mode 100755 index d259708..0000000 --- a/_site/stylesheets/images/svg/fire.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/home.svg b/_site/stylesheets/images/svg/home.svg deleted file mode 100755 index 99b2bec..0000000 --- a/_site/stylesheets/images/svg/home.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/menu.svg b/_site/stylesheets/images/svg/menu.svg deleted file mode 100755 index 70995c1..0000000 --- a/_site/stylesheets/images/svg/menu.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/pencil.svg b/_site/stylesheets/images/svg/pencil.svg deleted file mode 100755 index 98a299c..0000000 --- a/_site/stylesheets/images/svg/pencil.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/price-tag.svg b/_site/stylesheets/images/svg/price-tag.svg deleted file mode 100755 index ab5780c..0000000 --- a/_site/stylesheets/images/svg/price-tag.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/private.svg b/_site/stylesheets/images/svg/private.svg deleted file mode 100755 index c9c5978..0000000 --- a/_site/stylesheets/images/svg/private.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/search.svg b/_site/stylesheets/images/svg/search.svg deleted file mode 100755 index 8b7e927..0000000 --- a/_site/stylesheets/images/svg/search.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/search_big.svg b/_site/stylesheets/images/svg/search_big.svg deleted file mode 100755 index 4cbab12..0000000 --- a/_site/stylesheets/images/svg/search_big.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/user.svg b/_site/stylesheets/images/svg/user.svg deleted file mode 100755 index 3cc506e..0000000 --- a/_site/stylesheets/images/svg/user.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/images/svg/users.svg b/_site/stylesheets/images/svg/users.svg deleted file mode 100755 index eca9513..0000000 --- a/_site/stylesheets/images/svg/users.svg +++ /dev/null @@ -1,7 +0,0 @@ - - - - - - - diff --git a/_site/stylesheets/images/svg/zoom-in.svg b/_site/stylesheets/images/svg/zoom-in.svg deleted file mode 100755 index 3b31831..0000000 --- a/_site/stylesheets/images/svg/zoom-in.svg +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/_site/stylesheets/reset.css b/_site/stylesheets/reset.css deleted file mode 100644 index 71f8447..0000000 --- a/_site/stylesheets/reset.css +++ /dev/null @@ -1,62 +0,0 @@ -/* http://meyerweb.com/eric/tools/css/reset/ - v2.0 | 20110126 - License: none (public domain) -*/ - -html, body, div, span, applet, object, iframe, -h1, h2, h3, h4, h5, h6, p, blockquote, pre, -a, abbr, acronym, address, big, cite, code, -del, dfn, em, img, ins, kbd, q, s, samp, -small, strike, strong, sub, sup, tt, var, -b, u, i, -dl, dt, dd, ol, ul, li, -fieldset, form, label, legend, -table, caption, tbody, tfoot, thead, tr, th, td, -article, aside, canvas, details, embed, -figure, figcaption, footer, header, menu, nav, -output, ruby, section, summary, -time, mark, audio, video { - margin: 0; - padding: 0; - border: 0; - font-size: 100%; - font: inherit; - vertical-align: baseline; -} -/* HTML5 display-role reset for older browsers */ -article, aside, details, figcaption, figure, -footer, header, hgroup, menu, nav, section { - display: block; -} -body { line-height: 1; } -ol, ul { list-style: none; } -blockquote, q { quotes: none; } -blockquote:before, blockquote:after, -q:before, q:after { content: ''; content: none; } -table { - border-collapse: collapse; - border-spacing: 0; -} - -html { - box-sizing: border-box; - font-size: 16px; - font-family: sans-serif; /* 1 */ - -ms-text-size-adjust: 100%; - -webkit-text-size-adjust: 100%; /* Prevent font scaling in landscape while allowing user zoom */ -} - -*, *:before, *:after { box-sizing: inherit; } - -html{ font-size: 16px; } - -sub, -sup { - font-size: 75%; - line-height: 0; - position: relative; - vertical-align: baseline; -} - -sup { top: -0.5em; } -sub { bottom: -0.25em; } diff --git a/_site/stylesheets/screen.css b/_site/stylesheets/screen.css deleted file mode 100644 index 0683589..0000000 --- a/_site/stylesheets/screen.css +++ /dev/null @@ -1,826 +0,0 @@ -/* @override http://localhost:5000/stylesheets/screen.css */ - -/* @group bootstrap */ - -html { - box-sizing: border-box; -} -*, *:before, *:after { - box-sizing: inherit; -} - -body{ - font-family: Source Sans Pro, Verdana, sans-serif; - font-size: 18px; - font-weight: 400; - color: #404040; - background: #f8f8f8; -} - -a{ color: #bd4921; text-decoration: ;} -a:hover{ color: #b7004f; } - -a:visited{ color: #8d0058; } - -.a-skip-to-main{ - position: absolute; - left: -9999em; -} -::selection { - background: #ffe4c5; /* WebKit/Blink Browsers */ -} - -::-moz-selection { - background: #ffe4c5; /* Gecko Browsers */ -} - -.wrapper{ - width: 95%; - max-width: 960px; - margin: 0 auto; - position: relative; -} - -@media screen and (min-width: 336.84px){ .wrapper{ width: 90%; } } - -.wrapper::after{ - content: ""; - display: table; - clear: both; -} - -main{ - background: white; - padding-bottom: 2em; -} - -img { max-width: 100%; } - -/* @group icomoon */ - -@font-face { - font-family: 'icomoon'; - src: url('fonts/icomoon.eot?8ojtgr'); - src: url('fonts/icomoon.eot?8ojtgr#iefix') format('embedded-opentype'), - url('fonts/icomoon.ttf?8ojtgr') format('truetype'), - url('fonts/icomoon.woff?8ojtgr') format('woff'), - url('fonts/icomoon.svg?8ojtgr#icomoon') format('svg'); - font-weight: normal; - font-style: normal; -} - -[class^="icon-"], [class*=" icon-"] { - /* use !important to prevent issues with browser extensions that change fonts */ - font-family: 'icomoon' !important; - speak: none; - font-style: normal; - font-weight: normal; - font-variant: normal; - text-transform: none; - line-height: 1; - - /* Better Font Rendering =========== */ - -webkit-font-smoothing: antialiased; - -moz-osx-font-smoothing: grayscale; -} - -.icon-pencil:before { - content: "\e905"; -} -.icon-menu:before { - content: "\e9bd"; -} - - - -.button, -.button:visited{ - border: 1px solid #d3d3d3; - border-bottom-color: #ccc; - border-radius: 3px; - background: #f8f8f8; - background: linear-gradient(#fff, #eee); - font-family: Source Sans Pro, Verdana, sans-serif; - font-size: 24px; - font-weight: 300; - color: #444; - text-shadow: 0 1px 0 #fff; - padding: 0.4em 1em 0.5em; - -webkit-box-shadow: 0 1px 0 #eee; - float: left; - line-height: 1.33em; - margin-top: 1em; - margin-bottom: 0.8em; - margin-right: 1em; - white-space: nowrap; - cursor: pointer; - text-decoration: none; - -} - - - -.button:hover{ - background: linear-gradient(#fff, #e3e3e3); - border-color: #c3c3c3; - border-bottom-color: #b8b8b8; - text-decoration: none; - color: #333; -} - -.button:active{ - color: #888; - background: linear-gradient(#e3e3e3, #eee); - border-color: #bbb; - border-top-color: #aaa; - border-bottom-color: #b3b3b3; - text-shadow: none; - -webkit-box-shadow: inset 1px 1px 0 #ddd; - -webkit-touch-callout: none; /* iOS Safari */ - -webkit-user-select: none; /* Chrome/Safari/Opera */ - -khtml-user-select: none; /* Konqueror */ - -moz-user-select: none; /* Firefox */ - -ms-user-select: none; /* IE/Edge */ - user-select: none; -} - -/* @end */ - - -/* @end */ - - - -/* @group .site-header */ - -.site-header{ - padding: 4px 0 6px; - border-bottom: 1px solid #006d47; - background: #4d384b; - color: #fff; -} - - -.site-header h1 a{ - font-size: 24px; - color: inherit; - text-decoration: none; - line-height: 40px; - letter-spacing: -1px; - padding: - 2px; -} - -.site-header form, -.search-interface form{ - position: relative; - text-align: right; - margin-top: 4px; - margin-bottom: 6px; -} - -.site-header form .field{ - position: relative; - background-color: #003629; - border-radius: 99em; -} - -.site-header .field .label-text{ - color: #ccc; - left: 50%; - top: 0; - bottom: 0; - right: 0; - z-index: 0; -} - -html body .site-header form input{ - -webkit-appearance: none; - appearance: none; - border: none; - border-radius: 999em; - box-shadow: 0 1px 0 #007f5d; - display: block; - width: 100% !important; - height: 32px; - line-height: 26px !important; - font: inherit; - font-size: 18px !important; - padding: 0; - padding-left: 28px !important; - color: #aaa; -} - -*::-webkit-input-placeholder{ - color: #aaa; - -} -input[type="search"]::-webkit-search-cancel-button { -webkit-appearance: none; } - -input[type="search"]:focus::-webkit-search-cancel-button::after{ - content: "\00D7"; - display: block; - text-align: center; - height: 0.8em; - width: 0.8em; - line-height: 0.82em; - font-size: 18px; - border-radius: 100%; - margin-right: 6px; - background-color: #fff; - color: #000; -} - -.site-header form label::before, -.search-interface form label::before{ - content: "\e900"; - font-family: 'icomoon' !important; - speak: none; - font-size: 14px; - font-style: normal; - font-weight: normal; - font-variant: normal; - text-transform: none; - text-shadow: -1px -1px 1px rgba(0,0,0,0.02); - line-height: 1; - position: absolute; - bottom: 9px; - top: auto; - left: 10px; - color: white; - position: absolute; - margin-top: -0.5em; -} - -.site-header form .is-focused input, -.search-interface form .is-focused input, -.site-header form .is-focused label::before, -.search-interface form .is-focused label::before{ - color: white; -} - -.site-header form button{ - position: absolute; - left: -9999em; - bottom: 3px; - border: 1px solid #ddd; - border-radius: 2px; - background: #f8f8f8; - font: inherit; - font-weight: 600; - font-size: 16px; - color: #555; - padding: 4px 12px; - height: 2.33em; - -} - -.site-header form button:hover{ - background-color: #eee; - color: #111; - border-color: #bbb; - cursor: pointer; -} - -.site-header div.signed-in{ - top: 0; - right: 0; - position: absolute; - padding: 8px 8px 8px 44px; - font-size: 14px; - line-height: 1.2; - width: 192px; - border: 1px solid transparent; -} - -.site-header div.signed-in:hover{ - background: linear-gradient(#fbf9f4, #f0ede7); - border-color: #ebe8e0; - border-bottom-color: #dbd5c8; - cursor: pointer; - -webkit-box-shadow: inset 1px 1px 0 #fff; -} - -.site-header div.signed-in h1{ - font-size: 9px; - text-transform: uppercase; - font-family: Lucida Grande; - color: #555; - position: relative; - left: 1px; - margin-top: 1px; -} - -.site-header div.signed-in img{ - width: 32px; - height: 32px; - border-radius: 100%; - position: absolute; - left: 6px; - top: 5px; -} - -.site-header div.signed-in a{ - margin-left: 0.4em; - font-size: 14px; - color: #8f8466; -} - -@media screen and (min-width: 568.88px){ - .site-header .logo{ - float: left; - margin-bottom: 0; - white-space: nowrap; - overflow: hidden; - } - - .site-header .search-interface, - .banner form{ - position: absolute; - right: 0; - left: auto; - top: 0; - } - - .banner form input{ - margin-bottom: 0; - } - - -} - -/* @end */ - -/* @group .site-footer */ - -.site-footer{ - border-top: 1px solid #d8d8d8; - padding-top: 1em; - padding-bottom: 2em; - color: #555; - background: #f8f8f8; -} - - -/* @end */ - -/* @group .page */ - -.page{ padding-top: 1em; } - -.page .wrapper{ - width: auto; - max-width: none; -} - -.page .page-title, -.page h1, -.page h2, -.page h3, -.page h4, -.page h5, -.page nav, -.page figure, -.page p, -.page ul, -.page ol, -.page dl, -.page li{ - line-height: 1.4em; - margin: 0 auto 0.7em; - max-width: 640px; - width: 90%; -} - - -.page td{ line-height: 1.4em; } - -.page h1, -.page h2, -.page h3, -.page h4, -.page h5{ - line-height: 1.125em; -} - -.page figure.figure-fill{ - width: 100%; - max-width: none; - text-align: center; -} - -.page ul, -.page ol{ - padding-left: 1.4em; -} - -.page ul ol, -.page ul ul, -.page ol ol, -.page ol ul{ - margin-left: 0; -} - -.page strong{ font-weight: 600; } -.page em{ font-style: italic; } - -a[id]{ - color: inherit; - text-decoration: none; -} - -.page code{ - background: #eee; - border: 1px solid #e3e3e3; - padding: 1px 2px; - font-family: "Courier New", Courier, mono; - font-size: 0.8em; - font-weight: 600; - border-radius: 2px; - color: #d40b79; - top: -1px; - position: relative; - clear: none; -} - -.page aside{ - font-size: 16px; - color: #918c84; - margin-top: 6px; -} - -.page h1, -.page .page-title{ - margin-bottom: 0.67em; - font-size: 36px; - font-weight: 600; - line-height: 1.125em; - color: #383838; - letter-spacing: -1px; - max-width: 640px; - position: relative; - left: -1px; -} - -.page h1+p{ - padding-top: 0.4em; - font-family: merriweather; - line-height: 1.5em; - color: #444; - font-size: 18px; - margin: -1em auto 2em; -} - -.page h2{ - font-weight: 600; - font-size: 21px; - line-height: 1.3em; - font-family: Merriweather, Georgia; - color: #3f7f71; - max-width: 640px; - margin: 28px auto 16px; -} - -.page h3, -.page h4{ - font-weight: 600; - font-size: 21px; - line-height: 1.4em; - margin-top: 28px; - margin-bottom: 16px; - color: #333; -} - -.page h4{ - font: inherit; - font-family: Merriweather, Georgia; - text-transform: uppercase; - font-size: 14px; - font-weight: 600; - color: #222; - letter-spacing: 0.05em; - word-spacing: 0.125em; - margin-top: 24px !important; - margin-bottom: 16px !important; -} - -.location .h-card .p-name{ - position: absolute; - left: -9999em; -} - -.page blockquote{ - padding-left: 1em; - position: relative; - max-width: 640px; - margin: 0 auto; -} - -.page blockquote::after{ - content: ""; - position: absolute; - left: 1px; - top: 0; - bottom: 0; - width: 3px; - background: #e3e3e3; - border-radius: 3px; -} - -.page blockquote p{ - font-family: Merriweather, Georgia, serif; - font-style: italic; - color: #555; - font-size: 17px; - line-height: 1.67em; - width: auto; - max-width: none; -} - -@media screen and (min-width: 568.88px){ - - .page{ padding-top: 1.6em; } - - .page .page-title, - .page h1, - .page h2, - .page h3, - .page h4, - .page h5, - .page figure, - .page p, - .page ul, - .page ol, - .page dl, - .page li{ - width: 90%; - margin-left: auto; - margin-right: auto; - } - .page p, - .page figure, - .page ul, - .page ol, - .page dl, - .page li, - .page td { - margin: 0 auto 0.8em; - line-height: 1.6em; - } - - .page li p{ - margin-left: 0; - width: auto; - } - - .page h1, - .page h2, - .page h3, - .page h4 { - line-height: 1.2em; - } - - .page h1, - .page .page-title{ font-size: 40px; } - .page h1+p, - .page .page-title+p{ - font-size: 20px; - line-height: 1.67em; - } - .page h2{ - margin-top: 28px; - font-size: 21px; - line-height: 1.3em; - } -} - -} - -.page .page-title+h2{ margin-top: 20px; } - -.page hr{ - border: none; - height: 0.2em; - margin-top: 2em; - margin-bottom: 2em; - background: #f2f1ec; - width: 90%; - max-width: 640px; -} - -.page .h-card{ - line-height: 1.33em; - margin: 0 auto 0.6em; - padding: 8px 16px 8px 16px; - border: 1px solid #ddd; - border-radius: 4px; - max-width: 480px; - position: relative; -} - -.page .h-card:last-of-type{ margin-bottom: 1em; } - -.page table{ - border-radius: 3px; - border: 1px solid #eee; - margin: 0 auto; - max-width: 640px; - table-layout: fixed; - box-shadow: 0 0 0 2px #fafafa; -} - -.page .table-wrapper{ - margin: 0 auto 1.8em; - padding-bottom: 0.2em; - max-width: 90%; - overflow: auto; -} - -@media screen and (min-width: 711.11px){ - .page .table-wrapper{ max-width: 640px; } -} - -.page table tbody tr:first-child td:first-child{ - border-radius: 3px; -} - -.page table tbody tr:nth-child(odd) td{ - background: #fafafa; -} - -.page table td, -.page table th{ - border: 1px solid #ddd; - padding: 8px; -} - -.page .h-card .p-job-title{ - clear: left; - display: block; - -} - - -@media screen and (min-width: 711.11px){ - .page .h-card{ - position: relative; - left: -80px; - } -} - -.page .h-card::before{ - content: ""; - position: absolute; - left: 0; - top: 0; - bottom: 0; - width: 6px; - background: #e7f3f4; - border-radius: 5px 0 0 5px -} - -.page .h-card .p-tel{ clear: left; } - -.page li{ - list-style-type: square; - margin-left: 1.125em; - margin-bottom: 0.6em; -} - -.page ol li{ list-style-type: decimal; } -.page ol li li { list-style-type: lower-latin; } -.page ol li a { - text-decoration: none; -} - - -.page ol > li li{ - margin-bottom: 0.2em; -} -.page ol > li li li{ margin-bottom: 0.3em;} - -.page ol .offices a { - color: #aa470f; -} -.page ol .offices a:hover{ - color: #8d0058; - text-decoration: underline; -} - - - -.page table thead td{ font-weight: 300; } - -/* @end */ - -/* @group nav */ - - nav{ - padding: 0.5em 0; - border-bottom: 1px solid #d8d8d8; - line-height: 24px; - background: #fafafa; - } - - nav .wrapper h1{ - content: "Table of contents"; - text-transform: uppercase; - letter-spacing: 0.02em; - font-family: Merriweather, Georgia, Serif; - font-size: 0.8em; - font-weight: 600; - } - - nav .wrapper h1 span.preposition{ - text-transform: lowercase; - font-style: italic; - font-weight: normal; - margin-right: 0.04em; - } - - nav ol{ - list-style-type: decimal; - margin-left: 1.4em; - } - - nav ol ol{ - padding-left: 0.8em; - list-style-type: lower-roman; - } - - .layout-article-overview nav .overview a, - .layout-article-case-study-58-hhs-buyer-rsquo-s-club nav .case-study a, - .layout-article-process nav .process > a, - .layout-article-ignition nav .ignition a, - .layout-article-inception nav .inception a, - .layout-article-procurement nav .procurement a, - .layout-article-delivery nav .delivery a, - .layout-article-landing nav .landing a, - .layout-article-primers nav .primers > a, - .layout-article-about nav .about a, - .layout-article-glossary nav .glossary a, - .layout-article-agile nav .agile a, - .layout-article-lean-startup nav .lean-startup a, - .layout-article-human-centered-design-hcd nav .human-centered-design a, - .layout-article-open-innovation nav .open-innovation a, - .layout-article-modular-contracting nav .modular-contracting a{ - font-weight: 600; - color: #333; - text-decoration: none; - } - - -/* @end */ - -/* @group layouts */ - -/* @group .layout-article */ - -@media screen and (min-width: 817.7777px) { - - .site-header .wrapper{ - width: auto; - max-width: 100%; - padding: 0 1.7em; - } - .layout-article main{ - padding: 0; - padding-left: 320px; - } - - .layout-article main::after{ - content: ""; - display: table; - clear: both; - } - - .layout-article .page, - .layout-article nav{ - float: left; - width: 100%; - } - - .layout-article .page{ - border-left: 1px solid #e3e3e3; - padding-bottom: 2em; - min-height: 22em; - } - .layout-article nav{ - width: 320px; - margin-left: -320px; - border: none; - background: none; - padding: 1em; - } - - .layout-article nav h1{ - margin-bottom: 1em; - } - .layout-article nav ol li{ - margin-bottom: 0.2em; - } -} - - -/* @end */ - -/* @end */