Service Design for Government
Technical Assent Logo
Boy licking an ice cream cone

Avoiding the Sugar Crash of IT Modernization

IT leaders across government are clearly re-energized about IT modernization, thanks to recent legislation, funding, and prioritization. It is a bit like the professional version of the end-of-school-year ice cream party many of us witness as our children set their sights on summer vacation. FedScoop’s IT Modernization Summit in March confirmed this excitement through interviews with more than 20 IT leaders from across government and industry.

Much of the chatter in the beltway about modernizing government technology systems focuses on cloud migration for email and reducing the profile for cyber attackers, but there are some foundational aspects of the way we think about IT modernization that we need to be considering as well. These strategies will push beyond the initial sugar high and into the sustainable successes we need to make IT modernization a reality over the long term.

Earn a seat at the table by framing technology in terms of mission impact

CIOs have long advocated for a “seat at the executive table” but it might not be clear to everyone else why this is so important. Unfortunately, some misguided souls may believe it is to provide a direct link to the help desk, to shepherd a pet project, or to get status updates on ongoing IT projects. Business function leads–like the COO or CFO–who already have a seat at the executive table understand how their key piece impacts the mission and have developed a capability to communicate in those terms. IT executives advocating for a seat at the table must be able to do the same by talking about how technology impacts the mission’s bottom line.

A good example of this comes from a story a colleague of mine shared recently. My colleague–a seasoned executive IT consultant–was meeting with an IT project manager and the IT project manager’s boss, who had responsibility for mission operations. The IT project manager had expressed frustration that outside technical teams had come to the facility to provide periodic system upgrades without giving any prior notice. The complaint began to ramble about how the unexpected outage would impact mean time to repair metrics and cause his team to work overtime that week. The IT project manager’s boss, shrugged off the incident and made it clear that periodic maintenance to IT equipment did not warrant her time and attention.

The executive IT consultant, who has earned a regular seat at the executive table and understands how to talk about technology in mission terms, explaining that the boss had unknowingly assumed specific operational risks during the maintenance period because the operating capability of their key missions systems was being reduced. And because the boss wasn’t aware of what was upgraded, how confident could she be that her mission capabilities were as effective now as they were prior to the upgrade? As our missions become more dependent on IT, so does our ability to effect mission outcomes.  

We are modernizing government services, not technologies

People who use government services care that their problem gets solved with as little effort as possible. Well-designed services should function smoothly and intuitively for its customers. But poorly designed services put the burden on the customers to get the service to function properly. This is too often the result of the false promise of technology – that through the magic of AI, big data, and [insert IT buzzword], we can take poorly designed processes and make them serve people’s needs better.

This is why customer experience is so critical to our IT modernization efforts. The role of customer experience in these IT modernization initiatives is not just designing a better user interface or pushing more short surveys at the point of service – it is fundamentally understanding the services that government provides.  Mat Hunter, Chief Design Officer at the Design Council in the UK, explains the concept as

“[Shaping] service experiences so that they really work for people. Removing the lumps and bumps that make them frustrating, and then adding some magic to make them compelling.”

Technology plays a major role in the way we deliver government services at scale. It impacts the reliability, security, and availability of government services; it provides us the power to customize and tailor the experience individually in real time for billions of people. And yet, for as much we rely on the technology to make the services work, we must always remember that technology is not the end game.  We need to continue to put IT in the service of people and remember that it is just a tool that enables a human-to-human connection to occur faster, more reliably, and more securely.

Innovation comes from deep customer understanding

With $100 million of Technology Modernization Funds on the table, government leaders are vying for some kind of advantage to get a leg up on the competition. I was speaking to a well-known innovation leader last week who indicated she fielded several calls from agencies about whether her team could use “innovation” help them find that next golden egg.

The answer lies within another capability that is already built into the IT modernization framework – service delivery analytics. We need to ask a few key questions about how we are serving our customers today to help target our modernization and improvement efforts for the future:  

  1. “What does the customer care about?”
  2. “What segments of the customer journey are we really good at and how do we ensure that every customer receives that quality service, every time?”
  3. “What are we doing today that causes our customers frustration; most importantly, where does that frustration reach a level where they abandon or disengage?”
  4. “How might we uncover latent demand or untapped potential where there is a need that is not yet being served?

The answers to these questions, at least in part, begin with an understanding of how service delivery is being measured today. Service delivery analytics can be a powerful engine to help resolve immediate customer issues but also help engage customers in an ongoing dialogue about where they are going long term.

It is a tremendous opportunity to follow customer needs and understand the delta between how those needs are met today, how those needs are evolving, and what you need to differently tomorrow in order to meet them.

GSA’s Center of Excellence Director (and Director of Technology Transformation Services and Deputy Commissioner of the Federal Acquisition Service) Joanne Collins Smee remarked at FedScoop’s IT Modernization Summit that

