Archive | implementation RSS for this section

My Dog Ate the Requirements, Part 2

DogAteRequirements2

There’s nothing more frustrating than not being able to rely upon a business partner.  There’s lots of business books about information technology that espouses the importance of Business/IT alignment and the importance of establishing business users as IT stakeholders. The whole idea of delivering business value with data and analytics is to provide business users with tools and data that can support business decision making.  It’s incredibly hard to deliver business value when half of the partnership isn’t stepping up to their responsibilities.

There’s never a shortage of rationale as to why requirements haven’t been collected or recorded.  In order for a relationship to be successful, both parties have to participate and cooperate.  Gathering and recording requirements isn’t possible if the technologist doesn’t meet with the users to discuss their needs, pains, and priorities.  Conversely, the requirements process won’t succeed if the users won’t participate. My last blog reviewed the excuses that technologists offered for explaining the lack of documented requirements; this week’s blog focuses on remarks I’ve heard from business stakeholders.

  • “I’m too busy.  I don’t have time to talk to developers”
  • “I meet with IT every month, they should know my requirements”
  • “IT isn’t asking me for requirements, they want me to approve SQL”
  • “We sent an email with a list of questions. What else do they need?”
  • “They have copies of reports we create. That should be enough.”
  • “The IT staff has worked here longer than I have.  There’s nothing I can tell them that they don’t already know”
  • “I’ve discussed my reporting needs in 3 separate meetings; I seem to be educating someone else with each successive discussion”
  • “I seem to answer a lot of questions.  I don’t ever see anyone writing anything down”
  • “I’ll meet with them again when they deliver the requirements I identified in our last discussion.
  • “I’m not going to sign off on the requirements because my business priorities might change – and I’ll need to change the requirements.

Requirements gathering is really a beginning stage for negotiating a contract for the creation and delivery of new software.  The contract is closed (or agreed to) when the business stakeholders agree to (or sign-off on) the requirements document.  While many believe that requirements are an IT-only artifact, they’re really a tool to establish responsibilities of both parties in the relationship.

A requirements document defines the data, functions, and capabilities that the technologist needs to build to deliver business value.  The requirements document also establishes the “product” that will be deployed and used by the business stakeholders to support their business decision making activities. The requirements process holds both parties accountable: technologists to build and business stakeholders to use. When two organizations can’t work together to develop requirements, it’s often a reflection of a bigger problem.

It’s not fair for business stakeholders to expect development teams to build commercial grade software if there’s no participation in the requirements process.  By the same token, it’s not right for technologists to build software without business stakeholder participation. If one stakeholder doesn’t want to participate in the requirements process, they shouldn’t be allowed to offer an opinion about the resulting deliverable.  If multiple stakeholders don’t want to participate in a requirements activity, the development process should be cancelled.  Lack of business stakeholder participation means they have other priorities; the technologists should take a hint and work on their other priorities.

Welcome Inside!

Welcome to Baseline’s blog
entries, and to my inaugural blog, Inside
IT
. For those of you who have seen me present and read some of my articles,
you’ll be happy (or sad) to know that this blog will echo the same themes,
tone, and yes, sense of humor, from those other media. (I promise to control my
colorful language and not use too many four-letter words, unless it’s something
like “SDLC” or “BPEL.”)

My Baseline blog will be
consistent with the rest of my speaking and writing topics, which means that it
will align with some of the core assumptions in my other content, including:

  •  We’re doing all
    this IT stuff to help the business. We’ve obsessed over the importance of IT
    having a place at the corporate table, but we sometimes forget we’re here to
    support business actions and decision making. Companies use technology and data
    to help run their businesses, not because they want to win awards for the
    biggest database. We’re so wrapped up in protecting the reputation of IT that
    sometimes we forget about the business. As Jill would say, we do so at our
    peril.
  • Too many IT
    organizations forget that data can contribute to innovation. If you take a look
    at what a retailer does, it doesn’t invent its own POS or inventory management
    systems, it buys them. What’s valuable is the data. Where IT provides value
    isn’t in deploying its backbone systems, but creating the decision making systems
    supported by information. Which as it happens are closer to the business users.
    Notice a theme here?
  • Data integration
    isn’t rocket science. It’s really not that hard. The complexity isn’t in the
    processing. It’s in defining the rules for identification and integration. We
    still find IT shops that want to build their own ETL tools rather than
    designing the right data integration frameworks. Sometimes the rules that
    govern integration aren’t as sexy as building new software. Sometimes we don’t
    need to build a better mousetrap ‘cuz there are no mice. We have other problems
    to solve.

 The whole premise here, and
maybe my new mantra, is: Leverage, re-use, and buy if you have to. Check back
here often and we’ll discuss how to do them.

%d bloggers like this: