Feature

IT project strangulation in government

Government IT projects are notorious for both their complexity and for having a high failure rate. Randy Bablitz of CareWay Informatics argues that the complexity of government organisations themselves and the resulting layers of bureaucracy can be the major causes of failure, and that this is unlikely ever to change.

Track record

Overwhelming evidence demonstrates that governments are inept at running information technology (IT) projects. Despite their dismal track record globally, governments must continue to procure and implement expensive, complicated information systems.

It seems that governments are far more successful in other publicly funded feats, such as the construction of a hospital or a bridge. Although some construction projects may come in over budget and late, virtually all of these projects are completed and satisfy the original project requirements.

But for IT projects, governments seem to have muddled the lines between what they should and should not do at the 'IT construction site'. Only a fraction of these IT construction sites reach a successful completion, but can you imagine New York or London full of half-completed buildings?

Structure and process

Every government is a complicated organization and, at each level, co-dependent agencies support diverse and sometimes specialized business functions. Within this enormous bureaucracy, the customer agency, as a section or department, must deal with its peer agencies even though these peers may not fully understand the business objectives of the customer agency. It’s no surprise that the business objectives of a cluster of peer agencies in the same department may be overlapping, parallel, or even pulling in opposing directions.

Priority and funding for any IT initiative comes from management. Management encourages the centralization and standardization of IT services, in the interest of compatibility and cost-saving. And so, for any variation from the organization’s existing vanilla standards, the customer must prove that the new requirement is unique. Another agency, responsible for common procurement within the organization, will review the new requirement and do its best to fit it into an existing product category.

The common procurement review team may be totally ignorant of the supported lines of business. Examples might include large, specialized information systems for healthcare, the police, or the military. To make any headway, the customer will have to educate the review team. But, once priority and funding are finally granted by management, the procurement process may begin.

Requirements

For approved initiatives, documents are submitted to yet another government department that may own the procurement process for everything: socks, trucks, reams of paper, and yes, a sideline is information systems. The cycle of requesting proposals and bid evaluation is not easily adapted to technically pre-qualifying specialized software or system vendors, or for the requirement for site visits where the customer’s functional team must go out and evaluate how well a system works.

The bid evaluation is ‘requirements driven’ and compliance is measured primarily by what vendors say. The customer’s assessment of what vendors have actually done for similar clients may carry less weight.

Prospective vendors look at the mandatory requirements for bid preparation, perhaps requiring integration of old and new products, and recognize that submitting a bid is an expensive venture, demanding considerable analysis and effort — with a very serious risk of no return on the investment.

The vendor may jack up prices on a bid and carefully wordsmith the proposal in an effort to refer risk back to the government. Many capable vendors will walk around a troublesome government request for proposal. The vendor’s non-government customers may be focused and talented, offering the promise of a lucrative contract with a fast turnaround and a successful implementation. Sadly, the government can only evaluate the bids that are received. Does this subset of received proposals include the best the marketplace and technology have to offer?

In some jurisdictions, another dimension is added to this staggering complexity — bilingualism. Many important project documents must be produced in two official languages. Ensuring that both versions are synchronized and clear, through the amendments, the question and answer process, and bid evaluation, requires a coordinated effort.

In some cases, even the software solution must be bilingual — not an easy undertaking. Imagine tackling the tasks of finding genuinely off-the-shelf bilingual applications, and duplicating training, user manuals and instructions, helpdesk support, and all application patches and updates in perpetuity in two languages. Imagine the task of assuring the quality of data in two languages.

Humanity

Meanwhile, at some point during this lengthy definition, funding, and procurement process, the government customer agency may lose its ‘visionary’ player. That unique individual, the key proponent of the initiative, moves on to whatever. Who will guide the customer agency through the resulting business transformation? Imagine how many promising government IT ventures have died in obscurity shortly after conception because the key proponent left the scene.

For those projects that are successfully birthed, government requires highly skilled workers. There are many good workers in government, but their number, skill, and experience are finite. Specialized workers must be secured from a very competitive market by a human resources department that is burdened with corporate direction on: job descriptions, classification, pay and benefits, collective agreements, nationality, race, gender, and a lethargic hiring process.

