Bad leadership causes failed IT
Summary: IT failures continue to plague organizations across virtually every industry. Poor business leaders who don't possess the skills needed to manage change effectively have created this mess.
This post was written by guest blogger, Mike Kavis, a senior enterprise architect. Mike describes how the roots of failed IT projects lie in management and leadership rather than in technology.
IT failures continue to plague organizations across virtually every industry. Poor business leaders who don't possess the skills needed to manage change effectively have created this mess.
There are countless articles about failed IT projects, ranging from outsourcing failures, SOA failures, technical architecture failures, and customer service failures. I outlined 10 reasons why large IT initiatives fail in a previous post:
- Poor Communication
- Underestimating or ignoring impact of change
- Lack of Leadership
- Lack of strong executive sponsorship
- Poor project management
- Poor Planning
- Trying to do it cheap
- Lack of technical knowledge
- Lack of sound business case
- Poor vendor management
This list boils down to three categories: technology, business, and people. You can probably count on one hand the number of folks that you've come across who excel in all three areas.
Most large business transformation projects fail because IT leaders don’t acknowledge, or at least underestimate, the impact of change on the workforce. These managers focus entirely on technical issues while failing to address the human side of change.
Driving change successfully requires creating a sense of urgency, communicating a clear vision, and addressing WIIFM (what’s in it for me) at all levels. Leaders must identify change agents throughout the company to battle resistance, while remembering success is about the people and not the technology.
Leaders often make a lethal mistake by not aligning technology projects with key business drivers, which is precisely why so many Service-Oriented Architecture and Enterprise Architecture initiatives fail. Both SOA and EA are long term strategic initiatives requiring many resources and a great deal of funding, which only worsens alignment issues.
When IT is not aligned with business drivers, IT makes poor architectural decisions that nobody on the business side will want or understand. Consequently, the business won't invest in these initiatives because they see no apparent benefit. This is where IT leaders must learn to speak in financial terms that the business will understand and appreciate.
Most IT failures are due to a team's inability to embrace changes needed to implement new technology. Nonetheless, leadership frequently points the harsh finger of failure to technology, which is simply the wrong place to look for solutions. No wonder IT failure rates remain so high!
The next time you see a major project fall apart, remember it's not the technology that failed but leadership that didn't measure up.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
From the Obvious to the execution
Having delivered some very successful projects myself, the biggest success factor is a clear delineation between, business, technical and project management. It is the interference between them that causes the problems, especially project managers thinking they are architects.
From my perspective, the business provides the focus and the technical leader provides the drive and manages the scope to the schedule, and the Project Manager ensures that our project measures are in place, e.g. burn rates, resourcing and does not get involved in tasking of the team, that is a technical function.
more on execution
Great points. It all starts with strong executive sponsorship, a clear vision and goals, a guiding coalition made up of IT and business, and a firm commitment to the cause. Too often projects rely on the heroic efforts of one "leader". True leadership engages many and empowers others.
Note: I am a practitioner not a philosopher. So this is coming from years of lessons learned.
Before alignment or execution ...
"We will successfully implement SAP in 2008," is not a business strategy. Too often the goal of the technology implementation is to implement technology, not to lay the groundwork for the benefits the technology will provide.
Too often, the thinking goes, "All the big companies in our space use [technology x], therefore we must use [technology x] to become a big company." And in a situation like this, no amount of planning, communication, leadership, sponsorship, spending or know-how is going to put the horse back in front of the cart.
Here's what SAP's CTO said
Lines of business know the what and IT knows the how (http://blogs.zdnet.com/projectfailures/?p=710)
This is a great statement of the relative roles for each group.
But you have to filter
solutions. I've seen projects fail because the IT staff were
either too naive to recognize this, or the Management staff
were unable to differentiate between the what and the
how.
For example, a project that I was brought into after it had
been going on for a while, included a hard requirement for
"intelligent product numbers". What the users really need
is a mechanism to query by attributes. The current design
will have many collisions in the derived numbers because
of the mechanics of it. This, plus some other requirements
that are beyond the scope of this reply, will cause them
pain later on.
The project spent a lot of time and money on the wrong
thing. Now I am facing two challenges: education of the
stakeholders and re-working design and code.
The use-cases were correct as stated, but the underlying
requirement and application of the use-cases is flawed.
Many projects fail because everyone involved fails to
understand that they don't always know what they don't
know. And they don't know how to express what they do
know.
As in all things, the problems can be fixed - but with a
cost (time, money, resources)
Good example
At the End of the Day, One Person Must Manage the Whole
Yes, the challenge is finding the one person who can speak or perhaps translate amongst the various domains, who is also a diplomat and a good horse trader, who understands at the big picture level where everything is, AND can oversee and execute.
And oh yes, has good judgment and isn?t afraid to make decisions.
It is IT that fails...
The second reason is due to a lack of skills in the IT department. Most IT workers are young and lack people skills as well as real world technical experience. All you have to do is deal with IT personel once or twice to see a gross lacking and the real reason for failure.
As long as we try to lay the blame on anything but its creator, we are going to fail.
Lots of overgeneralization here ...
Ideally users begin the cycle by defining a business need. Often, however, they don't define a business need -- they define a technology solution. They say, "We need x [software, platform, system, whatever]. [Buy, build, install] that for us." Or to every IT person's horror, "We just bought x. It'll get here tomorrow. How quick can you put it in?"
IT fails when it doesn't say, "Why do you need x? What are you trying to accomplish that you can't do now?" This should start a dialog that results in a business problem defined by the users and a technology solution designed by IT.
IT has its responsibilities, but I've seen way too many people on the "business" side of the house who were too young (or acted it), had NO people skills at all. Frankly THESE are the types who are always looking for someone to blame, instead of looking to step up as a team member and as a respectful colleague and work through a problem together.
So, I have to reject your post completely.
Project Manager
I would say the project manager (or maybe I should say program manager) should always be business-side, but in practice this is seldom the case because business-side people have "real" work to do and consequently don't have the time.
Wow, you've managed to insult every project manager ...
The project manager is often the go-between, managing both business needs and technical concerns. They should shepherd over the budget and the timeline, wrangle the stokeholders together, and make sure that the job is not only "done" but "done right", on time and on budget, to the satisfaction of the customer (i.e., the business stakeholder).
"real" work...
Anyway...
A project manager is supposed to manage people. There are people both on the business-side and IT side that are critical to project success. IT project managers usually have no authority and very little influence over people on the business side. Heck, sometimes they have little influence over either, because they live in some mythical project management group that is divorced from the rest of the management chain.
A project manager on the business side will generally have substantially more influence over business-side staff, and at least as much influence over IT staff as an IT project manager.
It can be difficult ...
I think what you're saying is generally true, but in my experience that has more to do with personality types, approach to the problem, and communication than it does with reporting structure. Business-side staff tends to respond well to PMs focused on solving the business problem better than they do to those focused on the technology implementation -- regardless of what part of town the PM grew up in.
It also depends on what your organization considers a Project Manager to be
I other companies, the project manager runs the project--- hires (fires), sets up the teams, arbitrates and coordinates amongst the various parties, manages the project budget, and owns the schedule (whose ever tool you use).
Depending on where you worked, the scope of authority of the PM is different.
project managers...
Hire/fire decisions are a little different. Large organizations tend to acquire matrix-like qualities (meaning being like a matrix organization, not the movie). I would argue that you have "project managers" and "resource managers" or "functional managers," and it is fairly common for the same person to play both roles, usually managing small projects that are focused within their own organization.
RE: Bad leadership causes failed IT [guest blogger]
RE: Bad leadership causes failed IT [guest blogger]
Personal opinion
Thanks for your kind words ;} I am familiar with all of the reasons that the PMI research has reported for project failures. It still takes leadership to implement them. It takes leadership to implement the PMI's best practices in an organization as well. My "opinion" is based on a combination of personal experiences, researching SOA and other culture changing projects of peers and the IT industry, and through my graduate studies which included four semesters of studying the PMI PMBOK and a graduate certificate in project management. Most of the failures that I was referring to were SOA and ERP failures that I have researched and not those of my company (we succeeded with SOA and don't do ERP). It is one thing to put a plan on paper, it is another thing to execute on it.