The Digital Service Playbook #1 "Understand What People Need"

I often tell people that I have been acquiring agile development before I even knew what it was. As a Contracting Officer I am first and foremost a business advisor. So when my customers changed their requirements from traditional waterfall system requirements, to those with evolving technical functionality, I adapted my contracting approach as well. Don't get me wrong, I didn't just magically end up where I am today with regards to acquisition strategies for agile programs, but I knew I needed to change the contractual terms to meet the flexibility they were requiring.

All of the plays in the Digital Service Playbook are essential to program success, but for me the most important is "Understanding What People Need"

"We must begin digital projects by exploring and pinpointing the needs of the people who will use the service, and the ways the service will fit into their lives. Whether the users are members of the public or government employees, policy makers must include real people in their design process from the beginning. The needs of people — not constraints of government structures or silos — should inform technical and design decisions. We need to continually test the products we build with real people to keep us honest about what is important,"(Digital Service Playbook).

At first I implemented labor hour and T&M solutions to provide the greatest flexibility to the Program Managers. This was successful but presented a great deal of risk to the Government. Overtime I conducted my own research to better understand this trend in requirements. I took a Certified Agile Scrum training, and interviewed my customers to get a better understanding of what it was they needed. It quickly became apparent to me that the need was not hours but a repeatable process that resulted in functional code. In other words there was a clear requirement (i.e., the process) and a clear deliverable (i.e., the code). Additionally, these services to provide the code were commercially available and in-fact common place in industry.

This realization is what lead me to the conclusion that Fixed Price per iteration was the most appropriate vehicle to use. I never would have been able to reach this conclusion and been able to provide value to my customers if hadn't taken the time to understand what they need.