Somewhere in that mix comes the requirement for competence at the job. Finding skilled workers is tough enough. Security clearances are also required and this is another very slow process. For skilled expatriates, it may take many months to acquire a security clearance. Many skilled workers find they must chose between another immediate job offer in the industry, or waiting for that other government job to come through. With any added language requirements, it’s no surprise that acquiring the best candidate is difficult.

Sometimes, human resources departments may propose another worker, already in government, who is suitable to come into the position immediately, to receive on the job training to meet the performance requirements. Managers reluctantly receive these ‘gifts’ asking, “Why is this person available?” If the employee doesn’t work out, they know, it’s nearly impossible to fire a unionized worker without a considerable effort from a determined manager who would have to remain and outlast this lengthy exorcism.

The project director (PD) typically represents the customer agency, and the project manager (PM) is the representative of the information management organization charged with delivering the solution and related training. The PM and PD may be from different worlds professionally and, for longer projects, personnel turbulence guarantees that neither of them (or their respective bosses) will be there for the duration.

A vendor is providing the product, and perhaps technical services. Both vendor and government technical services must work together. Lines of responsibility and accountability become obscured. Hence, the government has selected another mechanism to manage the functional, technical, customer, project manager, implementer, and vendor relationships — the integrated project team.

Conflicting objectives begin to surface including: the customer’s desire to succeed in acquiring a solution, the vendor’s need to turn a profit, and the need for all to ‘look good’ independently before their various masters.

The desperate belief in the merit of an integrated project team as a panacea is misplaced. A capable vendor will exploit this prize opportunity, because generally, the vendor’s team is, above all, competent at generating revenue within the targeted government system. Remember, the vendor helped wordsmith the contract and will make a point of ensuring a capable project team remains on site to run bamboozling contractual circles around transient government managers.

Given these complexities, a government may rely on an alternate source of expertise and manpower to assist the customer agency — consultants. Consultants may be employees of a larger company, independent contractors or sub-contractors who prefer to earn their living in the free market place. Many of them have previously worked within the government.

The consultants may or may not be competent on functional and technical issues. There are pros and cons to using contractors. There are limitations and strict guidance to control the process around hiring consultants, causing delays before hiring and then, there is potential for disruptive contract breaks. The government is appropriately concerned about maintaining their hold on accountability and responsibility. Can the government afford to fully trust a consultant?

One of the common limitations in project work is that a contracted consultant must never sign off or assume any formal responsibility on behalf of the government.

Home grown asphyxia

Governments face pressure to buy domestic products and services. Customers from within government and taxpayers have asked questions about 100% domestic solutions when they fail to achieve the desired outcome. Sometimes a product might be acquired at bargain basement prices from offshore with the promise that politically opportune industrial spin offs will be directed towards a specific constituency.

With reflection, some examples may come to mind. When questions on procurements are raised, the government may review procurement policy and tighten things up. But, this makes it even more difficult for the honest workers who must navigate procurement ice flows on subsequent voyages.

Regulation is no guarantee against interference or back-room brokering. And those individuals who meddle in the procurement process for their own gain are difficult to identify, and more difficult to prosecute.

Conclusion

Managers at every level should be aware of these issues and make appropriate compensation in their planning for project oversight, human resources, grooming and succession of key players, and establishing key milestones where achievements can be measured before proceeding further.

We must remember that government structure itself may impede the effective management of IT projects. Typical procurement systems are not very adaptable or well suited to attracting vendors and then acquiring and implementing specialized information systems.

Customer agencies within government may fail to adequately support the implementation of IT initiatives and effectively manage the associated changes. The general-purpose information management organizations charged with implementation may be naive of particular business complexities and related user training requirements, and consequently, are ill-prepared to complete the project. The human resource challenges facing IT projects are considerable, even crippling.

Wherever it is mandated, bilingualism in information technology to support government operations will continue to be an expensive and troublesome requirement.

Will governments be able to make the necessary adjustments to become consistently successful in delivering IT projects?

Not in my lifetime.

Randy Bablitz, CD, MHA, CareWay Informatics.