“Agencies need to enhance the capabilities of IT workers who are already in place.”

She also acknowledged USDA’s strategy to bring in top IT talent to help drive culture change across the organization.

Sustaining momentum for long term change in IT modernization

With the current energy and momentum for government IT modernization comes great opportunity. As we continue to position IT modernization for long term success, it is essential that agencies understand these foundational aspects of IT services and continue to expand the capabilities of boundary spanners who can effectively communicate in the language of the technology, the language of the mission, and the language of the customers.

A Technical Assent consultants uses a sheet of paper as a visual aid in presenting a prototype to government employees

Epic Presentation-Fail Yields Real-World Prototyping Lessons for Government

A Technical Assent employee talks with a group of government employees during a prototyping sessionRecently, I traveled to Florida with a co-worker to test some service prototypes with a government audience. Long story short, once we arrived, everything went wrong.

 This wasn’t my first rodeo and, as usual when presenting at someone else’s facility, we had prepared many backups for our technology setup. We had our materials on a hard drive. We them on the cloud. We had them on external media drives and we had emailed files to the our audience in advance. But for one reason or another, none of it worked.

 Fortunately, we had printouts of a paper-based exercise with us, but even the electronic presentation meant to guide participants through that exercise didn’t work. The computer “game” was functioning, but instead of using it on a projector as intended, it could now only be played on a single laptop screen.

 We only had three hours’ time with the group, we needed their feedback, and we’d already traveled six hours to get there. So we proceeded using only what we had. And you know what? It went surprisingly well.

Aside from the obvious embarrassment and frustration of falling prey to Murphy’s Law, the feedback we got from this catastrophic test was just as good—and possibly better—than what we were able to capture in previous tech-enabled tests. Here’s why (and a few of the prototyping lessons for government we learned):

My introduction was reduced to only the most important points

In government work, we tend to demonstrate our understanding of complex bureaucratic frameworks by caveating and referencing everything we say. As consultants, we also tend to spend lots of time reassuring clients that our recommendations come from demonstrable expertise and logic. Therefore, not having a carefully prepared set of slides in this context was daunting—but the format forced brevity, directness, and honesty with the audience. I had only one “slide”: the whiteboard in the room where I’d scribbled a few notes from memory of my PowerPoint presentation.

The result was that the preliminaries were over quickly and after few questions, we were on our way. People were moving around, asking questions, engaging immediately at the start of the event rather than 20 minutes in.

We learned something about the structure of the offering

Rather than having 15 people move through the exercises in order, we broke into small groups. Some of the participants gathered around the laptop for the “game” while others worked through the paper packets.  The results of individual exercises were roughly comparable to results collected from tests done “in order.” As a result, I now understand that a series of exercises we had previously considered to be strictly linear might be rearranged (or possibly made iterative) without seriously impacting the outcome.

Participants’ deeper engagement revealed intrinsic priorities

The clarifications I had to give while we played in the new—unintended—format helped me understand which parts of the presentation really mattered most. The format highlighted what participants understood intuitively and what actually requires additional preparation. The thoughtfulness and level of detail participants put into the feedback demonstrated a much deeper engagement with the prototypes than previous tests.

It was clear what we didn’t yet understand about our own prototypes

The reason? All the answers and directions we gave participants were from memory. Watching our team explain the prototypes from memory gave me not only a list of things to improve about the prototype, but also a better understanding of what kinds of training we’ll need to do with staff to ensure everyone has the basic expertise required to facilitate in a situation like this.

Technical Assent employees use memory and paper simulations after their electronic prototyping models failed during a presentationConclusion: Including these prototyping lessons for government in future events

While I love plans, and believe in the power of technology to support engagement, this “failure” of technology and planning was actually refreshing. My main takeaway from this experience was that rather than preparing presentations in the hopes that nothing breaks, sometimes the thing to do in an iterative design process really is to build the “break” in intentionally. This is a relatively common tactic in design thinking, but one that can still feel foreign and scary in the government consulting space.

I’m already brainstorming effective ways to intentionally get the same kinds of results we got from this “failure.” For others working in government, do you intentionally build in chaos when you test ideas? What works (or doesn’t work) for you? I’d love to hear your ideas.

A group of professionals interact at a table; engaging with customers is key in government service design

In Government Service Design, Thinking Like Your Customer Is Not Enough

Technical Assent’s vision is helping federal government organizations create excellent services. To do this, we emphasize with our government service design teams how important it is to “think like your customer.” What we mean by this is that we should have a good understanding of who our customer is and what they want. But here’s the thing—it’s almost impossible to think exactly like your customer in a realistic way.

