Don’t forget the ‘How’

We all know that software projects have a bad name in the industry. Very often these projects are late and don’t really deliver to the clients expectations. There have been lots of ways that companies have tried to address this such as running projects using agile methodologies, etc. This post is slightly different. It’s about addressing these problems by trying to understand the client a bit better.

Business Analysts will visit the client and document, in detail, what work the client needs done. The business objects, business rules, etc. are all carefully collated and pushed down the chain until they arrive at the developers. However, there is often a problem lurking in the background. How the client will be using the system is often missed or forgotten. Developers are experts at thinking in technical terms. They will take the business objects and quickly draw up a few database tables. From those, they already start picturing the visual parts of the system in their minds. At this point, things could already be going very wrong. That crucial piece of information on how the users work or would like to work could be missing.

Lets say that we were building a system to manage a fleet of vehicles, there is a big difference between capturing a single vehicle and having to capture 50 or 100 of them. That’s where the understanding of how the users will be using the system starts to become very important. Capturing a large number of vehicles brings other complications that effect everything from the back-end database right the way through to the user interface. We may need to have a holding table to store the vehicles while they are being captured. If we don’t start building it properly from the word go then we could end up with a lot of rework and wastage.

What I found really helps is for developers to try and put themselves in the users place for a while and try and understand not just what the users do, but how they do it as well.