What Is Success?
Why IT and business leaders need to agree on a destination.
by Minda Zetlin, August 2011
Is your IT department a success? How good are you at successfully completing projects? How do you know if your project or team is a success? And if someone were to ask your contacts on the business side if they think your projects and department are successful, would they have the same answer that you do?
For the majority of companies, the answer to that last question is no. It’s depressingly common for technology people to complete what they think of as a successful project but fail to meet the business needs that inspired it.
“The folks in information systems sometimes have a narrower definition of success than their customers or partners in the business do,” says Rob Meilen, CIO at Hunter Douglas North America, a leading manufacturer of window treatments. “They may view their role as purely delivering the systemic aspects of a product, new application system, or upgrade. They may not include changes to the business process or whether adoption of the new technology brings measurable business results.”
Therein lies the problem. A business leader will judge the success of a technical project by asking, “Did this solve a business problem and improve our bottom line?” At the same time, a technology leader might ask, “Did we deliver technology that performs correctly according to the specifications we were given?”
It’s easy to see how the answer to the second question might be yes, while the answer to the first could be a resounding no. “I had one project where I was the quality assurance lead,” recalls Paul Glen, CEO at the Leading Geeks Company, an IT consultancy, and author of Leading Geeks: How to Lead and Manage the People Who Deliver Technology (Jossey-Bass, 2002). “The product did what the functional specs said it should, but I went to the head of development and said, ‘We have a problem. When a user clicks on the icon, it takes 20 minutes for the application to load.’”
The developer thought the software was just fine as it was, because it completely met all the specifications he’d been given. “Load time wasn’t in the specs,” he pointed out, adding that users could “do something else” while waiting for the program to load. He kept on insisting that there wasn’t a problem, right up until the day he was fired.
Are You Strategy or Operations?
Few tech people would be as willfully blind to business issues as this developer was, but his attitude reveals a real concern that IT and business managers must both reflect on. Many IT staff believe that their departments serve two functions only: (1) to keep needed systems running, and (2) to act as order-takers, delivering technology that precisely matches whatever requirements they’ve been given.
That outlook is a natural result of the history of IT in most organizations. “For the longest time, IT has been seen as a necessary evil,” says Subra Sripada, senior vice president and CIO at Beaumont Health System, a hospital chain in Michigan. “As businesses become more and more dependent on IT and technology spend continues to spike, IT has quickly become a subject of boardroom discussions. Leading organizations are leveraging IT as a strategic asset.”
The problem is that most IT organizations aren’t prepared to leverage IT as a strategic asset, and most traditional CIOs aren’t ready to lead them there, he says. “Traditional focus is on operations and keeping the lights on. Developing the awareness or the power of technology will help organizations harness the capabilities to reduce costs, increase efficiency, and create market differentiation for the organization.”
Operational CIOs must change their views to embrace a more strategic role, says Gerard Verweij, partner at accounting and consultancy firm PwC. “Whenever I talk to a CIO who can quote numbers from weekly operational reports, I know I’m dealing with someone still focused on operations. When a CIO talks about business performance and what the business needs, that’s someone focused on business strategy.”
Becoming more focused on strategy and less on operations will help CIOs bring their whole department’s view of success more in line with that of business constituents. But how do you actually change that focus?
A good first step involves taking a hard look at any new projects initiated by the IT department. Meilen recommends avoiding projects with a purely technical motivation as much as possible.
“If someone says, ‘It would be really good to upgrade the middleware on our Website,’ my response is, ‘That sounds nifty, and what benefit is there for the business? Will we sell more product? Will our Website be more available? Will it support a new product launch? Let’s demonstrate exactly what the benefits will be.’ We’ll have a better chance of selling the project internally, and we’ll be serving a more core set of needs.”
In fact, Meilen tries to avoid approving a project unless it has a sponsor from the business side. “That’s a great way to force a different kind of examination of the request,” he says. “It has the side benefit of encouraging people in all parts of our department to develop strong relationships with all parts of the business. Even for someone in infrastructure, if they have a good relationship with someone in the business, that benefits both the individual and the department.”
Needless to say, he sometimes encounters resistance on this score from IT folks who insist their business contacts don’t understand the company’s technology needs. “My answer is always, ‘Let’s go talk to them and help them understand.’ The information systems organization gets in a risky position when people in the business don’t understand what we’re doing and why,” says Meilen. “It can feel easier in the short term to say, ‘Let me just do this; don’t make me sell it to someone on the business side,’” he continues. “But there are a lot of long-term benefits in having the mindset that every project serves multiple purposes—some technological, some business-based.”
What Will Success Look Like?
The chances both business and IT will view a project as successful increase if both groups agree on exactly what success will look like before the project begins. While this may seem obvious, it can be exceedingly difficult to accomplish. “There are two assumptions you tend to make when dealing with customers,” Glen says. “The first is that they know what they want, and the second is that they are always right. These can both be false assumptions when you’re dealing with the business customers of IT.”
Business contacts may have no way of knowing what they want because they don’t know what is and isn’t possible, he adds. “You need to have a collaborative process with the business. You can’t just pick them up and shake them by the ankles until requirements fall out.”
Instead, Glen says, there should be a negotiation at the beginning, to settle the question of how a project’s success will be defined. “To the best of our ability, we should talk about it,” he says. “What are the effects we want the project to have on the business? What are the ‘soft’ measurements of success? Some aspects of success will be measurable and others not, but we should be able to talk in advance about what criteria we are using.
“Once you’re into the project, it’s kind of late to do that. And the later you do it, the more expensive it will be to find out you have different sets of success criteria.”
Is the Client Happy?
Dan Gingras, partner at the professional services firm Tatum, believes there’s only one measure of success, and that’s the definition at the business level. Thus, he says, the questions you ask at the end of any project should focus squarely on customer satisfaction. “Is the client happy with what we delivered? Is it on time and on budget? Did we work with the client to help them articulate their needs and also manage their expectations?”
If the IT department views a project from the perspective of customer service, the scope of a successful project immediately expands to include such factors as documentation, training, and user adoption. “Because they don’t see the internal structure of the technology and aren’t qualified to appreciate its elegance, business users will judge the success of a project much more on their experience of getting it and using it,” Glen says. “‘Does it look like I expected it to look? Did you explain it to me in language I understand? Did I feel you condescended to me during the process?’”
Getting the business engaged in IT governance and priority setting has been critical as Beaumont Health System introduces new electronic interfaces in the traditionally paper-based healthcare industry. For the hospital chain’s IT staff, closer collaboration has paid off in smooth IT implementations. Sripada’s recent projects have a broad impact on the way doctors track and deliver care. If IT staff had not engaged users and their requirements, there could have been wholesale rebellion against the change.
But major implementations at three hospitals went very smoothly and were completed on schedule without major complaints from users—something Sripada attributes to his department’s collaborative approach.
“We’ve worked very hard to be transparent, and to invite dialogue around IT,” Sripada says. “And I find the more we do that, the less I need to convince upper management of what we need. These days, more often than not, it’s other leaders within the organization asking the CEO to devote more resources to IT—so that we can do more for them.”
For More Information Should Business Satisfaction Factor into IT Pay? Effective Collaboration The Right Fight
Minda Zetlin is coauthor with Bill Pfleging of The Geek Gap: Why Business and Technology Professionals Don’t Understand Each Other and Why They Need Each Other to Survive (Prometheus Books, 2006).