My team is in the midst of designing and developing a solution offering that takes incredibly complex problems like rising sea levels and makes them approachable by turning them into collaborative games and exercises. We’ve spent months developing something we thought would make sense to our target client base. Last week, we went off-site and tested our offering twice with two groups of volunteers from government offices. The volunteers ranged from experienced SMEs to junior staff performing support work on the topic area.

The results?

Some people loved what we were doing. Some didn’t understand why we were talking to them in the first place. Some saw opportunities in our vision but identified things they wanted to change.

The Key to Success Government Service Design

Part of the reason consultants and designers spend so much of their time trying to think like their customers is that it’s incredibly hard—nearly impossible—to do. No matter how hard you work to understand your customer base, define personas, identify points of view, and create empathy, the design team is never going to be able to see things exactly like your customers do.

Part of this is the nature of human complexity; people are diverse and hard to predict. Part of this is natural bias on the part of the designer. But here’s the takeaway: no matter how much time you spend trying to think like your customer, the most important part of any design effort is to take the time to test your solution and gain feedback from actual people who are not you and who would conceivably be your customers.

This is not rocket science, but it’s a detail that is easy to forget or skip all together. Sitting in an office and iterating based on the team’s is a lot less work and a lot more comfortable than identifying effective, appropriate ways to test with government customers.

But despite the potential to be uncomfortable, do take this step. Schedule opportunities for real customer feedback early and often, and make sure you listen. After all, seeking customer feedback is not something that is just for private industry; this is absolutely critical to real success in government service design as well.

Lightbulb resting on a small chalkboard with the names of international cities surrounding it

Making Virtual Design-Thinking Efforts Effective in Government

Most design-thinking efforts are conceived and executed as in-person workshops marked by the shoulder-to-shoulder collaboration of participants at whiteboards and a flurry of post-it notes. The design-thinking ethos is premised on the idea that interaction breeds empathy, creativity, and ultimately results in good problem solving.

To be sure, face-to-face interaction is one of the fastest ways to get there, but it isn’t the only way. The need to keep costs low, respect telework agreements, and include global or faraway colleagues in critical solution design are all considerations that demand some level of virtual capability in design-thinking.

There are lots of great firms out there with examples, tools, and kits to help aspiring designers conceive and execute their own design projects (Ideo’s Design Kit, Luma’s Innovation Path, and Accenture Fjord Interactive to name a few). However, virtual design projects require special considerations to be effective.

At Technical Assent, we’ve been facilitating virtual collaboration and design sessions for our clients in the federal government since 2015. We continuously work to improve our capability to facilitate and deliver design-thinking workshops and outcomes for clients – both in person and virtually, nationally and globally. In addition, being a firm with many remote employees, we regularly devote time to practicing virtual design.

There are many advantages and some drawbacks of leveraging virtual collaboration in design efforts, and, here, we are sharing some of our best practices and most important considerations for successful virtual design-thinking efforts.

1. Structuring Your Virtual Design Project

To make virtual collaboration for design projects effective, the most important consideration is structure. The workshop must be structured with participation in mind to avoid remote participants feeling left out or frustrated. If this happens, they will “tune out,” leaving you without the benefit of their ideas and inputs. We consider the following very carefully when structuring a design-thinking effort:

 Spend more time planning.

We have found that the effective execution of a design project in a fully virtual environment or with some remote participants requires twice as long for planning as a traditional design effort. A few of the things that take extra time include:

  • Adapting and testing exercises to the virtual setting
  • Selecting interaction tools and platforms as part of designing the exercise
  • Testing and troubleshooting IT across multiple nodes of activity

 

Choose your activities wisely (and test them!).

We try not to select activities that require lots of space or fast communication. On the other hand, many drawing, symbol, and board-based activities work well. For example, abstraction laddering is very challenging on a small screen but concept posters and “visualize the vote” work very well. We test activities ahead of time to make sure they will work, and as we do so, we identify the “rules of engagement” for the activity.

Think hard about information flow.

Virtual design-thinking efforts require planning to ensure we can move information from one activity or screen to another, and to decide who is responsible for doing what. Knowing your information flow prevents glitches during the event and allows you to have more accurate timing and scheduling.

Consider timing very carefully.

If all your participants are in one room, it’s relatively easy to change a schedule (“Everyone finished early? Ok, let’s start sharing now.”). It’s possible, but not easy, to do the same thing when everyone is behind a computer. Additionally, we find most activities take a little bit longer virtually. Plan your schedule conservatively and try to stick to it.

2. Choosing Collaboration Tools

There are so many great collaboration tools out there right now, it can be dizzying to pick one. Tools have different price points and usability considerations for unfamiliar audiences. Try not to rely on any one platform simply because it’s new or has lots of features. Most tools do some things really well, but no tool does everything well.

