CIO view: Business requirements and the elegant art of 'no'

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.

1. 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.
2. If business owners cannot define their future state workflows, software is not going to do it for them.
3. 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.
4. 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.
5. 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.