4 Tips to Not Destroy Your Project if you Must Use Spreadsheets for Software Requirements
A year ago, I was working on a project where we created a list of features in Excel to help development understand at a high-level what would be in the new system we were building so that they could provide quick and dirty estimates. Out of these estimates, a solution design for the project was chosen and the team headed down the path of a full blown software development lifecycle on these features. Before too long, we recognized the nightmare that Excel was going to cause us, so we uploaded the features from Excel into Borland’s Caliber requirements management tool. The great thing was we could continue to export to Excel pretty quickly for delivery to our customer, since they didn’t have the tool and they were used to that format.
Now also of note, the team decided to use something a bit like SCRUM for this project, so we just treated the features list as a “backlog” of sorts. As sets of features were prioritized for an upcoming sprint, the business analysis team did its elicitation and documented requirements in the form of models from RML™. Throughout this process, we wrote user stories instead of formal use cases, used other visual models as appropriate, and instead of traditional “shall statements”, we wrote “confirmation statements” to describe the functional requirements and business rules. They were used to describe in detail what the system actually needed to do. Oh and by the way, these were all put in Caliber and exported into Word docs as needed for review and development.
Let’s jump ahead 6 months. Our team actually wasn’t on this project for about 3 months, and when we came back to it, we found what I would label “a requirements mess”. I have analyzed this a million times to understand what happened when we transitioned off for that time period that it went so wrong to land the team in this situation. And while I have ideas, the point of this post really is that it just was a mess.
Unfortunately the team stopped using Caliber completely, so all requirements changes and new additions were done in Excel and Word. As is expected, they had lost chunks of work in overwriting newer versions with older versions by accident. There used to be traceability between features and detailed system requirements, but that was completely lost.
What was most alarming and damaging was that the development team believed that the Excel list (which represents just a list of features with one-line sentence descriptions) was the full set of requirements. They weren’t even looking at the user stories, models, and confirmation statements to develop the system! As one might expect, the system developed didn’t really meet the requirements.
And so we headed down a path of narrowing the gap between what was developed and what was required, as well as completing analysis on areas not yet developed.
Over the next few months it became completely apparent how much people love to use Excel. I mean LOVE. Sure enough, one year later, the Excel file still lives as the source of what the scope is on this project. And while they are now using the detailed requirements documents to develop, the Excel list is still the master of all information. And did I mention, there are now about 60 columns to it? And 3 versions of the document that have different information in different columns? I had the exciting task of trying to merge the 3 back into 1, but while I was doing that, someone was editing one of those versions so now we still have 2 versions. Alas we are trying to get approval to get a few licenses of Caliber in place so we can move this spreadsheet back into a management tool.
But the moral of the story is….well Excel sucks for managing requirements, but if you must absolutely use it:
1. Do more than just use Excel – put your requirements details in other formats as well.
2. Be cautious about what information belongs it and what does not.
3. Be careful what you communicate that it actually represents to the project team.
4. And please use a tool behind that Excel to house your data.
Labels: Borland Caliber RM, requirements tools, software requirements
posted by Joy at 2/10/2010 10:05:00 AM
5 Comments:
The message I take away from this story is the importance of good requirements management practices - traceability, etc. It seems that the key issue of the team that replaced you for 3 months wasn't so much their reliance on excel as their lack of requirements management.
This is interesting. Virtually all our large healthcare software vendors still utilize Excel exclusively for eliciting, communicating and tracking system implementation requirements. And I've often wondered why they don’t use something more customized or sophisticated, even on larger projects.
It is well known that Excel is "le bien-aimé", for its inherent cognitive simplicity and understandability. At the most basic level it appeals to a collective psyche of "list-makers", to that most basic instinct of what a lot of people tend to do when trying to determine and remember what they need/want. It is very available and easily scalable, in a sense. That apparent easy scalability is of course a problem and trap as well. Too easy to just add a sheet or add rows/cols. without a proper level of semantic linking, as it seems Joy experienced – my sympathies!
Like any requirements tool Excel can be misused and misunderstood, as clearly pointed out here. But is it simply because the higher level, dedicated electronic tools for reqs. processes are not as available, accessible, understandable, economical or easily scalable?
Perhaps the more sophisticated tools may not support simple, flexible-format and agile communication, sharing and discourse quite so well? And sounds like a critical req. for reqs. processes tools is – ironically- the ready ability to export back to Excel (or Word)?
Or maybe it is a case of control, the “I want complete ownership and control over my data” syndrome, for reqs. in this case. We see a lot of that in healthcare. I think that is why we still see Excel ALL over, including Reqs. procs and beyond, and will for some time ☺ So the tips here are well heeded.
I agree that lack of requirements management was a problem, but so was lack of a good tool. For three months the client did not have a better tool. Don't blame them for using what they had.
Excel -- and I assume Caliber, I don't know -- makes it easy to treat requirements as discrete entities, to track them as in and out of scope for a particular release, etc. Word makes it easy to show requirements in context with each other and with explanatory material such as use cases, diagrams, etc. Those two uses are somewhat in contradiction. How does Caliber stack up in that regard?
I'd actually argue that many times lists that start out in Excel frequently need to be moved to more collaborative mechanisms. The standalone spreadsheet really isn't meant for collaboration but Excel is in many ways a victim of its success. People love it so much (as do I) that they are often loathe to embrace something different, something foreign.
Post a Comment
<< Home