Choose your tools based on what you need to get done, your budget, your client’s IT constraints (especially in federal government), and the tech literacy of your participants. You can get great results with simple screen sharing and a conference call, if your activities are well structured and facilitated.

3. Facilitating Your Virtual Design Effort

Facilitation—or leadership—is always important in a design effort. It’s especially important when your group of designers are dispersed and collaborating virtually.

Establish communication ground rules.

Communication is key to good collaboration, and good communication is always just a bit trickier over phones and computers. Consider instituting ground rules before you start to ensure everyone isn’t trying to talk or edit at once. That way all ideas are heard and no one gets frustrated.

Consider your introverted participants.

It’s much easier for shy or quiet participants to fade into the background in a virtual setting. Either be prepared to gently coax ideas out of your less extroverted participants more often than you would in a face-to-face session, or use the relative anonymity of “remote participation” to support individual brainstorming and ideation before participants share with a group.

Be patient.

Technology always requires some troubleshooting and learning before everyone is 100% effective. Be patient, and advise others to be patient as well.

Balance structure with flexibility.

The extra structure required by communication ground rules and careful time planning must be balanced carefully with the need for flexibility to accommodate the innovation process. Try to be cognizant of that balance as you facilitate, and be prepared to have your plan stymied. If you take changes in stride and have a good sense of humor, you (and your participants!) can adapt and still get great results.

Consider hybrid alternatives.

Thinks about if there is a way you can organize the project so that in-person collaboration is only required for a portion of the exercise rather than the whole project. For example, being in-person for a single day at the end of a session instead of the whole time. That way you can take advantage of both methods.


Written by Danielle Wiederoder and Jonathan Miller

A man looks at a bulletin board of ideas

Three Companies Proving Agile is Successful Outside of Software

Agile is often referred to as a project management framework, methodology, or a mindset and is widely used throughout software development companies. You may have heard about some of the benefits of Agile like increased productivity, higher success rates vs. traditional project management, and boosts to customer satisfaction while simultaneously decreasing time to market, costs, and waste.

With results like these, you might be asking if Agile could also work for your organization, even if you’re not in software development. Unfortunately, I often encounter the mindset that “Agile is only for software, its principles don’t apply to us.” I think that’s just plain wrong. As a Certified Scrum Master and Product Owner myself, I often see Agile principles in practice beyond their perceived scope of software development, even using Agile in government work.

It’s true that many software development companies have adopted Agile and been greatly successful with its implementation, but why couldn’t professional services like Management Consulting, Human Resources or Marketing use the same principles to reach success? That very question was the focus of the recent Business Agility Conference in NYC. In a first of its kind event, 300+ agile professionals, consultants, and business leaders participated in a series of short presentations and facilitated workshops to discuss how applying Agile can, and is, innovating and disrupting current markets while increasing organizational success outside of software development.

While there were several great presentations focused on successful Agile implementation outside of software development, I think the following three presentations did a particularly great job:

David Grabel – VistaPrint

VistaPrint, a marketing company for small businesses, conducted an evaluation of their waterfall methodology revealing that the teams were taking more than 60 days to take a new idea to a deliverable. However, the 60-day cycle amounted to only about 40 hours of actual work.

Why, if the actual life-cycle takes only 40 hours of actual work were they seeing the process take two months to deliver? A root cause analysis revealed they were suffering from feedback “swirls”, blaming, unclear decision rights, and long creative lead times.

VistaPrint made the decision to switch to Agile, focusing on decreasing project lead time. They began by promoting team environments, information sharing, and transparency. They implemented team building activities, daily stand-ups, Kanban boards, an idea pipeline, more informational touch points, and retrospectives to review what went well and what didn’t to improve their processes for the future.

In five months, they saw their Lead Time decrease from 40 days to 15 days. Five months later, they would see this drop further to 7 days, an 83% improvement overall.

Dan Montgomery – AgileStrategies

Dan Montgomery was hired as a consultant and coach to help 5Acres, a not-for-profit orphanage placing children with permanent loving families, improve their business model to increase the number of children placed with permanent families each year.

The current system used a waterfall methodology and a hierarchical management framework. The control was tightly coupled and often failed in cascading down to the appropriate levels for execution. The organization also found that there were far too many initiatives being worked simultaneously further affecting their ability to successfully plan, execute, and deliver results.

5Acres began the transition to Agile by conducting team building activities and deep dives to define the organization’s initiatives. One key outcome was implementing the use of Objectives & Key Results (OKRs). They committed to taking on only 1-5 initiatives at a time to improve the likelihood of success. The teams focused on the mantra “start less and finish more.”

In doing so, 5Acres took over 30 strategic initiatives and prioritized them to set five clearly defined, measurable, organizational goals to reach by 2020. The clearly defined goals helped 5Acres hone in on their key objectives and desired outcomes over a short 3-5 year horizon resulting in a focused, attainable plan.

