The Curse of Jumping to Solutions
A few days ago I received a document in my inbox from a potential customer. The document contained background information about a new internet site that should serve as a tool for distributing information and providing access to a "knowledge bank" for a network of organizations. So far so good.
When I started to read the document I realized that it was more or less a long feature list. It also hit me that there was no "social networking thinking" behind the suggested features. I would have expected this for a site that should support an otherwise loosely coupled network of organizations (well, people). To me, features such as "Expert database", "Newsletters" and "Project database" seem almost like relics of a prehistoric era.
Furthermore and more importantly, none of the features were traceable to any clearly defined objectives or target group needs. The features were motivated with sentences such as "We need this feature so that we can publish XXX" or "We have this database with XXX and want to extend it with this information". The list of features seemed to be a product of a workshop that started right away with brainstorming on features.
Well, how do you continue from there with that as your baseline of requirements? I would say that you should make the customer scrap the document and start all over again by identifying the objectives, the target groups and their needs, and THEN take a look at what features that can help to achieve the objectives and satisfy the needs of the target groups. But, I know how hard it is to make stakeholders who have already fought hard for their ideas and got them approved by others to abandon them. This is the curse of jumping to solutions. It happens ever so often.
When I started to read the document I realized that it was more or less a long feature list. It also hit me that there was no "social networking thinking" behind the suggested features. I would have expected this for a site that should support an otherwise loosely coupled network of organizations (well, people). To me, features such as "Expert database", "Newsletters" and "Project database" seem almost like relics of a prehistoric era.
Furthermore and more importantly, none of the features were traceable to any clearly defined objectives or target group needs. The features were motivated with sentences such as "We need this feature so that we can publish XXX" or "We have this database with XXX and want to extend it with this information". The list of features seemed to be a product of a workshop that started right away with brainstorming on features.
Well, how do you continue from there with that as your baseline of requirements? I would say that you should make the customer scrap the document and start all over again by identifying the objectives, the target groups and their needs, and THEN take a look at what features that can help to achieve the objectives and satisfy the needs of the target groups. But, I know how hard it is to make stakeholders who have already fought hard for their ideas and got them approved by others to abandon them. This is the curse of jumping to solutions. It happens ever so often.