Blogs

But, you can probably get what you really need.  Provided you are a business user with a good business analyst on your project team.  And you don’t get distracted by sparkly technology thingies.

My favorite illustration of failure in the “get requirements….deliver on those requirements” process is this website: http://www.cakewrecks.com/home/2012/10/12/marital-miss.html. Caution: some of the cakes on other parts of this site are not in good taste (pun totally intended). These are PROFESSIONAL cakes some trusting person ordered that, when delivered, bore no resemblance to what was requested.   I’m sure they started with good intentions, and then, one compromise or mistaken assumption at a time, slid down that slippery slope to total disaster. 

So, how do you avoid disappointed users and project failure on a records or content management solution?  Start with the business requirements.  Not the wants or desires or theories about how it should work…the actual requirements.  What is necessary to support the core/value added aspects of the business process?  Having served in analyst and project manager roles for many years before becoming a records manager, I have a few lessons learned to share.

First, start by understanding constraints.  That will keep you from being perceived as having over-promised.  If you start by talking to the business unit and listen attentively to all their desires, only to have to go back to them and tell them you can only deliver about 25% of what was discussed, that’s no fun for anyone.  Some constraints you should explore:

• Time - does this project have a drop dead date?  Providing polling place registers for the 2000 Presidential election was one of my favorite examples of a drop dead date.  Missing the date and paying a fine wasn’t even an option.
• Budget – is the budget for this effort already determined AND does it need to be spent by a certain time or you lose the money?  Really a combination of a budget and a time constraint.
• Architecture – you might be able to deliver EXACTLY what the users want if you could leverage technologies outside of your enterprise portfolio.  But you need to work within the set of solutions supported by your IT department.  Don’t dwell on what might have been.  Instead, focus on figuring out what you can do with the tools available/allowed.
• Compliance – Figure out how many rules/regulations apply to this process and then understand those rules so that you know whether business requests are real requirements.  A good example here is when a unit “needs” to keep both the paper and the electronic copy because they honestly believe that’s what the law requires.  A paper copy is rarely required.    

When I enter into a requirements setting session with subject matter experts, I find it helpful to list those constraints as we get started.  Keeps expectations in line with reality.

Now to figure out how to differentiate “wants” from “needs.”  Some helpful filters for those “we need it to” statements are:

• Does what they are requesting happen now?  If not, what has changed that makes it necessary in the future state?  If nothing has changed and they are getting by now, it’s not a need….it might be a really great idea that will save the organization a ton of money, but that’s different.
• Are they inserting a requirement based on what they think someone else expects?  Politely note the requirement, then verify with the other party they actually need what was requested. 
• Is the perceived need based on a limitation of the existing process that will go away with the new solution?  Many audit or review requirements fall into this category.  If they feel they route every transaction to a second person for review to ensure the required supporting documents were attached and the math was done correctly, you can explore options to automate the process so that the review is unnecessary.
• Be wary of “needs” that are attempts to automate workplace etiquette.  The system COULD force users to take the next transaction in the queue instead of only taking the easy ones.  But how much extra coding effort will that require and why would you make the system so inflexible?  Instead, just communicate the “take the next transaction” rule and train supervisors on the fine art of holding people accountable.

I sure there are a million more examples of “needs” that are actually “wants” that I’m missing.  Fill in the ones I missed by leaving a comment below!