Leadership

Debating Forrester Research: Service providers and failure

Michael Krigsman takes issue with a Forrester Research blog post that pushes virtually all blame for IT failures onto technology buyers.

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

A Forrester Research blog post pushing virtually all blame for IT failures onto technology buyers caught me by surprise because it doesn't correspond to real world complexities of why IT projects fail.

The post asserts:

Project failure is rarely the fault of your IT services partner - even if it is, it is your fault for not managing the process effectively and pulling them up before it turns into a failure. The only time when the partner is to blame is when they promise to do something that simply is not possible - and again, they are probably just responding to your impossible requests.

Such statements reflect a simplistic and inaccurate view of the dynamics driving over-budget, late, and under-performing projects.

The project failures analysis

Service providers play an important role in the enterprise IT ecosystem, providing at least three important benefits to the market:

  • Specialized technical skills
  • Flexible labor supply, which can expand or contract based on customer's project demand
  • Best practices and experience for executing complex projects

In the best situations, third-party system integrators and consultants bring a large body of knowledge to the customer, which benefits from the provider's broad experience across multiple engagements. Consulting companies implement technology on a regular basis, making them specialized experts and a great source of detailed implementation knowledge.

However, problems arise when customer and service provider incentives and goals don't align in important ways.

IT Devil's Triangle. Virtually all IT projects involve three parties: customer, technology provider, and integrator. Each of these groups has its own independent set of goals, which leads to a series of interlocking, overlapping, and sometimes mutually exclusive agendas. Customers want low prices and top-quality work; consultants seek high margins and large projects; and technology vendors often bow toward system integrators since consultants are a source of vendor deal flow. Understanding why IT projects fail requires analyzing relationships among these three groups.

The best service providers place customer interests first and strive to contain costs. This generates good will, happy clients, and long-term relationships. However, consultants naturally prefer larger projects, which lead to more billable hours and higher profits, sometimes creating a conflict of interest with the client.

Sometimes, consultants are reluctant to push back against poorly considered client requests and actions that create higher billing without adding value to a project. For example, here's what I wrote about Deloitte Consulting's role in contributing to the Los Angeles Unified School District's (LAUSD) problems printing teacher paychecks:

I suspect Deloitte pussy-footed [pushing back against the customer], to avoid pissing off this big client. Deloitte, you're paid handsomely to get this stuff done and you are now failing. If the LAUSD isn't supplying information needed to fully configure and test the system (which I strongly suspect is part of the problem), then take stronger steps. If your paychecks were on the line, you'd call the president of the United States, if that's what it took.

Single-mindedly casting blame toward any one side of the IT Devil's Triangle is a losing proposition that fails to reflect the deeper causes of failure. Although I respect Forrester and its team of analysts, the post reflects a one-sided view that wrongly pushes blame exclusively to customers.

19 comments
JustMax
JustMax

Blaming buyers exclusively is like doctors blaming patients for not getting better or car mechanics blaming owners for not being able to fix a problem. Each situation is unique, but as was stated before - it is a partnership. There are customers who don't know what they want, there are vendors selling vaporware, there is internal politics game on both sides plus people are making honest mistakes. All that has to mesh somehow and finding single guilty party is difficult. Side note - it is somewhat rare to have a 100% failure. Prudent organization will have some use for knowledge learned, hardware/software acquired, etc. even for projects that didn't succeed in their main objective. Who gets the credit for the secondary hits?

casey
casey

Saying that Buyers bear the responsibility for their purchases is nothing like a doctor blaming a patient for not getting better; the patient is buying the doctor's services, not the other way around. And for those who consider this kind of work a "partnership" - inferring equal status and contribution in the relationship, nothing could be further from reality. The "P" word is hollow rhetoric used by sales and marketing types to convince buyers that they are the best ones for the job. A systems integrator or consultant is not a partner - they are hired for their skill and expertise, not as co-owners of project. And while there is no denying project failure can be triggered by any number of factors, the root cause can always be traced back to client - lack of due diligence, lack of risk mitigation, poor requirements, poor vendor management, poor project management, inappropriate resource or funds allocation -- you name it, the client ultimately owns it. As for less than 100% failures having some residual benefit ... maybe to a select few of the people involved, rarely for the organization. Most companies I've seen do not take a proactive position where failure is concerned (except maybe firing those responsible) and seldom is there a 2nd chance to do it right.

JustMax
JustMax

