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

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

Summary: A CIO explains the importance of defining business requirements as a prerequisite for IT success.

SHARE:
TOPICS: CXO
5

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, Dr. 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 advantage.

Image from iStockphoto.com

Topic: CXO

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

5 comments
Log in or register to join the discussion
  • RE: CIO view: Business requirements and the elegant art of 'no'

    All that I can say is: AMEN!
    rs_jr
  • RE: CIO view: Business requirements and the elegant art of 'no'

    Michael,

    We've been around long enough to know that, for the past 10 years (at least) the causes of most 'failures' have been an absence of what many would describe as 'the basics'. I think this post is completely accurate, and yet when you scour the web as to ERP/IT App. projects, you'll see the same best practices reiterated ad nauseum. With such a wealth of expertise available, why do you think these things still happen with such regularity?

    Yours, attempting to prompt a healthy discourse,
    Steve
    datango
    • RE: CIO view: Business requirements and the elegant art of 'no'

      @datango It's easy to focus on core project management and hard to align people and expectations, so we keep repeating the negative cycle. In my view, aligning expectations and perception among the various stakeholder groups forms is the essential missing ingredient for success.
      mkrigsman
      • RE: CIO view: Business requirements and the elegant art of 'no'

        @mkrigsman@... It's those darn people again! They get in the way of all these straightforward IT projects... Thanks Michael. Hope you're enjoying a good start to 2011.

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

    The quotes taken from John Halamka?s post are very revealing and go way beyond the need to "define business requirements" and the mantra of "ownership."

    First, if an initiative fulfills a line of business need, then that line of business, not IT, owns or is responsible for:

    * Clearly and comprehensively defining the need, the benefits of the initiative, and the value of those benefits

    * Realistically anticipating and assessing the organizational and operational impact of changes resulting from the initiative

    * Performing a dispassionate cost-benefit analysis for the initiative including cost tolerance

    * Identify conditions for which the initiative should be terminated prematurely or the initiative mission changed
    Second, the steering committee approving these initiatives needs to do a better job of educating lines of business regarding appropriate due diligence and ownership. Diligence should be proportional to the importance or urgency of the business need. There is a reason that these initiatives have a 30-70% failure. Lines of business need to understand the ramification to operations and financials of performing end-runs around proper business case
    elizab