Make Change Happen

When I think of innovation, change, even upheaval of the status quo comes to mind.  True innovation requires taking chances, and being willing to fail.  This is contrary to the mindset of many in the acquisition community, where the prevailing viewpoint is to fear change, and subsequently view innovation as an unneeded risk.  I view innovation as progress, something exciting that reminds me of why I’m here, doing the job I am in the first place.

Innovation has the potential to be transformative, which makes some people uncomfortable, as any interruption to the known has the tendency to do.  To me, the alternative, regression, is a much more frightening state.  Real innovation can sometimes be labeled divisive, which is often true.  It divides the people looking for progression and change to those uncomfortable with uncharted territory, and I’m okay with that.  Historically, real, life-altering change has always been divisive, and to me, can be an indicator that innovation is occurring.

The acquisition community needs fearless leaders, who are willing to put big ideas out there, and aren’t afraid to fail.  Failure is an unavoidable part of life and something to be embraced and learned from.  When I’m done my federal career, and look back on what purpose I served, I don’t want to have any regrets about change I could have made happen, but didn’t.  Innovation is a mindset and Digital Service CO’s are the ambassadors to transform the way the Federal Government provides a digital experience.

Forty Percent of the Time, I’m Right Everytime

The fall of 2010 was an important time for the Centers for Medicare and Medicaid Services (CMS), and the Federal Government as a whole.  The previous March, the Affordable Care Act was signed into law, and more importantly, I began as an 1102, which was a major transition from my previous job of dressing up and playing a millionaire at parties.

So I started my federal career as a blank slate, with the basis of my knowledge of CMS being what I had learned in my interview prep.  (Before I get any further, I need to disclose something about myself.  I hate not knowing things.  Seriously hate it.  Nothing bothers me more.  So yea, I always have a question or something to say and I can’t help but be curious as to everything going on, even if it isn’t in my direct workload.  I’m that guy up in everyone’s business, and while I’m at peace with it, my condolences to those I have and will continue to annoy.)  So back to CMS… After many months of tedious CON classes, I finally got back to the office and into the IT contracts division.

After the year or so it took me to figure out the basics, I started noticing things that didn’t make any logical sense.  Whether it was the backwards way we did IGCE’s – if you have a firm budget, then it’s not your estimate, it’s your budget; used extensive resources to implement award fee contracts, only to consistently pay 90%+ for mediocre performance; spent endless time and money on EVM, when no one could articulate the actual value to CMS; consistently used Statement’s of Work well over 100 pages that were overly prescriptive, which at first I thought was a result of program offices expertise – I’d soon learn this was definitely not the case; and the belief that the more pages of analysis of documentation, the better, regardless of content.

As expected, I had questions.  A lot of questions.  Most revolved back to, why are we doing so many thing with no value added?  I got the same answer I’m sure any federal employee has heard before, “That’s how it was done when I got here,” or “That’s just the way it is.”  As I explained earlier, that type of response won’t jive with me.  I’ve always been a major proponent of the “working smart” school of thought, and so much of what I encountered in the federal government made no sense to me.

Fast forward a year or so and I forced my way into an Agile Contracting training for Contracting Officers, with no mind given that I was a Contract Specialist at the time with only ~two years of experience.  The agile training made so much sense, but seemed like it would be impossible to implement at CMS, given the existing infrastructure and personnel.  It made too much sense to give up on, and I was adamant that I would never become a disgruntled Fed, counting down the decades until my retirement.  Life’s too short for that.  I knew I wanted to be involved in changing the way the federal government administers digital services, but like Frodo, was waiting for my Samwise Gamgee to guide me on my journey.

In late 2014 the opportunity I was looking for presented itself.  I began speaking with Mark Naggar, who had just began working as the PM for the HHS Buyer’s Club.  We started talking about prototypes, concept papers, Statement of Objectives (SOO) and agile development.  This was good, but I needed more.  An opportunity arose for someone from CMS to attend the Developing Agile Professionals Meeting at Jackson Place in D.C., and I immediately requested approval from my supervisors to attend.  At the meeting, I had the opportunity to be introduced to U.S. Digital Services and share knowledge with various leaders and contracting professionals from various agencies.  We discussed the formation of the DITAP program and I knew I had to be a member of the first DITAP class, even if I had to assume a false identity to attend.

When the DITAP classes began in October, I had high expectations, which have been exceeded in every way.  Everything about it makes sense, from communicating with vendors and treating them as partners, rather than adversaries – they have the expertise; to putting the premium on working code/systems over documentation; and most importantly minimizing initial investment and failing fast.  This is what I’ve been waiting for DITAP, and you finally found me.  Best of all, I get to be lazy like a fox!