Leaders Play IT Blame Game - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IT Leadership // CIO Insights & Innovation
09:50 AM
Bill Hurley
Bill Hurley
50% Leaders Play IT Blame Game

It's not fair to just point the finger at technology or its implementers when IT projects go bad. Let's talk about the business team that originally defined the project vision.

As a CIO watching the firestorm on the nightly news, I sometimes feel like I'm back in the office. The project is late or incomplete. It's all the IT department's fault. Let's send in more support, more hardware, and more software. Bring in the outside experts to save the day!

If you've been in IT management for any length of time, this fire drill should sound familiar. Putting aside the political and hypermedia aspects of Obamacare, the reality is that the failure of is simply one more IT project gone bad. The fact that it's a highly publicized government initiative doesn't change the underlying issue. Nor does it change the basic approach organizations should take when putting big IT projects back on track.

Looking at the Affordable Care Act website, there's no cutting-edge technology at play. It's a website with commerce capabilities. Period. With that as background, I have to assume the issue is one of the following: Either a failure in the requirements definition, or a problem of business ownership and involvement (i.e., governance). Add the fact that it's a high-profile initiative with a range of opinions and even fewer solutions, and what you've got is a classic "Dilbert" situation.

[ Read our complete coverage of the launch here. ]

My Monday morning quarterbacking from afar: It appears there were both poorly defined requirements for and last-minute changes in project scope. In other words, significant modifications were made at the architecture level, with the major issue centered on registration flow.
For any big website project, changes to the registration system are more than simple code tweaks. They're a fundamental departure from the entire architecture of the application, both systems and data.
Normally, application modules expect the environment, especially data, to be in a certain state at each moment during process flow. But when you change underlying flow -- and thereby, the site architecture – there's more state changes than the modules originally tested. This means that procedures to gracefully handle issues aren't in place. The system is immediately exposed -- and things devolve into chaos.
A significant last-minute change in registration process suggests business flows and definitions were poorly documented. Otherwise, requirements would have been identified either in a prototyping, scrum session, or early iteration. Usually, the solution is to restart from that point, working your way forward on design development and deployment. This approach takes a lot of time and patience.

Alternatively, perhaps requirements were defined clearly -- whether correctly or incorrectly -- but project governance was poor. In any enterprise, IT is a service provider, one that must be managed. Non-IT business owners must participate in the project on a regular basis. My sense is governance failed on this project. Otherwise, a system this poorly designed would never have progressed this far.

Proper governance includes setting up "tollgates" that the business owns and manages. (Enterprises that excel at IT stopped saying, "I don't understand what those guys are saying" back in the '70s.) Both project team and governance body must understand the purpose of tollgates and measure successful project passage from one to the next.

Having senior government officials stand in front of the American public and imply that the problem is technical just isn't right. This is the classic cop-out companies use when IT projects go bad, and it demonstrates lack of ownership and accountability. Quite simply, the wrong leadership was in place from the beginning.
The key to any successful business project is threefold: ownership, accountability, and an ability to execute. The IT group certainly must take ownership of mistakes during design and development. The same group must also maintain control during testing, deployment, and ongoing management.
However, equally important is the business leader or team that originally defined the project vision. This group must be willing to take full responsibility, at any stage. Whether we're talking about a finance, marketing, legal, or any other business unit lead requesting a technology solution, each must be willing to step up and share blame if the project stalls.
Although the IT department surely can carry out requirements, a project can fall apart if its champions haven't constructed effective definitions. This process involves not only designing a viable business and technology model up front, but also mapping goals and monitoring benchmarks along the way.
It just isn't fair to always point the finger at technology or its implementers. Unfortunately, IT is often the odd man out in the blame game.
Bill Hurley is CIO of Westcon Group, a value-added distributor of unified communications, network infrastructure, datacenter, and security products. Before joining Westcon in 2008, he was a managing director with Marsh & McLennan, where he acted as global CIO for the Americas.

There's no such thing as perfection when it comes to software applications, but organizations should make every effort to ensure that their developers do everything in their power to get as close as possible. This Dark Reading report, Integrating Vulnerability Management Into The Application Development Process, examines the challenges of finding and remediating bugs in applications that are growing in complexity and number, and recommends tools and best practices for weaving vulnerability management into the development process from the very beginning. (Free registration required.)

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
12/13/2013 | 10:24:31 AM
Agree that IT is generally the "scape goat" department
As a former senior officer of a health care company and an old-time tech User, I could not agree more with the opinion that IT is generally used as the scape goat department by incompetent Users who generally ill define their requirements and/or constantly change their requests. What I always found amazing was how often the IT Department was willing to fall on their own sword to protect what they considered their "customers" (i.e. other departments within the same company). As Mr. Hurley indicated as appropriate, I generally tried holding the User responsible. Oddly enough, I often got more push back from the IT department than the User's themselves since, I believe, in addition to possibly trying to protect their "customers", IT managers often wanted to take ownership (and ultimately credit) for the project itself. The main problem I had with IT was their general unwillingness to assign and identify specific resources behind a project. My position was always that I would prefer to have 5 to 10 people with names and faces than 500 "FTE's" (i.e. Full-Time Equivalents). Without a full court press, I was generally assured that hundreds or even thousands of hours were being spent on my projects but they were provided in a black-box environment with the general reasoning that IT management needed the flexibility to move resources around from project to project based on specific skill sets needed. That approach always drove me crazy and never seemed to produce results. Both sides of the project fence (i.e. IT and User) need names and faces from management to spec writers to program coders. This would seem to be even more essential when an IT project like was being farmed out to 35 different organizations.
User Rank: Author
12/12/2013 | 4:16:45 PM
Governance Startegy
Bill, regarding your questions on governance of the project, that was one complicated governance exercise, considering the 35+ subcontractors working on the project. Most private enterprise CIOs would not easily agree to using such as high number of subcontractors, for the governance reasons alone. Can you imagine Google approaching the project in that way? Yet that is a way of life for government IT. This will be a project management and governance case study for years to come.
11 Ways DevOps Is Evolving
Lisa Morgan, Freelance Writer,  2/18/2021
Graph-Based AI Enters the Enterprise Mainstream
James Kobielus, Tech Analyst, Consultant and Author,  2/16/2021
What Comes Next for AWS with Jassy to Become Amazon CEO
Joao-Pierre S. Ruth, Senior Writer,  2/4/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you.
Flash Poll