Let me ask you a different question. If project is a success, who is the main contributor then? I realize that victory has many parents and defeat is always an orphan, but... If vendor has nothing to do with the project failure then there is nothing to brag about in case of success. And lastly about do overs - in my personal experience, will not claim it for everybody - if project was supposed to address a real need, it will be tried again, may be with different people internally, definitely with different tools. Please, excuse my analogies, if your roof is leaking and first round of patching didn't fix it, you will be doing something until you succeed one way or another.

casey
casey

JustMax - I totally understand where you're coming from. But the question in play is not who caused the failure or success, but who is ultimately responsible. In my mind (and perhaps my mind alone) these are two different things. As you correctly point out, literal success or failure are almost always the result of a number of different players and interactions, not just one. But at the end of the day, the final responsibility rests with the party that started and paid for the thing in the first place. Does this mean that a vendor who misrepresents the capabilities of their product or people such that a failure occurs is not culpable? Absolutely not. But this does not excuse the client from not performing adequate risk mitigation to account for this type of behavior. Likewise, a vendor that pulls their client's butt from the fire to save the day should be congratulated, but it was the client who ultimately made the selection to bring that vendor on board in the first place ... maybe for that very reason. I know this from personal experience.

rlight
rlight

This is a great thread so far, and while I am not an expert, my observation of why projects fail is not just in poorly defined initial requirements or the vendor/partner lacking ethics (though clearly both of those senarios occur), it comes down to change management. That is, project success or failure is highly dependent on how effectively management, with the support/cooperation of the partner, can get employees to change their processes/behavior to adapt to the new system. The reality is, most people dislike change (just try switching the coffee or soda brands in your office.....) and will resist it even if it is in their interest not to. Am I off base with this?

axaris
axaris

Anybody here heard of the "Agency Theory"? I am convinced that in this theory lie the main cause for all these issues. Aligning motivation towards a common goal and adjusting rewards accordingly is not just a job for lawyers to put in contracts. Nor it is productive (especially by Forrester research) to be in the blaming business, after all they have been instrumental in providing excessive cheerleading during the IT bubble of the last decade. My 2 cents here, is that the motivation should become more clear and risk should be born accordingly. The conductor in this little orchestra is the integrator but paradoxically the entity that pays the bills is the client. And here is where the problem lies....

casey
casey

Ax - I like your analogy of the integrator as conductor. But it's no paradox that the client pays the bills if you consider the role of the client as promoter and owner of the venue in which the orchestra plays. Further extending this, it's the client who approves and arranges the advertising to promote the performance as well as carry the proper insurance (property, casualty and performance) in case something goes awry. It is also up to the client to do due diligence on the orchestra itself, validating every member if the investment/risk warrants it. And while I agree with your Agency Theory direction, the theory focuses more on performance rather than responsibility. Ultimately, it is the client who bears responsibility for the performance, regardless of its outcome.

mmondo
mmondo

... in that both customer and services supplier should behave as if each of them had full responsibility for project success. I.e., while suppliers are often to blame for taking whatever they receive from the customer at face value without thinking through the consequences (for lack of trying, or in the hope of charging later for inevitable changes), buyers are very often to blame for not defining their requirements (and thinking how smart they were in making it possible to change those later at will). An IT project is typically complex and depends on smooth cooperation of all parties involved. If one of the parties just wants to save (or make) a buck without regards to quality the project has a pretty high chance of failure. If the Forrester article and this discussion helps both sides to remember that they shouldn't even think of putting the blame of project failure on someone else then it has served its purpose. Maybe Forrester should write a similar post reminding suppliers of their problems as well.

robin
robin

In more than 35 years of experience with all aspects of system/software acquisition, I???ve been fortunate to have the perspective to analyze the process objectively across dozens of acquisition projects. Overwhelmingly, time and again the biggest reason for failure is the buyer???s inadequate definition of their own requirements. Effective buying starts with the buyer discovering and soliciting proposals for satisfying their REAL business requirements which provide value when satisfied. Instead, buyers almost always try to specify requirements of a product/system/software which they presume is what they need. This leads to two problems: (1) Even if delivered as specified, the product/system/software fails to provide value because it fails to meet the buyer???s REAL business requirements, because they weren???t defined adequately; and (2) specifying a product/system/software not only is not the buyer???s strength but also undercuts a primary source of the vendor???s value???the vendor???s presumed expertise in designing relevant products/systems/software.

PalKerekfy
PalKerekfy

I do agree with the reasoning. It is a mistake to put all the blame on one party. It is true that the customer has to manage the provider(s) properly. On the other hand, the vendor and the consultant possess significantly more in-depth knowledge in their business than the customer. Actually, this is why they are paid. If I (as a customer) knew it better, I'd do it myself. We, customers, have to do our part properly. We need to understand what they (consultants and vendors) say and promise. If we don't, we have to push them hard to translate their jargon into human language. We shouldn't believe the unbelievable (even if we would like to get it). But at the end of the day, it is the common responsibility of all parties to lead a project to success.

