Want vs.Need
I was in a shop the other day and overheard a conversation between a young boy and his mother. The boy, about five years old, was after the latest 'Dr Who' comic (a spin-off publication from a popular and long-running BBC sci-fi series). What caught my attention was the boy saying, '... but mummy, I really, really need this!' To which his mother replied: 'No, you really, really wantit – there's a difference'.
Now, I am not sure if this distinction was not completely lost on the boy - at five years old I am fairly certain that I thought want and need were the same thing – but it did set me thinking about how much I still confuse the two in my adult life.
For example, I am about to replace my car. What I need is something that will get me from home to office and back, with the occasional long distance journey (which means over 50 miles in the UK) in reasonable comfort and at relatively low-cost. What I want, in addition to the obvious, is sat-nav, iPod connection, air-con, leather seats, decent acceleration and preferably something that will express the success and charisma of a movie-star (in my dreams!).
My needs would easily be met by any decent hatchback: a Ford Fiesta or VW Golf, for example. Does that stop me going for something considerably more expensive? In a word, no.
Nowhere is this lack of distinction between want and need more apparent than in the realm of software requirement specification. Look at the software you use from day to day, particularly the bespoke stuff, and ask yourself, 'How much of the functionality do I need to do my job? How much of the functionality makes me more efficient, prevents unnecessary work, or eases communication with colleagues?'
Then, turn the question around. How much is just there because it could be done? Because someone thought it might be useful? Because it was just 'cool' to program? Worst of all, and perniciously subtle, how much of the functionality actually increases the workload without generating any real business benefit? For example, the ability to generate a complex report with lots of detailed data and graphs, when the recipients are only ever going to read the executive summary.
When specifying requirements for software, rule number one is unless this feature or feature set actively supports a significant business need it should be dropped or at least heavily de-prioritised. Particularly in these lean economic times, keep in mind that implementation of any functionality costs time and money, and 'cool' features often do nothing for, and sometimes actively detract from, user productivity.
Category
| Permalink |
|
|
|
|
|
Comments
What YOU may not see as important may be quite important indeed to those paying for the development. I prefer to bring issues like this to my clients' attention and let them decide what's necessary vs. just desirable.
Posted by Nobody At 12:26:17 PM On 07/06/2010 | - Website - |
Posted by Matthew At 08:29:02 AM On 07/07/2010 | - Website - |