Isabella Serg – AgileIBM

Agile is not necessarily new to IBM. The technology company has been using Agile across IT programs for years. The novelty was implementing it in their Human Resources department.

IBM was facing challenges in recruiting and retaining top talent including the difficulty of attracting STEM talent, an expanding global workforce, and a need to better manage high and low performance across the organization. To improve their employee services, HR conducted an evaluation of their current practices and identified two areas that would benefit from an Agile approach: its hierarchical organization and implementation of a specialized work force within HR; and managing work in progress (WIP).

IBM started by identifying their Big Hairy Audacious Goals (BHAGs) which fed into the creation of cross-functional, self-selected teams. Making the change from specialized, management assigned teams to cross-functional, self-selected teams increased employee feelings of empowerment, purpose, and collaboration ultimately resulting in better work products.

The teams implemented a backlog to manage their WIP. This provided transparency and focused employees on finishing a task before starting a new one. The teams were then able to measure their work and end results providing them further insights into their strengths and identify areas for improvement.

As we can see from these three examples at the Business Agility Conference, Agile is not only successful in software development, it’s just the first industry that really proved it works. Creating cross-functional collaborative teams can lead to employee empowerment and boost team performance while delivering better client results. Developing measurable, attainable, time-boxed goals can lead to a higher likelihood of successful execution: start less and finish more. Implementing transparent work practices, measuring end results, and evaluating strengths and weaknesses can lead to process improvement and increased efficiency.

 

The basic principles of Agile center on collaboration, transparency, and the creation of self-organizing cross-functional teams. Almost any organization can build on those basic principles to achieve success.

U.S. Capitol during cherry blossom season represents the idea of government innovation

Government Innovation with Purpose in a New Administration

In April, I attended MITX’s DesignTech summit in Boston and had the opportunity to talk to a lot of really interesting folks designing innovations in the IT world today. As a government innovation professional, I particularly enjoyed the keynote by Gene Han – he said two things in that stuck with me:

  1. Innovation must have purpose
  2. Innovation is about getting things to work together (it’s not always about the most advanced technology)

 

Both statements are simple, and neither is totally new, but these are sometimes hard principles to remember and apply – particularly in the government innovation world. Mr. Han probably didn’t have the federal government (or state or local) in the front of his mind when he gave his talk, but it struck me how important these two principles are for the government (and those like me who support them) in this precise moment.

Big-budget departments like the Department of Defense have been talking about government innovation for some time – former Secretary of Defense Ash Carter gave a speech this week reminding the world of the steps he took to try to bring innovation back to Defense. However, the future of those initiatives is cloudy in a new administration with different priorities.

Other organizations, many with already small budgets, find themselves facing new budget priorities and potential for significantly reduced spending power. And yet, the country faces a lot of really important and unprecedented social, economic, and diplomatic challenges.

If the government’s goal is to continue (or even improve) its service to the public, they need to get innovating at a time when resources to innovate are increasingly slippery. Daunting, yes – but it can be done, especially if we remember to have purpose and make things work together.

What does federal government innovation look like in practice?

Focus on outcomes first

This sounds easy but can be surprisingly hard in government spaces where things are often done because of regulation or policy, not value. Identify what the improvement looks like in practice and then work backwards.   If you build something cool that no one uses, your “innovation” is without purpose – and therefore not really innovative at all.

Use the tools you already have

Think hard – and seriously – about how to use the tools you already have to create innovative government solutions. If you can reach your outcomes by rethinking process, training, and re-use (or better use) of everyday tools that everyone already has. This is where “making things work together” comes in. It doesn’t matter if it’s a laser-guided missile or a really well-designed process with a shared drive; if you’re doing something new to improve the status quo, you’re innovating.

Think about requirements as constraints, not restraints. Too often in government we get stuck in the mindset that “we can’t” because of all the requirements placed on us (interoperability, reporting, security, authority…the list goes on). If we start to think of these requirements as constraints (that which imposes structure) as opposed to restraints (that which limits), we suddenly allow ourselves to think more creatively and proactively.

Simplify

Another temptation for those swimming in government bureaucracy is to think that everything has to be highly specialized or complicated for it to work.   The more we focus on outcomes, the easier it is to focus on core requirements. This makes it a lot easier to find an iterative path to innovation: ways of making ideas, people, methods and tools connect to get things done.

 

Maybe there is hope for the White House Office of American Innovation after all.

hot air balloon provides an escape similar to innovation series

Technical Assent’s Inspiring Service Summer Series

At Technical Assent, we believe that a key component of providing exceptional service is rooted in providing an exceptional customer experience. In May 2016, we launched a four-month design thinking effort called Inspiring Service Summer Series, or ISSS for short. ISSS was professional development, but it was also our tool for looking in the mirror and working on our own service delivery as a company. Or, in other words, working “in a problem, on a problem.”