Celeroo
Celeroo

Michael/Steve, The way I see it is that both your perspectives have value in them. But first off, I think the Forrester article is very poorly worded. I can see that there is value to what Tim is TRYING to say, but his statements, on their face value, completely undermine what he is trying to get across (at least, that is how I am trying to see it). Michael is ABSOLUTELY RIGHT in his assertions that the onus lies on ALL parties involved. The biggest culprits (without taking recourse to studies and Standish reports) are: Poorly defined requirements - Buyer Poorly understood requirements - Provider Scope creep - Buyer Bargaining the hell out of the provider - Buyer Viewing the project only as a revenue source instead of getting involved and taking ownership and seeing the client's project as their own baby - Provider Communication gaps - Buyer and Provider There are many other issues dealing with the knowledge levels of both the parties involved, project management, etc. All of it goes to show that this is a PARTNERSHIP and the chances of success will diminish if transparency, communication, requirements management and a healthy view and understanding of constraints faced by each party is lacking on the part of BOTH the BUYER and the PROVIDER. We have series of articles and tips (and more to come) on successfully executing software development projects at http://www.celeroo.com/blog/

DGIM
DGIM

Must agree: this covers all the projects I have seen fail and probably most UK public sector failures. Including those that are happening now.

addicted2speed
addicted2speed

As with Success, Wars, Arguments, Agreements, and Dancing, Failures also require at least 2 parties. I am very surprised and disappointed at this shallow assessment from Forrester... although the post is almost a year old. Perhaps they have changed their analysis.

aghai
aghai

Michael is right that such statements blaming the customer reflect a simplistic and inaccurate view. An initiative or project that goes wrong can have many reasons for having gone wrong including failure by the customer and/or the vendor/partner. A partner who promises to deliver on what they know to be impossible is unethical or incompetent or both.

Steve Romero
Steve Romero

I can't believe I am doing this, but I have to agree with the Forrester contention that the blame falls on the buyer. As the "buyer" I must ensure steps are taken to enable success - which means I have the appropriate governance and associated processes in place to meet my goals and objectives. IT Governance ensures the enterprise has the "Structure of relationships and processes to direct and control the IT enterprise to achieve IT's goals by adding value while balancing risk versus return over IT and its processes." This includes critical governance processes such as Project and Portfolio Management, Building and Maintaining Applications, and Outsourcing Services. If I don't have the appropriate structure of relationships and processes, then I am likely to fail. As the buyer, I need to acknowledge, manage, and overcome the risks and challenges of the "IT Devil's Triangle." I can't count on the Supplier or Integrator to do so, which is why I am so bothered at my appearance of defending Forrester. The blog post is an obvious defense of the numerous partners that ignore if not exploit the absense of the appropriate IT Governance in it's customers. I would love it if all partners took it upon themselves to help us overcome our deficiencies and subsequent oversights and helped us "know the things we don't know." The reality is, this accountability falls on the buyer. Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/

LucasISG
LucasISG

Steve, you are dead on target when you state, ?As the ?buyer? I must ensure steps are taken to enable success? There is little doubt that the party paying the bill is wholly accountable for accepting the results. Your leveraging of IT Governance processes provides the guidelines for reasonable outcomes. However, there are equal parts of common sense, integrity, and trust that come into play when dealing with other people and understanding their agendas/motivations. It may take the ?IT Devil?s Triangle? to deliver the product. There has to be one side that bears the responsibility for success and you nailed it. Great post!

casey
casey

I've watched big and small companies for close to 30 years go through this same dance. The bottom-line is simple: it is the customer who initiates and ultimately pays for the work. The extent to which they seek to identify and mitigate risks across the spectrum of human and technological activities, from initial scope to service provider competency to internal staffing, it is the customer's ultimate responsibility. While it is true there are unscrupulous service providers promising undeliverable results and technology providers who tout features and functionality that may or may not be in their products, the customer as end-state victim - "they told me it would work ...", speaks to a lack of rigor and control in the planning and management processes. Mr. Romero posted simply and succinctly: "As the 'buyer' I must ensure steps are taken to enable success". Nothing more, nothing less.

wparke
wparke

The buyer is managing the project. The project fails. Either the project manager failed or no one is listening to the project manager (the later is my current source of frustration as I've previously posted). If there's no chance of the seller fulfilling a contractual obligation, the project manager should be able to tell this and switch horses in mid stream - THUS PREVENTING FAILURE

Editor's Picks