It’s not a problem at all. I’m glad that I helped.

All the best,

Vjeko

I’m a bit ashamed. Yes there is a drop down list and I did not see it. Thanks for your help.

Hans van der Hoeven
Avans University of Applied Sciences,
The Netherlands
Winner Excellence Award in Academic Alliance EMEA, november 2008

Hope to get your answer.
Thanks.

Hans

Excellent comment! And it explains very well why all requirements should be listed. But I do think that detailed requirements worksheet should exist. It might be costly, but that’s where the project management tools and templates (and Sure Step!) step in: you can have fit/gap worksheet templates for various industries, customer sizes, functional areas etc. that you have created, updated and developed during your previous projects. It is also a good project management practice: frequently updating and utilizing what PMBOK calls “organization process assets”.

Another thing that seldom happens is that fit/gap worksheet is updated throughout the project as a part of change management process. If you get a new requirement, either a fit or a gap, during later phases, it should really be recorded in the fit/gap worksheet (which becomes part of your OPA).

And about my dream car–when I get it, I’ll take you on a test drive!

Best,

Vjeko

About gaps: my firm opinion is that all requirements should get recorded. If the customer will be adjusting the G/L balances, then it has to be recorded as a feature, and analyzed to see whether native functionality is a gap or a fit. It might end up being a gap, although in probably 99%+ cases it will be one big fat fit.
About RFP: yes, you’ll definitely get a different results from a requirements workshop than from an RFP. In my experience, a lot of RFPs are far away from what customers really need – they are often written by a hired third-party consultant, and are very generic (depending on the third-party consultant’s experience in the industry and the RFP template they used). But the RFP form is generally very good at articulating specific requirements, and fit/gap worksheet should really resemble the RFP, but you should by no means merely copy the RFP into the fit/gap worksheet and call it a day, because the RFP rarely lists all the requirements (and rarely are the requirements at the same “level” of depth, to give a reliable degree of fit). RFP (if it exists) should be used as a starting point. It might be “a massive amount of work”, as you point out, but I believe it is not a “very little gain”–on the opposite, it is a huge gain. Requirements are the cornerstone of every project, and the more detailed you get them up front, the less rework and hidden gotchas the project will bring later on, IMHO this is BIG gain. Just to illustrate, I’ve seen a project where the consultant has deemed a requirement a fit, while it was one huge gap, and the problem was terminology: the customer had one idea of a techincal term, while the consultant had the other (and it was a huge functionality area lurking behind what seemed a standard minor feature at first); if proper analysis and documentation of this big requirement had been conducted in the first place, it would have saved hundreds of hours of work and rework.

I really hope my next post will shed some light on what a real use of the degree of fit might be.

Best regards,

Vjeko

BTW Dave, we LOVED the Everyone Lies post (and I’m still waiting for the ‘selective-Tourettes’ -as we call it follow up).

What we’ve struggled with periodically when writing requirements with clients is that often times we expect our sales team has done an adequate job of doing discovery to get us to this point. More times than not, they have gotten about as much as they can (or should really-we need them selling, not analyzing), then it becomes our responsibility to work with the client to throw back the covers a bit.

If you fail to mention any of the standard, out of the box functionality to a client, they will not be very helpful in identifying where their business processes differ. They should not be expected to be ‘product experts’ at the time of discovery/analysis, rather a well-trained consultant should be able to throw out a little, to get the conversations started, then gravitate to those items they clearly know are not possible in the proposed solution.

Having a mixture of both in a requirement document helps the client also explain to their team ‘why’ there needs to be a customization or third party product. If it’s written well, it should be understandable without someone needing to be certified in the application.

Configuration is what we strive for as it is usually a lot less expensive for a client to change some business processes-those that are relatively new (or will resolve a long-standing problem) but it still needs to be documented as a requirement.

If it’s not documented that the accounts payable manager will need to balance the accrued purchases account to an outstanding report every month in order for a modified screen to provide the correct totals, then you can rest assured when it’s time for deployment they will not remember anything about it.

To bad every engagement doesn’t go to the level of an RFP being generated-but you are right Dave in that it would be incredibly costly-and then there wouldn’t be any money left to implement the requirements.

What I’ve heard through the grapevine is the next release of Sure Step is certain to have better requirements gathering questionnaires to hopefully help in this whole area. I’m looking forward to seeing the new release-and you can bet I’ll come back here to find out about it first.

As always Vjeko-thank you for your excellent topic, and when you do get that dream car, I hope you’ll post a pix of it here for the rest of us to drool at!

Chris