We included all staff members in this effort, with non-client-facing staff and consultants learning and contributing equally. Additionally, ISSS had a secondary purpose as a forum for testing virtual collaboration and facilitation methods our company developed.

Why we did this

One goal was to ensure that all Technical Assent employees are well-equipped to deliver “Services that INSPIRE” to our clients, including access to the necessary knowledge, skills, tools, and other resources. We also wanted to continue to build employee comfort with design-thinking tools—especially in a virtual environment—and learn more about ourselves. Ultimately, we wanted to create something of value for our customers by improving ourselves.

The graphic below summarizes our #ISSS virtual design journey.

What emerged from the effort

Our starting point, as always, was our customers, because our solutions will ultimately be measured by their impact to them. Based on customer input, we spent considerable time reflecting and defining what they need from us, what they really want, and how they want it delivered. That definition of inspiring service became the foundation of everything that came afterward. We identified focus areas based on client needs and our corporate goals, brainstormed over 70 ideas to make ourselves better, and assembled prototype teams to bring select ideas to life.

So now, after nearly four months of work, we emerged with three completely different innovations we’re now in the process of implementing.

We are sharing our design journey because it is something that can be repeated. As with any of these types of efforts, it was less about the specific technique or method and more about the richness of the dialogue that evolved.

Overall, the exercise was a great success and as a result, we’re confident our entire staff is better positioned to provide the kind of inspiring service our clients most need. We learned a lot along the way, and we look forward to sharing some of those insights in the future.

eli whitney innovation in muskets

What Eli Whitney’s 1798 Gun-Making Contract Can Teach Us About 21st Century Defense Innovation

In 1798, faced with potential war against France, President John Adams directed a threefold increase in the number of ready army soldiers.  At the time, gun-making was a complex craft; skilled gunsmiths worked by hand to create each distinctive weapon.  The young government didn’t have the capability to manufacture the weapons it needed, so Adams turned to private industry for support.

Eli Whitney, the famed inventor of the cotton gin, won one of the 28-month contracts to produce 10,000 “stands of weapons,” enough to outfit 80% of the army with new muskets. As the story goes, after two years of contract performance, Whitney had produced exactly zero guns. Instead, he had focused his attention on building a better system for building muskets. He built the factory and the machinery, trained a labor force for how to use it, and developed repeatable assembly process.  The result was the first weapons system where one musket behaved similarly to another and used interchangeable parts.

Outputs Vs. Outcomes in Defense Innovation

While there are certainly some starting points here for a conversation about acquisition reform, I’m focusing on a different, larger issue: how a narrow focus on outputs can distract us from pursuing the right outcomes.  Our military faces similar challenges today as they did in 1798, sharing  a need to rapidly scale its capability and evolve to multi-dimensional threat. Back then, they did it with more soldiers and more muskets; today we do it with much more sophisticated, integrated weapon systems.

We’re living in a new era for innovation in the Defense industry.  Defense Secretary Ash Carter is shaping and expanding an innovation unit in Silicon Valley (DIUx)—and the Department of Homeland Security is following suit.  Professors at Stanford University have students and soldiers collaborating to identify “hacks” for the way DoD does business. Groups like the Defense Entrepreneurs Forum (DEF) are facilitating discussions about major issues the Third Offset, Force of the Future, and Goldwater-Nichols Act Reform.  Earlier this month, the Senate Armed Services Committee released its draft of the 2017 Defense Authorization that splits the Pentagon’s largest office in an effort to improve management of research and development  efforts.

These examples suggest a consensus that fostering innovation in our defense machine is imperative to retaining our “edge” over competitors and obstacles—whether we are providing disaster relief and humanitarian support, or fighting large ground wars.  What government and defense leaders  don’t seem to agree on is where to start. What we really need is a system where we are continually getting better at getting better, where real change can happen faster than in 15-20 year increments.

Disrupting the Dominant Cycle of Thinking

Whitney’s brilliance is that he disrupted the dominant cycle of thinking at the time.  Instead of cranking out thousands of hand-crafted rifles, bayonets, and ramrods, he focused on building a system where new technology could be produced faster.  However, our current collective efforts to increase our technological advantages (e.g., Third Offset) seem more focused on buying better muskets—drone muskets, cyber muskets, nano-muskets, human-musket collaboration, inter-continental ballistic muskets—than building a system of innovation.  That needs to change.

Here’s a DoD-specific analogy for what that actually means.  Consider Innovation as an organizational capability gap.  DoD evaluates these gaps across Doctrine, Organization, Training, Muskets (i.e., Materiel such as equipment, tools, systems), Leadership, Policy, Facilities, and Policy (DOTMLPF-P).  Rather than looking first to innovative Materiel (“better muskets”) as we usually do, let’s first actually sit down and think hard about how we can innovate the way the department trains and equips our personnel to solve the problem in the context of the environment in which they must solve it.

