IT projects that fail to deliver significant net positive contribution back to the organization remain a serious issue. Since the problem shows no signs of abatement, we must continue to examine the conditions that drive IT failure.
Properly defining business requirements is among the most important contributors to successful IT programs and projects. High rates of enterprise IT failure therefore suggest that many organizations do a lousy job managing the business goals that should underlie any project.
The CIO of Boston’s CareGroup Healthcare System and Harvard Medical School, John Halamka, recently wrote about the challenges associated with defining business requirements:
Here’s what I’ve learned.
- Automating a dysfunctional manual process will not yield a successful performance improvement outcome. Before any technology project is launched, the business owners need to understand their own process flows and goals for improving them.
- If business owners cannot define their future state workflows, software is not going to do it for them.
- The IT department can impose governance and project management processes to ensure that future state workflows and requirements are defined prior to any procurement processes. However, the business owners who are least experienced with project management methodology will accuse the IT department of slowing down the purchase. Projects without clear requirements and goals can be stopped before they expend time and money on an implementation that is likely to fail.
- Some departments will try to circumvent governance prioritization and project management processes by contributing departmental funds, obtaining a grant, or getting a donor to fund their software purchases. Such as approach should not be allowed for many reasons. Software licensing is generally about 20% of total implementation cost which includes hardware, configuration, interfacing, testing, training, and support costs. Every software implementation is a project and needs to be considered a use of scarce IT resources.
- Creating formal documentation of business requirements, goals/success metrics, and forecasted financial impact is important to establish ownership of the project by the sponsoring department. Although infrastructure projects such as provisioning networks, desktops, storage, and servers can be owned by the IT department, application projects should never be owned or sponsored by the IT department. If the project is considered an IT effort, then business owners will claim their lack of requirements definition or process redesign is an IT failure based on poorly designed or implemented software.
Thus, however unpopular it makes the CIO, insist on business owner sponsorship with defined requirements, goals, and accountability for process and people change management. Every project I’ve been involved in that includes this role for the business owner has been successful.
Many organizations expect IT to deliver successful results despite ambiguous and contradictory business goals and requirements. Although rational minds know this inevitably leads failure, we still repeat the same negative patterns. To break this dysfunctional cycle of angst and pain, IT and the lines of business must jointly establish shared expectations on their respective roles and responsibilities.
The governance system described by CIO Halamka depends on respecting the boundaries of project ownership. Beyond identifying process and procedures, however, both sides must learn the rigorous and disciplined art of saying “no.”
Constructively “saying no” is a cooperative and beneficial activity if born of confidence, experience, and shared values. However, be wary of obstructionists who masquerade as cooperative helpers when their primary goal is achieving personal political gain or creating factional divisions.

Excellent post about a very common and value-destroying problem – thank you! You hit an important proverbial nail on its head with your closing paragraph, “Constructively ‘saying no’ is a cooperative and beneficial activity if born of confidence, experience, and shared values. However, be wary of obstructionists who masquerade as cooperative helpers when their primary goal is achieving personal political gain or creating factional divisions.”
This speaks to business and IT maturity – an important lens through which I have studied IT value realization for 20+ years. At low maturity, IT leaders have neither the mechanisms nor credibility to say “No!” So a vicious cycle is generated – business execs ask for stuff and IT execs are happy (even if reluctantly so) to ‘take the orders.” Over time, the business execs complain that the cost of IT is too high, the value delivered, too low, and it’s IT leadership’s fault! If IT leadership pushes back, then not only is IT of questionable value, but also, as you point out, is unresponsive!
This is a difficult cycle to break out of – often requiring a change of IT leadership. Where there is such a change in leadership, the turn around may have more to do with the ‘honeymoon period’ allowed the new leadership, rather than any particular new competencies brought to the table. The new leader has a little time to educate business leaders, forge a strong partnership with the CFO, and introduce business-IT governance practices that shine a light on dysfunctional behavior in the demand-supply dynamic.
It’s a tough problem to solve, but it is solvable – takes some willpower and astute political maneuverings.
Vaughn, thank you for the thoughtful comment. Would love it if you were to leave a copy of this comment over on ZDNet, because there is a discussion there:
http://www.zdnet.com/blog/projectfailures/cio-view-business-requirements-and-the-elegant-art-of-no/11949
Thank you,
Michael
[…] CIO view: Business requirements and the elegant art of ‘no’ (enterpriseirregulars.com) […]