Three Waypoints for PubSec Software Delivery
One does not simply walk into Mordor; plan your journey before you innovate.
Innovation often starts as a vision. It’s aspirational. It feels like “why hasn’t anyone done this before.” The truth is, people have thought of it, but they ran into obstacles. This happens all the time in the Federal space. Here’s a roadmap to chart some of those obstacles.
In the public sector, software innovation is a journey that requires deliberate forethought along three constraint domains: compliance, technical competency, and resourcing. These domains can overlap, but each one requires distinct consideration.
Areas of significant complexity that are likely to require advanced planning.
“Every project we’ve seen fail, fails in at least one of the three constraint domains.” - The Authors
The authors have 25+ years of combined experience in public sector software innovation.
Of the three constraint domains, the most consequential for a successful public sector software project is compliance. This domain is primarily driven by cybersecurity, but it is actually composed of all legal and organizational policy requirements.
Compliance is sometimes conflated with technical security. It is important to note that they are not the same thing. It is possible to have poorly secured applications that are fully compliant and it is also possible to have highly secured applications that are non-compliant.
Professionals in this community are inundated with systems and programs - leaving them little time to form a deep understanding of any given project. Trust between all involved stakeholders is the currency of this domain. Consistency, transparency, and communicating effectively are the means of obtaining and maintaining trust.
The second major constraint domain for public sector software projects is technical competency. This area is defined by the collective abilities of all personnel supporting a software objective.
This includes all of the technical competencies necessary to design, build, and deliver the product. The idea that all of these are contained within a single individual - often referred to as a 10x engineer - is a foolish, yet common mistake.
Good hiring practices, that target complementary skills, build a team of individuals that can overcome many technical challenges. Pay particular attention to soft skills, because they exponentially increase overall team effectiveness. Plan for continuous investment in personnel as a means of increasing knowledge-overlaps and depth-of-specialization.
The easiest constraint domain for public sector organizations to address in their software projects is resourcing. Resources are not simply money; they include every limited asset and material invested by the organization into a project.
Even though the other domains touched on aspects of resourcing, this domain considers it holistically. Difficulty emerges when making hard decisions for resource prioritization. Don’t try to “have your cake and eat it too.”
The approach here is simple. Define what is necessary, account for on-hand resources, then cover the gaps. There may be tradeoffs; it may not even be possible to cover everything. Do not move forward if there is no accomplishable path to obtaining the necessary resources.
Finally, remember that people are at the core of modern software development. This is a deeper conversation, perhaps for another article… for now, just know that good relationships can bridge otherwise insurmountable obstacles. Foster relationships with and between prominent groups, such as: compliance, legal, security, engineering, human resources, finance, and contracting. Form the Fellowship.
We’ve seen these constraint domains become impediments to success time and again. Innovators should be able to articulate an approach to them throughout the life of a project.