or…
WHY SO MANY I.T. PROJECTS FAIL
Information Technology solution RFPs are generally outsourced for one primary reason – internal resources are too busy to do it.
It’s a sound, but insufficient, reason. Here’s why.
Frequently, IT people are not superior communicators. The IT discipline requires precision, but not nuance. Its disciples exercise control more often than collaboration.
Generally their knowledge of the business domain is viewed through an applications lens. They may have an intimate knowledge of the business rules but little understanding of the marketplace which spawned them. They may have an adequate understanding of the incipient changes which are driving the need for new solutions but little comprehension of the evolving opportunities which a new application could exploit.
The business domain experts, on the other hand, are struggling to succeed with inadequate solutions. They probably have some good insights as to where the marketplace is going, what the opportunities may be, and perhaps a reasonably sound understanding of today’s rapidly evolving technologies. What they lack is an understanding of the complexity of work that goes into making ‘user friendly’ interfaces that work with all of today’s consumer and business gadgets.
Both the IT folks and the business people may also suffer from tunnel vision.
The IT people are somewhat hobbled with a concern for integrating the new solution with the old. Or with supporting new technologies and software tools within decreasing budgets. These ARE serious concerns, but they should not override genuine business imperatives.
For their parts, the business people have organizational views of the issues: sales and marketing know what the customer wants while finance and operations know they can’t afford to give it to them. We’ve all seen the cartoon of a kid’s vision of a swing and how it’s different from what actually is built. Then there’s the legal backstop! More on that issue later.
So, out-sourcing the function is the right way to go, but to whom can you turn?
Writing RFPs is a staple of every consulting firm, both large and small. Often they know your business from other work they have done for you. Perhaps they did the feasibility study, or the annual audit. They will almost certainly have up to date knowledge of the technology domain. They may also have done similar work for others in your field, either direct competitors, or enterprises in the same business but a different geography.
These are all good qualifications.
But as expert witnesses in several failed IT contract litigations, and as advisors in project turnarounds we have frequently traced the root causes for disputes and setbacks to flawed RFPs, albeit written by ‘qualified’ outsiders.
| We have even seen a situation where the customer refused the recommendation of three different vendors who all declined to bid unless a specifically proscribed development tool was allowed. |
The most common mistake made in RFPs is to define the solution rather than the business problem to be solved. Not only does this limit the distribution of the RFP to the prospective solutions providers, but it also circumscribes their ability to provide the most cost-effective and innovative solution. In a similar vein, limiting the choice of tools or approaches to achieving the ends can be detrimental to a collaborative working arrangement and getting the job done in the required timeframe.
Another impediment to optimal solutions is defining non-business criteria as mandatory. Leading edge technologists often fall into the trap of defining self-limiting requirements which evolving technology will make obsolete before the project goes live.
In our experience, non-prescriptive RFPs elicit more cost-effective and innovative options from which to choose.
In many cases, especially in the public sector, real or perceived policy directives limit the distribution of the RFP to ‘safe’ suppliers or vendors of record. These vendors have often gone to a great deal of effort to establish their credentials, but it doesn’t make them the most qualified to do a specific job. Neither does it preclude them from outright failure, as we have witnessed far too often.
Now a few word on legal protection. It’s a false premise!
|
Good fences make good neighbors … But they shouldn’t have razor wire on them |
No financial compensation is adequate if your business fails through a failure of the IT solution. Nor will it enable the completion of the project on time though another vendor. As a rope to keep the vendor’s feet to the fire it has rarely been shown to be flameproof. At best it might provide unearned income to the enterprise in a far distant financial period.
So by all means have a strong contract, but also ensure that the vendor can have a collaborative relationship with your organization and can be open and honest about its issues, unexpected challenges and revised recommendations.
In any event, agreement to a provided contract should not be a prerequisite for a valid response to an RFP. Successful contracts are the result of negotiation.
Failure to encourage this openness in contract determination and subsequent management will preclude preparedness and contingency planning for delays, hinder the provision of additional resources and hamper expectation management across the spectrum of stakeholders in the project’s outcome.
| No matter how much you pay, or what the contract says, the vendor cannot implement a solution without a great deal of effort from the customer |
A contract, by definition obligates each party to certain roles. But paying for deliverables cannot nor should not be the only obligation of the customer. The responsibility for effective implementation of a functioning system must be shared, through participation in the design, testing and cut-over planning. Signing the contract and getting back to business as normal for the customer is a prescription for failure, no matter how dedicated the vendor is to the project.
| Seemingly simple tasks can require significant effort, while others might cost nothing – let the vendor advise! |
So, at an early stage, the writer of the RFP must work with the customers to communicate their obligations and convince them to accept for themselves those which they can manage more effectively than the prospective vendor. This is an area where the writer’s experience as a vendor can be very useful. Understanding the other party’s issues on bidding for business can favourably influence the cost of the solutions and the risk profile for the project. Issues can range from the length of the contract term, to intellectual property ownership and re-use.
While it is vitally important to accurately define the scope of a project, and the respective roles of provider and customer, it is important to allow bidders to have input into the scope of their role. Artificially imposing unreasonable roles, or equally precluding them from natural roles will affect both the cost of the proposals and, perhaps, preclude a satisfactory outcome. The final scope is best left to the contract negotiation phase, although the bidders’ approach to the comprehensiveness of scope may be included in the evaluation process.
The Evaluation Process
Developing the evaluation criteria, then weighting them appropriately, is perhaps the most difficult part of the RFP writing process. It is critical that the bidding community understand generally how they will be evaluated. However it is equally important to allow them, through the criteria, to propose innovative solutions which may not have previously been considered.
In the public sector there is generally a proliferation of rules and regulations designed to demonstrate fairness and to protect the public purse. A good deal of care is required to ensure that these rules are not broken, or even perceived to be broken. It is equally important, however, to ensure that the selection decision is not made on some arbitrary or irrelevant consideration, such as price or parochial considerations.
It is worth re-iterating here, that mandatory requirements are a major impediment to effective evaluation processes, so should be very selectively imposed upon bidders. There is invariably another way to get the job done!
| Most project methodologies include a project audit, or health-check, yet they are rarely done. |
In large projects these is an increasing inclination to require a huge insurance policy against failure. In our experience they are a complete waste of money, which the buyer pays for. A much more effective assurance of success can be obtained by providing for a mutually agreed third party health-check of the project at each stage gate in its completion. These are generally less expensive than insurance and reflect collaboration rather than suspicion.
Summary
IT projects continue to fail to meet customer expectations in over 50% of cases, a statistic that has remained unchanged in over 30 years. Many fail outright, generally after significant investment in dollars and time.
RFPs are the bedrock upon which most projects are based. They consume a lot of time and effort and should be done properly.
The writer of the RFP should therefore:
- Be knowledgeable about relevant technologies, but not dogmatic
- Be able to grasp the critical success factors of the business as it relates to the solution
- Be fully competent to define and/or validate the requirements for a satisfactory solution to the business needs
- Express business requirements in business outcomes focussed terms
- Fully describe the business environment within which the solution must operate, without prescribing the solution itself
- Be able to research and discuss where the business and technology market may be evolving to
- Be able to build consensus within the business about its future needs and opportunities
- Understand the procurement policies which affect the business, and effectively argue their limits, exemptions and implications
- Have a broad understanding of the vendor marketplace, beyond the obvious providers
- Understand the benefits and limitations of standard contractual terms and be able to discuss and negotiate with the business’s legal advisors, and ultimately with the selected vendor