Softwares are different, they evolve, and before you know it they are gone. Perhaps, because they are no longer required by the time you're done doing it or, the saddest of them all, it does not do what it intends to do. There are lot's of other factors that causes a project to fail, but one of the fatal bullets is the lack of clarity. I suggest you use the C.L.E.A.R. technique I created to dodge this problem. Here they are, your team must be or must...
Challenging.
No doubt, your customer knows their problems more than anyone. But why challenge? You need to understand more clearly how they hit their brick-wall, they might be doing things that should have not been done or should have done. If time and situation permits, show them, cautiously, that they could solve their problem on their own by simply improving their process or removing if necessary. I'm sure they will feel uneasy having to point the things they did wrong, but I'm even surer, you have understood their requirement more clearly. The idea is to recreate the problem in your mind by their way of telling. After all, you cannot solve anyone's problem by not knowing the real problem. The result is clear requirement.
Limiting.
Delivering more than what the customer's expectations is great. But in software, it just have to do what it intends to do. So don't be too noble in adding features that should not be there, a practical and logical solution to a problem will do. For a relatively small software company, this ‘noble' feature would cost a major resource: testing, documentation, and support. The result is clear features.
Exacting.
The customer might use specific definitions and words to describe their requirement. These words might sound common to you, but it meant differently for others or even you. It's important that you repeat it audibly on how you understood them and get feedback if it's precisely what it meant. The result is clear communication.
Agree.
All parties involved in the project must agree on your solution. It must be, at the very least, the near to final blueprint of solving the customer's problem. Most of the time, requirements and solutions does not come on the first day you met with the customer. But agree on the action items and the priority of tasks to be done before leaving the meeting room. Questions like: What to be done? Who will do it? When will it be done? must be in your list. The minutes of the meeting is the most important result after a meeting, it must answer the latter questions explicitly. The result is clear expectation.
Revising.
There are, most likely, points that you missed out on your first and second meeting. Your customer won't notice them until they get back and review their notes. That's why it's very important that you revise in a most precise fashion as possible. You have to make sure, that you're adding or removing points that needs to be addressed in the requirement but avoid ‘noble' features as discussed earlier, it's easy to get caught in a stream of ideas while you're working at your desk - but remember that you are there to solve the customer's problem and NOT to fly your bright ideas. The result is clear solution.
Just two words of advise. Be clear.
Finally, this article focuses on gathering and finalizing the requirement with customers, but that's just half the battle. Your creative team must have the commitment to deliver the project precisely and on time. When I was just starting out as an IT person, someone had advised me, "What good a precisely done project is if it's not also timely". So...
Do it now.
No. of Times this article has been viewed :
294
Date Published :
Feb 27 2007