#1: You took the buffalo for a walk

1 of 5: Top 5 Mistakes Collecting SPM / EIM Project Requirements

You need to be in control and organized. And if you’ve ever tried to walk a buffalo, you can attest to the fact that you are not in control of that situation. In this metaphor, the buffalo is a requirements meeting without an agenda. They can definitely get away from you and cause a lot of damage along the way.

The Problem

Implementations have a natural order of events.

  • Scoping/Budgeting
  • Resource Selection/Planning
  • Project Start
  • Requirements
  • Design
  • Etc…

You rarely want to rehash decisions made in prior stages. In the requirements stage, a key objective is to maintain the scope that was decided upon. Everybody has been in a requirements session that turned into a brain storming free for all. Brain storming isn’t bad, but it has its place.This place is not during the requirements gathering phase of a project. By this stage, there should be a high level scope and the key deliverables should have been identified. If the client team is still trying to decide what they want, then the project isn’t ready to begin.

The Solution

As an implementer, the best way to prevent the buffalo walk is to be organized. Lay out a meeting schedule detailing exactly who will be met with and what the agenda and outcome for each meeting will be. This schedule should be ready before the project kicks off so that meeting times can be reserved. The more detailed your agenda, the better.

The reason rehash happens is simple. In this stage you’ve started bringing in subject matter experts that were not involved in the original scoping. An effective way to prevent the newcomers from getting sidetracked is to give the impression that most decisions have been made and are set in stone. The more you appear to know about the situation, the more satisfied they will be with the decisions. Ideally, you should be able to identify individuals who you think might be a problem and do a one-on-one to get them up to speed. This puts them on the same plane as everyone else and enables you to waste less time during your actual requirements sessions.

Of course, the ideal solution is to prevent the possibility of the buffalo wanting to take a walk. That needs to happen way upstream in the budgeting and planning stages. That’s where management could get everyone’s input and get consensus on the major scoping decisions. Unfortunately, that’s typically not realistic. There will always be new people involved and there are hardly ever unanimous decisions. If we waited for that projects would never get started.

  • david.carlson

    The most common mistake I see in requirements is letting the customer create a requirement that is really a design. Often, the only way customers can think of requirements is to describe them as the design of how the system works today. Rather than saying “we need to give credit to salespeople who worked on the deal”, they say “we require the system to have a code that equates to these 5 people that report to this manager so they can get credit”.

  • JasonKearns

    That’s a good point David. One of our “top 5” mistakes is similar to that. In fact, we may borrow some of your thoughts for that posting. Its amazing how many “common” mistakes you can come up with when you really start thinking about it.