Recently, there has been a good bit of media attention recently on failed Federal IT projects.
The troubled launch of HealthCare.gov highlighted failures in the areas of technology, management processes, and leadership.
The highly-publicized unsuccessful launch quickly led to calls for reform of Federal IT procurement practices.
In another recent example, the Air Force abandoned a $1 Billion investment in a supply chain modernization program.
Unfortunately, these are just some of the latest in what has become a long pattern of failed Federal IT projects.
Government is not alone in its struggles to successfully deliver complex IT systems.
The Persistent Root Problems
Studies over the past two decades have closely examined failed government IT projects. Interestingly, both the findings and the recommendations from these studies are remarkably well aligned. Repeatedly the findings have pointed to common root causes:
- Failure to divide large IT projects into manageable, incrementally-delivered chunks
- Constantly changing or inadequately defined requirements
- Indecisive or inadequate management oversight, and
- Lack of experience of the government team
Congress has repeatedly tried to address the issue. The Federal IT Reform Act (FITRA) is the latest of these attempts. However, I observe that none of the root issues require legislative fixes.
To the contrary, I worry that legislation will give false optimism of solving the persistent root problems and may result in unintended negative consequences.
Government is not alone in its struggles to successfully deliver complex IT systems. Unfortunately, there are many private sector companies who have cancelled large IT projects after enormous cost overruns or disastrous roll outs.
Successful IT Projects Share a Pattern
On the other hand, I have visited many private sector as well as government organizations who have successfully delivered large, complex IT projects. In almost every case, I found that a successful IT project had a similar life-cycle pattern. Specifically, early development stage euphoria gave way to missed deadlines, cost growth, and loss of confidence. Organizations that recognized these symptoms of trouble early and took decisive action were typically successful.
The actions taken were surprisingly common:
- First, the project responsibility was realigned under a top-level line manager who had clear accountability for the success or failure of the project
- Second, a rigorous process was instituted to halt requirements creep
- Third, the project was divided into small increments with delivery dates cast in stone; increment content was adjusted if necessary to ensure delivery on schedule
- Finally, a regular and detailed project status review process (typically monthly) with the top level line manager was instituted
Applying the lessons learned from successful large-scale IT projects across the Federal government would appear straightforward. In my opinion, it is not. The structure of the Federal government and our IT procurement processes hinder the clean lines of accountability and the timely decision making needed for success.
In the Department of Defense (DoD) and the Department of Homeland Security (DHS), procurement oversight processes are stiflingly complex and cumbersome, and often become a distraction to focusing on the end product. The rollout of HealthCare.gov painfully exposed the ad hoc oversight and decision processes used in the Department of Health and Human Services and the Centers for Medicare and Medicaid.
Two Mandates for Success: Fix Federal Procurement
Even if there is no simple fix to the problems, I believe that there are two proposed mandates that can dramatically improve the likelihood of success. The most important mandate is easy to understand but deceptively hard to implement.
Mandate #1: Break larger IT projects into increments of useful capability that can be delivered in time periods no longer than 6 to 12 months (ideally shorter).
In my experience rapid delivery of useful capabilities is the single best way to enhance the probability of success. Delivering useful capabilities quickly, even if they do not yet fully meet user needs, exposes the alignment (or lack of alignment) between the development team and the end users and dramatically accelerates project progress. If appropriate, poor initial delivery permits early cancellation of what would likely be a failed IT project.
The mandate seems simple. However, in most government organizations, the oversight and contracting processes are so cumbersome that it is extraordinarily difficult to award a contract or task order in 12 months, much less deliver useful capability in this period of time.
The threat of project cancellation will motivate the government team to fix the process and cultural barriers that are strangling Federal IT projects.
There is a need for a radical change to the well-entrenched processes and culture. To achieve this culture change, I would further suggest Mandate #1 include a firm policy that any government IT project that did not deliver usable capabilities to end users (usually a small subset of the target user population) within 12 months would be automatically cancelled.
I believe that this seemingly radical policy is required to effect the needed culture changes. The threat of project cancellation will motivate the government team to fix the process and cultural barriers that are strangling Federal IT projects.
Mandate #2: Ensure that each large IT project has a clearly designated senior level person who is personally accountable for the success or failure of the IT project.
There is no substitute for accountability properly placed in an organization. As a primary focus, this senior person must ensure that requirements decisions and organization changes resulting from the IT system are dealt with in a timely and decisive manner. As such, ideally this person should reside in the mission area of the agency.
There is no substitute for accountability properly placed in an organization.
Clearly, the quality of the government project technical management team is important as well. To be successful, there is a need for the government to have people with competent technical and program management skills. However, I believe that most government technical and management skill weaknesses, if they exist, can be overcome if the two mandates suggested above are implemented.
However, the inverse is not the case. A strong government technical and management team will not be successful if the project is too large or there is no senior level person who is accountable and can make decisions necessary for success of the IT project. At the end of the day, there is just no substitute for good management.
The Federal government has the ability to dramatically improve IT procurement by implementing the two suggested mandates. The mandates are not conceptually complex. What is required for real progress is stronger leadership on the part of our government officials, something that cannot be achieved with new legislation.