Federal procurement rules include a concept called Organizational Conflict of Interest (OCI), [FAR Subpart 9.5]. Intended to keep a level competitive playing field, one particular element of OCI is retrograde for software development work.
This element mandates that the group that specifies a solution cannot
implement that solution. Yes, that is correct. The team that invests in
learning the problem domain, understanding the customer's problems and framing a solution must specify the solution yet cannot be involved in creating the solution.
This has negative implications in software construction. The team that specifies a solution has no
accountability for the feasibility of that solution. Moreover, because
they are never around when the solution is created, they never receive
any feedback about what works and what doesn't. Their ability to recommend solutions is therefore questionable.
This runs counter to the idea of continuous improvement. This
subverts the ideal of craftsmanship. It is the act of doing that teaches
us what should be done. In the doing there is learning that
cannot be accomplished without the experience of doing. And designers who don't do never experience the insights that lead to innovation. Andy Grove wrote eloquently about this as a national problem here.
It seems that in practice, the larger the problem the stronger the
enforcement of these OCI provisions. Evidence the very lucrative Systems Engineering Technical Assistance (SETA) companies that study but never deliver. Could this be one of the reasons
the federal government has such a horrible track record with large