 | by Kent Aitken |       |
In my last post, I presented a round-up of some thought-provoking pieces on Healthcare.gov from various technology writers and professionals (see: Healthcare.gov as a Case Study for the Digital Analog Divide). It had struck me that such a highly politicized government misstep would be subject to a lot of interesting diagnosis and misdiagnosis. I've been particularly interested in whether the result is a side effect of government's internal capacity. And if so, whether it's a result of reaching the limits of outsourcing, or if outsourcing for IM/IT is just fundamentally different.
How Big Should Government Be?
Clearly, the role for government is not everything, and not nothing. Somewhere in between there's a useful upper and lower boundary.
One of the themes from the 2012 conference of the Institute of Public Administration of Canada (IPAC) was the changing nature of policy analysts’ roles. Several observers suggested an evolution from a “subject matter expert” role to a “relationship manager” role, as the public service could increasingly rely on external parties for research and policy advice. It that the right path? And does it work for IM/IT?
I think there are two major concerns here. Not failings, just concerns. The first is if part of Mark Headd's analysis of government procurement is accurate: that government already needs “more makers and hackers.” One can imagine a hypothetical and absurd extreme, where government has lost the expertise to even manage and challenge third party organizations providing contracted services. I think there's a plausible risk on the spectrum towards that extreme for IM/IT, but that’s the “is IM/IT fundamentally different?” question for later. Is it a risk for policy work as well?
The second is about pragmatism. The question is, is relationship management a role that will attract and retain the appropriate level of talent? Or will bright public servants exit the ecosystem if they cannot actually make? The talent may exist outside government, but the result will hinge on the system's capacity to make productive use of it. So the decision rubric isn't “Can this be handled outside of government?”, it's “What balance of in-government and out-of-government capacity makes for the most effective system?”
Govcloud
In addition, government has an alternative to outsourcing that did not previously exist. For a large project like Healthcare.gov, a contract is essentially the only way to go, and the decision points revolve around managing that contract through its lifecycle and through its operating environment. However, for many projects, governments have an unprecedented capacity to throttle their own capacity through horizontal collaboration and networks. This is sounding like it would deprive the private sector of government contracts, but ultimately the goal is providing sustainable value for taxpayer money.
The option is hybrid or formal Govcloud models, that mean that we can manage workloads in aggregate, not on an individual or team basis.
Last year I wrote about spans of control, noting that small teams (characteristic of most of the teams I've worked on) have limited options for capacity control (see: Spans of Control). Say a manager has two employees. Under traditional staffing mechanisms, the smallest increment that they can increase or decrease capacity is huge: either going from three staff (manager plus two employees) to four (33% increase), or three to two (50% decrease). Managers with ten employees can, in contrast, adjust by 10%. Regardless, in both cases the magnitude of change (and their relative permanence) is inflexible.
But increasingly, we can supplement or subvert that system and make our feasible talent pool - our effective "team" size - much larger as we make the public service community "smaller" through networks and communities, partially digitally-enabled.
This is important because there's no organization in the world that accurately quarries work into perfect 40-hour blocks every week. Imagine a set of hypothetical employees, whose workloads cluster around an average work week:
While organizations make use of the productive variance above the standard, they lose the inevitable variance below it. But, we can push many of those low data points closer and closer to the trendline through collaboration. And the bigger the talent “cloud,” the better we can align people with the work they do best, not just fill their time.
Here There Be Monsters
Returning to an earlier question, it is also possible that IM/IT just represents the uncharted territory, off the map. A quick straw man as an example:
Even if you've never built a shed, if you hired someone to build a shed you can understand, intuitively, a rough order of magnitude for the level of work involved. Maybe even a rough appreciation for the value of the materials used. For software, however, it's harder to tell if a contractor actually laboured over it, or if they copied and pasted a software shed they built for someone else before, and added paint. Many of the people ultimately managing these contracts either learned how to program a long time ago, or not at all. Combine that with a procurement model that is largely immune to reference checks and the length of technology lifecycles, and it's easy to imagine the predicament government is in, managing such projects.
Regardless, the conclusions from concerns like these are not straightforward. It seems hardly constructive to simply suggest that governments wholesale examine their assumptions about the way they've adjusted to the digital, knowledge work world. (Though I think that they should.)
That said, maximizing individuals managers’ capacity to leverage the internal talent pool - which would require a combination of platform and governance - seems like a win-win approach. And it may alleviate some of the pressures on managing complex projects, by making it easier to get the right experts involved early in the process, even for quick-hit guidance.
What should be done about the state of that overall talent pool in the first place? A much trickier question.
No comments:
Post a Comment