Debating Forrester Research: Service providers and failure
Wednesday, February 11, 2009 02:00 PM
A blog post by the analyst, which pushes virtually all blame for IT failures onto technology buyers, may have provided a narrow view of the dynamics in project management.
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.
Michael Krigsman is CEO of Asuret, a software and consulting company dedicated to reducing software implementation failures. He is also CEO of Cambridge Publications, which specializes in developing tools and processes for software implementations and related business practice automation propjects. This article was first published as a blog post on ZDNet.com.
There are currently no comments for this post.