First, thanks for taking at least an initial look at what I believe can and must be a new, fresh start for federal IT if it is ever to regain the public trust and confidence lost over dozens of serial (and highly visible) failures. As I explained in my deep breath before the plunge introduction, I’ve seen enough such failures since joining federal public service that I’ve become convinced a new paradigm must be introduced that goes so far outside the envelope, that four envelopes must be pushed, top down within the federal public sector for the public to regain any semblance of confidence the over $85 billion spent each year is even marginally worthwhile.
I’ll start by introducing the envelopes that we have to push, the barriers to pushing those envelopes, and finally an organizational and process construct that will allow the federal government to achieve renewed trust and confidence. Following this introduction, I’ll present a blog on each of the envelopes individually, laying out clearly and as concisely as I can what I mean by that envelope and how it fits into the overall initiative. Next I’ll look at the structural, leadership, and legislative barriers that confront the initiative followed by individual blogs about how those might be most effectively overcome and implemented. That said, let me begin…
The four envelopes we must push to implement a new, effective, and trustworthy federal IT paradigm are:
- Program and Project Management,
- Enterprise Architecture Modeling,
- User Experience Modeling, and
- Collaborative Development.
The envelopes do not exist in isolation, they function on an integrated basis and in the context of an unprecedented degree of public engagement enabled by a level of transparency that simply does not today exist in any level of the federal government. Let’s take a look at them one-by-one at an introductory level of detail.
Program and Project Management
Program and project management in federal IT has been a fits-and-starts proposition for years. Starting with the formal recognition of the job titles in the Office of Personnel Management’s Job Family Standard for Administrative Work in the Information Technology Group, 2200, only one CFO department or agency had implemented the titles by the enforcement timeline. Even today, many departments incorrectly use program or project management as parenthetical subtitles for the IT Specialist title – notwithstanding OPM’s restrictions on permissible subtitles (p. 8).
Pushing this envelope envisions program and project management portals that provide both team and public visibility all the way down through the work breakdown structures, sprint planning, velocity metrics, document libraries of all program and project artifacts, and discussion forums. This is in stark contrast to the current federal IT dashboard that, as has been pointed out to the CIO’s office on more than several occasions, is a mere façade (keep in mind that healthcare.gov had green light status right up until it completely failed and that almost all updates are manually produced XML feeds, not PMIS-to-PMIS sources of truth).
Architectural Modeling
Under Dr. Scott Bernard’s leadership as Chief Federal Enterprise Architect within the federal CIO’s E-Gov office, federal enterprise architecture has matured to a common approach and methodological foundation that was here-to-fore absent. That said, many CFO departments and agencies have allowed their initial efforts in EA to wither, only to discover they have to create Chief Data Officers because nobody was keeping track of what would have been obvious in any well-maintained EA repository!
Pushing this envelope envisions a national repository of EA models, using any of the NIEM tools for at least all “major” and “strategic” IT investments. While OMB Exhibit 300 “major” investment models could be managed by any of the CFO departments or agencies, those designated in a new category, “strategic” (think healthcare.gov), would be managed by the CIO’s E-Gov office directly. These models need to reflect not only the initial, developing model, but the progressively defined, emerging model using round-trip engineering and development.
User Experience Modeling
User experience is a relatively recent addition to the information technology discipline but, from a public engagement perspective, it’s the single greatest bridge between project teams and stakeholder constituents because, as the experience takes shape progressively, most stakeholders will be able to visualize the usefulness of an emerging application because they’ll literally know it when they see it.
Pushing this envelope envisions a national repository similar to the EA model in the previous envelope but focused on the user experience. Elements such as Design (balance, contrast, emphasis, rhythm, and unity), site structure, page and dialog wireframes and comprehensives could all be addressed in this publicly available repository for all “major” and “strategic” IT investments. By way of an example, think of this as a national repository of in-progress project user experiences organized like those possible in Axure RP.
Collaborative Development
Development has evolved from the tail of a sequenced set of step-wise, massive document-driven process, to product-focused, stakeholder engaged, incremental steps with tangible, usable results with every step. With most contractor-lead federal IT projects it still ends up as an over-the-wall effort with costly and time-consuming serves and volleys back and forth between the contracting organization and the contractor. What’s missing in this entire picture is the public – the sponsoring stakeholder.
Pushing this envelope envisions not only collaborative development with publicly available Github repositories, but use of the Federal Acquisition Regulations award-fee mechanisms to incentivize best-effort-first code at the minimum-viable-product (MVP) stage. If public stakeholders fork the MVP code and provide 25% of the final code that gets deployed, the contractor would only see a 75% award fee.
Well, those are the Four Envelopes of the new paradigm I’m proposing at the outline level. Next I’ll look at each of the envelopes individually to see what the full extent of the paradigm could be like, followed by some of the many barriers that exist to realizing it, and how we might restructure the executive incentives and organization to facilitate adoption.
Richard L. Warren is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.
Leave a Reply
You must be logged in to post a comment.