Process Over Product
So how do we get to these shorter projects that are easier to estimate and conserve momentum? Today we build our plans thinking about the product and not the process. You can go to FedBizOpps and find bunches of statements of work and performance work statements that are asking contractors to develop proposals for how to build applications and systems for agencies. In some instances, as I identified in Chapter 2, the work statement tells potential bidders what stack, platform, or environment they are working in. For example, J2EE/Solaris/Oracle or JBoss/Linux/MySQL, or whatever the standard platform is. That kind of specificity is good. It narrows the amount of variability in the bids, decreases the risk to the offers and allows for a more effective comparison among the proposals.
Too frequently, however, we see work statements that go into exhaustive detail about what is to be developed. Excuse me, but isn’t part of the work that we want the contractor to perform, requirements analysis? If so, then why would we pay for something we have already done? When we include tons of detailed requirements in the work statement, we are excusing the contractor from performing the necessary analysis. They will charge us for their analysis because we said we want to pay for that, but their analysis must necessarily be consistent with the analysis we have already done because it is in the work statement.
Just because it is such a public whipping boy, let’s compare the HealthCare.gov contract over time. The initial $5 million award under the HITECH Act went to CGI Federal Inc. You can still find the synopsis and award information in FBO:
To facilitate this exercise I’m referencing data made available by Black Vault under the Freedom of Information Act.
Look at all the changes they had over time. Based on this table, I would have to say that we have a lot of changes. The Inspector General for HHS recently released a report8 that identified change management as one of the key issues that made this program problematic. By the way, I think that report is pretty good. But keep in mind that HealthCare.gov was just a very public debacle. As I look at this contract history and the acquisition documents that are behind it, this is not terribly different than what we see in many other projects. As I already mentioned, from an estimation perspective this is problematic. Also from a momentum perspective this is problematic. I wonder if there was some way to overcome all these issues.
| Stop Buying the Product and Start Buying the Process |
It infuriates me that we keep specifying the product in every work statement. If instead of doing that, let’s buy the process from the contractor and rely on the process to deliver the product we need.
Instead of buying products or applications, I buy the process to the left. I talk about the requirements backlog, what requirements and design looks like, and what sprints are. Then, I buy sprints. I do not waste time in my work statement describing the product because I know I’m going to get it wrong anyway. Instead, I describe the process that the contractor needs to bring to the table.
