Why so many Federal IT Contracts Fail and what to do about it

A percentage of this goes toward new projects, or what we now refer to as digital transformation. Policy makers in Washington would argue that far too many of these new projects fail, and few would argue with that assessment (though I’d be remiss if I did not also note that lots of government IT projects succeed). Why is that, and what can be done about it?

This is not a new topic. In fact, it has been discussed for decades – for example, ACT-IAC published a very thoughtful framework document in 2014 on the subject. But permit me to address it one more time and provide some possible remedies regarding mission critical IT projects. Let us start with a short list of reasons why many IT project fail. Consider the following:

• If your IGCE (Independent Government Cost Estimate) is poorly and inaccurately prepared, your project will likely fail.
• If you award a contract to a vendor who obviously and drastically underbids the contract to get the work, your project will likely fail.
• If you have weak Project Management on both the government and/or vendor side, your project is likely to fail.
• If your project schedule is drastically unrealistic, your project is likely to fail.
• If your project does not have strong and supportive leadership on the vendor and government/client side, your project is likely to fail.
• If your project has not employed an IV&V vendor, your project is likely to fail.
• If your project does not involve critical stakeholders early and often, your project is likely to fail.

While there are more reasons IT Projects fail, let me stop this list here. If this list is accurate, how do “any” projects succeed. There are simple remedies to all these maladies. Let us start at the top.

Relying on an inaccurate or poorly prepared IGCE

Typically, the government client is not an expert on the intricacies of the digital transformation project they want to implement. Therefore, agencies call upon industry to propose solutions to meet the challenge. If the government were qualified to implement the solution, agencies would likely do it themselves.

But, if you are not qualified to design the solution, you are likely not able to accurately estimate the level of effort or the total cost of ownership for the state-of-the-industry platforms you seek. For example, I don’t know anything about installing a new roof for my home. When it’s time to do so, I am going to engage many professionals about not only how they would do the job but how much it should cost. To tackle this problem, government should involve industry early in the process. Simply putting an RFI (Request for Information) on the street does not provide level-of-effort information that would sufficiently inform the government’s cost estimate. To make matters worse, because of the government’s multi-year budget request process, agencies typically request funding for projects before getting their estimate completed. Then, when bids come in significantly higher than estimated, it makes government leadership appear incompetent — when in reality, their estimates were based on insufficient data.

The Remedy: One possible answer is to contract with industry to prepare these estimates and simply eliminate those vendors from the competition. This is so critical for government leadership to engage industry very early in the process — bringing experts in to simply discuss challenges you have and your expectations for the future. Allow them to share ideas about what is available and what the future of technology holds. Opening your doors to all will avoid perceptions of unfair competition. Yes, this will take lots of time to do, but will result in more detailed and realistic RFPs and more accurate IGCEs. That spells a win for both government and industry.

Accepting a Low-Balled bid

Low-balling a bid to simply get the contract is a well-known strategy in industry. Low-balling simply means providing an estimate that a vendor knows is significantly lower than other bidders will submit. But when a low-balled bid wins the contract, everyone loses.

Contracts that don’t provide proper revenue for companies to perform ultimately result in cost-cutting measures that significantly impact quality. While the government’s intention is to get the best product for the least amount of money, vendors can hire the least expensive employees and search for other ways to cut their cost to increase their profit margin. Is that what the government really wants? Instead, shouldn’t government leadership want the best and brightest working on their mission critical systems? The answer is yes.

The Remedy: Obviously, knowing if bids are low-balled requires robust and accurate IGCEs. As discussed above, getting better at doing independent government estimates is paramount. If IGCEs begin to truly reflect what a project should cost, agencies can agree to ignore bids that are plus or minus x percent of their IGCE. An adage says, “if the bid is too low to be true, it probably isn’t.” Still, agencies can’t simply eliminate bids unless they have an independent estimate that sets a boundary. The agency acquisition staff should caucus early with their internal clients to discuss what a low-ball bid might look like. This will set the stage for selecting a proposal that falls within those reasonable boundaries.

Allowing weak Project Management

As a former PMP Certified Project Manager I am somewhat biased, but I feel that robust project management is the absolute lynch pin of a successful IT project. Like a wagon lynch pin stops the wheels from falling off the cart, so does the PM in an IT project. They ensure projects don’t have run-away cost or major schedule fluctuations.

Here are two additional thoughts to consider. First, competent project managers must exist on both the vendor and government side of the project. And they need to work in collaboration to make sure the project remains healthy throughout. Second, IT Project Managers need to be leaders, not just strong technically. Oftentimes, vendors will hire technically strong PMs who don’t possess the interpersonal skills necessary to maintain a cohesive high-performing team. Similarly, government agencies often will simply assign an available person to the PM role, not understanding the specific skills necessary to ensure a successful project.