Evolving Faster and More Effectively than the Competition

The ultimate strategy to counter competitors’ advantages (real or perceived) is a sustained, organic ability to improve and evolve yourself faster and more effectively than your competitors—rather than building a new portfolio of technologies.  If our objective is to create a system to get better at being better, there are two logical places to start:

Make the “Ability to Adapt” a factor for readiness.

Being ready to meet the demands of a mission is not simply a matter of assessing whether or not you have the right “kit” for the operation.  There is too much variation in the types of environments, the types of missions, and the circumstances surrounding those factors for you to assess readiness on equipment alone.  You have to assess whether or not the people and processes who will use the kit have the ability to adapt what they have (and don’t have) to fit the needs of the operation.

We need personnel who are ready to integrate themselves and their kit into the operation and be successful.  We need processes that allow them to do that—both in the field and in the headquarters functions that support them.  One way to do this might be to re-purpose some of the procurement budget for exercises. Don’t just assess readiness, test it.  Make these exercises faster to plan, less cumbersome to host and participate in, and cover more mission scenarios.  The more frequently we test ourselves, the better we understand our abilities, our needs, and the more we are inspired to innovate with real purpose.

Make non-materiel adaptability and innovation a tenet of the highest level guidance and plans.  

Strategic planning, policy, and doctrine provide a foundation on which much of the DoD’s ’s operations rest.  Like the mindset of our innovation efforts to date, these high level guidance and plans can also become too focused on “muskets.”  This is problematic because these high-level documents take years to formally update.  What’s published is often “behind the times”—describing situations and solutions that occurred in the past rather than enabling future success in what may be a completely new environment.  Fixing the strategic foundation that guides the way we “do” defense requires: 1) moving guidance, policy, and doctrine away from 3-5-year update cycles; and, 2) maintaining focus on enabling adaptability and innovation rather than focus on musket-based (“Materiel”) solutions.

 

John DiLuna and Danielle Wiederoder wrote this with me.

acquisition innovation will yield better outcomes for government services

So you’re an Acquisition Innovation Advocate – now what?

The new initiative announced by the White House to encourage the establishment of Acquisition Innovation “Labs” in Federal Agencies is a great step towards facilitating a culture that facilitates ingenuity and innovation.  One aspect of the initiative urges Departments and Agencies to appoint Acquisition Innovation  Advocates as a means to foster greater innovation, to stand up Innovation “Labs“, — really just a commitment to experiment with better ways to solve mission challenges through procurement, but I’m going to stick with Lab for the rest of this post — and to participate in an established council.  If you find yourself named as your agency’s Acquisition Innovation  Advocate or otherwise leading an Acquisition Innovation Lab, I offer a sample roadmap that has an excellent track record in innovation efforts, especially those with the sense to run like a start-up.

If you want to move your Agency’s Lab forward from “good idea” to “real impact”, you need to overcome inertia: on Day 90, you need to have at least 3 pilots launched. This means you need to have something of value to offer to willing customers with active requirements and procurement problems to solve.  Which means you need a thorough understanding of the requirements in the pipeline, the missions of the owner of each requirement, what they are trying to accomplish with each requirement, and the specific procurement challenges most impactful to each.  And you have to do all of this in the context of your agency mission and strategy.

This probably sounds like a lot.  You might be anxious.  An important way to minimize stress will be to minimize the spin/churn cycle.  If you change an experiment while you’re running it, it’s impossible to assess the result.

Start in a green field.  The FAR isn’t a labyrinth; it’s a giant prairie with some critical fences and some occasional giant rocks.  OFPP and the federal CIO told you to focus on technology procurements.  I wouldn’t limit your opportunity for innovation to just IT.  Focusing on IT and digital is good – these have gotten a lot of attention in recent years – but looking at services more broadly is the biggest opportunity: 2/3 of the federal government’s $437 billion in contracts during Fiscal Year 2015 were for services – and IT/Communications products weren’t even half of the 1/3 that was product/supplies spend (FPDS-NG).  Look at the entire procurement journey – from requirement concept to contract closeout – and be open to trade-offs.  Look at the three major groups of participants – the customer, the procurement shop, and the prospective vendor.

First, lay a strong foundation by setting out to make your innovations a win-win-win for each of the three types of participants – your customer, the procurement office, and the vendors who will offer solutions.  Try to do this in your first two weeks.  Be clear about what your agency wants from this effort.  Is it the cheapest, fastest solutions? Or more about the quality of the service or product (utility & warranty)?  How does the customer experience factor into acquisitions (both from the government program manager and the vendor perspectives)?  This will drive what you measure and how.  Calling in support from an artificial intelligence system that lives in the cloudcan’t help you here.

