Archive for February, 2011

Avoiding a Requirements Disaster with a Software Package

When you are thinking of buying a shiny new car, you probably have a few basic requirements in mind.  4 wheels are good to have.  2 door or 4 door.  Satellite Radio or built in GPS.  And in my family’s case, how many ways to keep the kids entertained while we are driving long distances?

These requirements are fundamental.  Not many people also come to the dealership with a list that says the car must have 3 AC outlets, 15 cup holders, and seat-back pockets to hold tissues & maps.  And if they did, can’t you just imagine the grin on the dealer’s face as he thinks about how much extra he is going to charge you for the extra cup holder adaptor and upgraded seats.  And hopefully you’ll overlook the fact that there is NO WAY to add an additional AC adaptor to the car that already has 2.

The concept of having a high level set of requirements and the less-valuable detailed list of requirements is what I have found applicable to purchasing a software package from a vendor.  My experience has shown that there are ways to avoid analysis-paralysis, sticker shock, or project risk in these situations.

First, it all starts with setting a priority.  Even before you talk to a vendor.  Your project sponsor must decide what comes first – Scope, Schedule or Cost.  Based on this upfront discussion, you can make decisions throughout the life of the project easier.  Based on the priority, have a discussion with your project sponsor about the ramifications of customizing any software package purchased.  Customizing a software package is fine if your priority is Scope but if your sponsor is more aligned with Cost or Schedule, then you should try to avoid customization like the plague.  Customizing software – no matter how experienced the vendor – adds Risk & Cost (short-term at implementation and long-term in ongoing maintenance).  Having your sponsor on the same page with you from the start – before they start to hear about all the great things the vendors can do for them – makes conversations about eliminating customizations easier.

Second, evaluate whether your software is supporting an existing business process or a new process – perhaps a new product or service you are planning to offer.  If the process is existing, make sure it is documented.  If the process is new to your organization, skip to Step #3.  For existing processes, work with the impacted stakeholders to identify processes that MUST be supported by the new software.  And don’t let them waffle on you – there is a difference between MUST and Nice to Have.

Third, issue your RFP.  I find it helpful to give my vendors insight into my priorities (Scope, Schedule, Cost) and to base my RFP on the Must Have requirements plus many other requirements about the ongoing relationship, architecture, and other things.

Once you have selected a supplier, do not start building a list of requirements.  Start with reviewing their available documentation.  Any vendor worth anything can provide you with system documentation that outlines how their system supports various business functions.  A user’s guide at a minimum would suffice.  Walk through this documentation twice.  Once to gain an understanding, and the second time to see how it applies to your organization.  This is where the process documentation comes in handy – if you have it.  You can align the system documentation to the process documentation and document the gaps.  These gaps are then reviewed for Must Have versus Nice to Have.  Again – keeping in mind the Scope, Schedule, Cost priority discussion in Step #1.  If you are building a new business process, you can start to build your process documentation based off of your stakeholders input and the functionality supported by the software.

By basing your requirements off of the gaps and not trying to build a full set of requirements from scratch, you can avoid spending hours eliciting requirements that are not satisfied by the selected package.  Additionally, you can avoid higher costs when the stakeholders insist that they need the additional functionality (customization) within the software package.


February 19, 2011 at 7:36 pm 2 comments

Reducing Risk and Maximizing Investment through IT Asset Management

I always thought that my first book would be about requirements.  I have been working on one for 3 years now – so you would think that would have been the natural progression.  But years ago, I had the opportunity to step into managing a team of outstanding resources who managed vendor platforms and the relationships with the vendors.  I had been the Business Analyst involved in launching many of the vendor platforms, so it was a great fit for me!

What I found as part of this experience was that managing vendor platforms/relationships could be broken down into repeatable steps that maximized efficiency.  Depending on the impact of the platform on our business,  we could approach our management method with more or less effort.  I also found that even though we were paying our vendors – they were great partners when they shared in our successes and failures.

If you’ve read my blog often, you know that my passion lies in Requirements Management.  The reality is that my passion lies around strong communication and clear expectations.  This is best represented in the SDLC in the requirements processes.  The same areas of focus – strong, consistent communication and clear expectations – also benefits teams involved in vendor management – and really any other teams but who is going to read a 1,000 page book?

A while ago, a colleague of mine contacted me about putting together a book based on our experiences.  He had extensive experience in building productive vendor relationships while working for Fortune 500 companies.  Two other colleagues we knew had great practical knowledge of how to best develop software and hardware purchases and leases.  Our hope was that readers would find our experiences helpful as they developed their own approach in developing vendor relationships for professional services, hardware, or software.

If you have any interest in this topic, I would encourage you to check out our book.  It is available through Amazon or Barnes & Noble.  The eBook format should be available by the end of the week.  I would love to hear your feedback!  Feel free to drop me a note at  You can also reach out to myself and my co-authors at

February 16, 2011 at 7:38 pm 4 comments

Words to Banish from your Vocabulary

There are days that I cringe in meetings.  I find that using my “poker-face” requires a lot of my energy so I use it sparingly.  When we are talking about the scope of a project, and I hear “well, sometimes it needs to do x and y”.

Wow – where to start!

Let’s break this down word by word.

1.  Sometimes – This is an indecisive way of saying that the functionality needs to vary in some aspect.  As a Business Analyst, you need to dig into the intent behind this word ASAP.

  • Is there a particular business rule that would drive a change in behavior of the solution?
  • Should the functionality only be available at a certain time of the day?  Day of the week?  Particular days of the year?

Similar words/phrases: Occasionally, In some cases, Periodically

2.  It – this is the name of the pet on the Adam’s Family, NOT a word to be used in requirements.  This word brings no value and all kinds of risk to your documentation.  As the Business Analyst, ask some exploratory questions to resolve “it” into something substantial.

3.  And – Warning bells should be sounding at this point! The words “and” and “or” are signs that you could be talking about 2 different requirements.  A way to validate this is whether or not the two pieces “x and y” are separate test cases.

Hopefully that example gives you a few ideas.  Here are a few of the other “ugly” words in requirements.  Help build this list so together we can banish these words from requirements conversations around the world.  Post your suggestions as comments and when our list grows, I’ll publish an updated, printer-friendly list.

  1. They
  2. Except
  3. Including but not limited to
  4. Etc

February 8, 2011 at 6:39 pm 2 comments

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 39 other followers

Top Posts & Pages

%d bloggers like this: