Too Big to Fail: Why Clients Pay Too Much

Too Big too Fail: Why Clients Pay too Much

When a projects budget exceeds 50m, there should be at least three separate implementation vendor contracts and the projects functionality should be broken into two or three components, with each component drawn up in its own contract.

There should also be a separate contract that supports the Integration Center, the set of services that enables inoperability, service-oriented architecture, and integration with external business partners.

Large projects too often wind up costing too much, taking too long, and delivering less capability than expected. They consume way too much money for ongoing support and enhancements. These consequences occur because sponsoring agencies places too much responsibility, and with it too much control, in the hands of a single system integration vendor. Sponsors claim that they allow a single vendor to take charge in order to have accountability; if the vendor does them wrong, they’ll have a single throat to choke.

The bad news: when a project gets too big, the throat becomes too big for the sponsor to get her hands around. Power shifts from the sponsor to the vendor. In the public sector the repercussions of this shift in power are exacerbated. Under public scrutiny, projects become “too big too fail.” The fear of adverse publicity makes a continuing a project, albeit destined for mediocrity, preferable to publicly admitting failure.

The argument in favor of large projects points to the need to address the end-to-end solution and ensure that all the pieces fit together. Other arguments in favor of large projects reveal concern about the cost of conducting multiple procurements, or the potential of having to manage multiple contracts and multiple vendors. For many, a single vendor provides the critical mass of on the ground expertise to shift resources where needed, to facilitate more effective communication across project teams, and to eliminate finger pointing.

Twenty years ago it was difficult to design a system that would allow different subsystems of functionality to merge and work together. Especially if they were built at different times with different technologies. and done by different vendors. Today, these problems have been outcome through advances in technology standards for web services and design approaches based on a service oriented architecture that takes advantage of web service technologies and standards.

Unfortunately, the same people and same mindsets that muddled through the “jaba the hutt” monolithic systems of twenty years ago are still dictating how to organize projects, design solutions, do the procurements, and manage today’s vendors. The languages have changed from Assembler, Cobol, and Powerbuilder to Java and C#, but the inventive spirit has been misdirected into figuring out how to replicate the rigid systems.

SOA

Large projects should follow a service-oriented architecture. This is NOT a technology. SOA is an approach to the organization of software functionality. Each major component should be separated and completely independent of other components. Components constitute the foundation of SOA – an industry best practice and State mandate. When components are drawn up independent of one another, there is no technical or business need to have the same vendor build every component that will be knitted into an enterprise-wide business solution.

SOA often over-promises benefits. Still, a benefit that is certain is that changes and future maintenance will be faster, better, and cheaper.  When components are divided, and stand apart from one another, less time and effort are needed to investigate where to make a change. It also reduces the potential of unintended consequences spilling into other components.

Visibility

When the separate contracts are used, each major component has more visibility. This ensures that the design and build enforces the desired independence between components. A separate contract for the Integration Center provides the specifications that enable components to be called, orchestrated, choreographed, and monitored using industry standards.

Added Leverage

Multiple contracts gives the client added leverage in contract management efforts with vendors who are typically far more experienced in winning change control battles. If the client is not satisfied with the performance of a vendor on one component of the contract, the client can change vendors for that contract without disrupting progress on the rest of the project. Even though components address separate functionality, they will use the same design standards, technologies, and management practices. This makes replacement, of one vendor for another, less disruptive and avoids the “nuclear option” that is rarely more than an idle threat.

More choices post-implementation

After implementation the client will have more choices among vendors to perform future enhancements and maintenance. The monopoly that the single vendor presently enjoys translates into a monopoly, also, on maintenance costs.

About the Author:

Steve Williamson is a business process architect and enterprise technology planning consultant. He has over 30 years of experience working with executive and project management and is an expert at defining and delivering information management and technology solutions. You can find him on Linkedin.

Leave A Comment

WordPress spam blocked by CleanTalk.