Take this opportunity to spend a few days re-learning your agency as a buyer. What does your agency really buy? What does the requirement pipeline look like?  Based on this discovery and learning, identify major areas of opportunity.  If these are still IT, great. Run with it.

Second, recruit early adopters as customers for your Lab.  To do this you need to craft your value proposition – why these customers should take a chance on the Lab: be explicit, be objective, and be honest.  Aim to do this by the end of Month 2.  If you want to end up with three strong pilots, you need to start with 20-30 prospects.  An email announcing the experiment is one way to raise awareness.  You should also consider a road show among the customers who already have requirements in the acquisition forecast.  Use these early adopter prospects to build a pipeline of upcoming customer requirements for the Lab.  From this pipeline, you will draw your 3 pilot procurements.  There may be some back-and-forth with customers as you recruit them to participate.

To narrow the list, you first establish criteria for what constitutes a good pilot candidate – measured against the utility, warranty, and experience objectives you laid out in the first two weeks.  Next, you and your team do a first round of scoping these potential pilots.  What mission outcomes is the customer trying to accomplish or enable with this procurement? What’s the customer particular procurement problem, how might you solve it, what would it take, what are the obstacles, etc.?  Force-rank these potential pilots, and then take a couple of weeks to refine the scope of the best half with the customer.  Repeat this down-select process toward the end of month two.  As part of selecting your first three pilots, be sure that you can measure what you need to measure for each in a timely and accurate manner.  You can reduce angst by keeping this part simple; just focus on how each furthers your acquisition innovation outcomes.

Third, select the top three pilots, execute, and “land the plane”.    By Day 90, launch your pilots.  Measure your results. Listen to your customers, the acquisition professionals involved in each pilot, and the vendors who offering solutions (and those who aren’t).  Read between the lines.  Measure impact and perceptions on both sides of the acquisition equation (government and industry).  The people involved will make or break any innovation.

As you think about the pilots, understand what behavior you incentivized or disincentivized?  Are procurements appealing only to well-funded, established companies that can afford to take the risk?  Does the approach encourage competition?  What are the costs to bid on work relative to the award?  What is the impact to the market?  “If my agency continues this behavior…”

This roadmap should get you started on building and measuring your experiments with better ways to solve your agency’s mission challenges using procurement.  Next you need to feed what you learn back into more experiments and start scaling what works.

I love thinking about this stuff, and I’d love to hear what you have to say.

SECDEF Ash Carter reviews DOD innovations

The DoD: Becoming a Good Neighbor in the Community They Started

I’ve lived in the San Francisco Bay Area for over a year now and I continue to be inspired by this geographic center of mass for innovation. It is no wonder that both the Secretary of Defense and Secretary of Homeland Security have both recently announced new programs with offices located in Silicon Valley to tap into that innovative spirit.

The Secretary of Defense’s program is the Defense Innovation Initiative (DII) with the Defense Innovation Unit Experimental (DIUx) positioning the DoD to be more open to the infusing of non-traditional technical ideas and talent.  The DIUx set up its Mountain View, Calif., office in August.

Last month, I had the opportunity to participate in a Center for New American Security workshop to provide recommendations to the Secretary of Defense about how to capture and infuse some of the Silicon Valley magic into the Department of Defense.  The group of people included members of the DIUx, defense industry associations, think tanks, and entrepreneurs.

The primary observation from the attendees focused on the increased requests from senior federal executives to tour innovative companies which has devolved into little more than a rote parade of military VIPs.  While “jumping through hoops” and “dog and pony shows” are common jargon in government, Silicon Valley innovators are fueled by taking action on real problems and quickly pivoting until they discover the optimal solution. However, the aspect that is most ironic to me is Silicon Valley itself was launched by DoD initiatives (See Steve Blank’s talk on the  Secret History of Silicon Valley), which means, at least at one time, that DoD knew how to effectively engage innovators and how to channel their spirit into meaningful work.

DoD can’t be an absentee owner of their new vacation property in Silicon Valley; they need to be a fully integrated member of the neighborhood.  To be enfolded in the epicenter of innovation, the DoD will have to start out by fitting in with the culture.  I’ve seen this opinion echoed in articles online, like Colin Clark’s “Can SecDef Carter Win Over Silicon Valley?”.

One thing I have noticed in my time living in the Bay Area is that many people close out their meetings with the same question:

“How can I help you?”

I have found something hugely powerful in this question as it seems to embody part of the culture that has made Silicon Valley companies so successful. In the asking of this question, it implies the asker is willing to take action and it supposes the receiver knows what they need.

Perhaps the DoD’s path to an invitation to the neighborhood block party is in recapturing the very spirit that helped build the neighborhood in the first place and being ready to answer “How can I help you?”

12