The Remedy: Agencies need to understand that selecting a government Project Manager should be done with the same rigor used when selecting the vendor. What skills sets, personality traits, and experience the candidate has are just three boxes to consider when making this selection. Leadership should interview carefully and be very selective about the PM hired to oversee mission-critical projects. Additionally, the government should have serious discussions with the vendor about the type of Project Manager they expect from the industry side. While the government may not be able to veto the vendor’s selection, having a conversation later about performance will be easier.

Having an unrealistic project schedule

While some projects have a forced schedule, such as those resulting from legislative changes and mandates, many projects are allowed to plan for realistic implementation timetables. Often, however, project schedules will be set that have nothing to do with how long it should really take to do the implementation. Inadequate project schedules tend to significantly increase risk.
While the big bang approach to systems implementation is somewhat a thing of the past, there are still multiple other ways to implement an IT project that support risk reduction.

The Remedy: Phased and rolling approaches that utilize agile methods and hybrid approaches are excellent ways to properly sequence a project. I urge leadership to avoid artificial reasons for project scheduling, such as “to complete before the end of an administration.” That rarely ends well. In most instances, projects should have aggressive but realistic schedules. Given that almost all IT projects experience unexpected delays, schedules should reflect this certainty.

Missing or detached leadership

As a long-time senior executive leader responsible for the implementation and maintenance of many mission-critical systems, I would often complain to vendors about only engaging with their top brass when there was a problem. Let me send this very strong message to all vendors large and small: senior company leaders should visit and engage agency customers on a regular basis!

What does regular mean here? As an example, if your company is implementing a multi-million-dollar digital transformation project for a customer and you are not visiting and engaging top leadership and project management at least once a quarter, you have been negligent. Engagement does not have to be an all-day-long affair — in some cases it could be a half hour conference call. Contacting your client when things are going well will make discussions go much better when things go wrong. And trust me, on large projects, things will go wrong.

The story rings true on the government side as well. System owners need to update and engage agency top brass early and often and insist that they take ownership of the project success. Again, when schedule changes and/or additional funding is required, those discussions will go much smoother.

The Remedy: Formally document in the project plan when touch points with leadership will occur. More importantly, given the audience, be decisive about what and how information will be shared. These touch points will pay dividends, especially if the project experiences challenges.

No IV&V Support

No matter how excellent of a senior IT manager you are, you simply cannot keep track of all the moving parts of a complex IT project. In addition, when new systems are being implemented, you still have the job of maintaining the legacy system, thus making oversight of the integration work seem like double duty. As a CIO, I insisted on having IV&V (Independent Verification and Validation) for any project over $5 million. IV&V lowers project risk by tracking every moving part in the project and identifying problems or anomalies early. For example, my IV&V regularly reviewed the projects Requirements Traceability Matrix (RTM) to ensure that every requirement paid for was indeed provided. Additionally, my IV&V vendor regularly reviewed and updated the Risk Mitigation Plan and Log to ensure we were prepared if any known risks were realized. These are not tasks that I had government staff available to do. Without this work, however, project risk increases dramatically.

The Remedy: When budgeting for a large and mission critical digital transformation project, include IV&V services as a necessary and risk-reducing expenditure. The early-warning data you will receive from such services will pay for itself, and will likely allow you to course correct more quickly. Additionally, having vendors aware that an independent third eye is keeping track of project progress is never a bad idea.

Avoiding or minimizing Stakeholder engagement

Early stakeholder involvement is the oldest no-brainer in the IT world. Yet, I continue to see agencies take a “build it and they will come” approach to digital transformation — such projects will likely fail. Not only does this approach result in user and stakeholder confusion, it also creates anger and an adversarial relationship between you and the users you are trying to serve. Keep in mind, simply asking users for their requirements is not enough. You also need to ask them about their challenges, their schedules, what they like or dislike about the legacy system, how often they want to be updated, and what their expectations are.

The Remedy: Customer engagement is about more than the requirements of the system. Engagement includes how the users interact with the system, how the system supports their work activities, the frequency with which they use the system, and where they use the system, just to name a few important questions to be answered. Getting the answer to these types of questions creates the true partnership that is required for successful IT projects. Building this “early and often” type engagement paradigm should occur at the same time the charter for the project is developed. This will cause all stakeholders to feel that they got in on the ground floor of the project, and that engaging them wasn’t simply an afterthought.

Conclusion

This post discusses only a few reasons why IT projects fail. The truth is, I could teach an entire semester course on why projects fail to meet expectations. The good news is that every challenge has a solution, if only leadership would employ them.

Building accurate IGCE’s by engaging industry early, selecting the best-priced vendor, involving leadership early and often, employing highly skilled project managers, including IV&V in project budgets, and making stakeholders critical players in the process are some remedies to significantly decrease the number of failed government IT projects.

 

 

 

 

 

 

 

Image by macrovector on Freepik