--- Jared [email protected] wrote:
Beware the client who always changes the
requirements... :)
Think there is a method of discovering such
clients
ahead of time? My experience so far has been that people with
vague
ideas of what they want are the worse. They don't know what they
want,
so you try to build what they describe
This is the totally wrong approach. It is the deisgner's job to extract from a client a clear picture of what it is they want. This means
getting
input from the people who will use the product. It maens asking questions, restating the answers, and developing a data map and interface requirements.
Exactly. Become the expert, and then implement what the customer wants (but cannot define clearly). Thereafter, scope creep is not the customer's fault, it is part of what you manage as the expert.
I know this all in principle; practice is a lot harder, because, essentially, it requires a geek to have the social skills to tell a customer what they want--with enough precision to keep them happy... which I am only just learning how to do.
Yes, this requires some people skills, but there are tools and methods to extract the information from clients. Tools and methods that every geek should learn and use. There is even software that can be bought that virtually develops the skeleton of the program. However, I don't recommend buying these very expensive tools. What it comes down to is focusing the clients on the data. Here's a quick primer for those interested (if I'm way OT and anyone wants me to shut up just say so.). First, get the clients together (obviously) and ask them questions about the objects they use in thier business. Let's say they rent equipment and they have asked you to rewrite their tracking and billing systems. So, the first question might be "What defines a piece of equipment?" or "What do we need to know about a piece of equipment to track it (bill it)?". This will porobalby elicit all the things they currently capture to track or bill. To which you need to respond, "Ok, this is good, but what do you need to know about equipment that your current system doesn't capture?". Now while all this question/answer is going on, you as the expert are of course using a Big Post-it board of paper to write down on the top the name of the object and underneath all the properties of the object. You repeat this for every object that need to be captured. You should have a basic understanding of the clients business so that you can inject a few objects to get them thinking. After you get all the properties of an object you can then ask them what arfe the key fields of the object, and also any fields which they "need" to do frequent look up on. Remembering that you have to constantly remind the client that we are looking for what they need or want and not what it is they currently do. It's those things they want to do that they currently can't that lead to ever expanding requirements (scope creep). When you have explored all the objects you will wind up with your database structure, and the client has done most of the work for you. If you have the man power you could have a second person at the meeting "taking notes" on a laptop. The notes of course being table definitions or UML. With this data one could then design screens for data entry and querying. However, we still need to ask more questions. Such as "what kinds of questions do they need to ask of the data", "what do they need to do to fix mistakes in the system","what kinds of reports do they need","what information needs to be on bills","what information do they need to see when asking certain questions","what kind of what if questions do they want to be able to do",etc. With these questions answered you should be able to build interfaces and report queries. Now of course, some of these wants will be easier to do than others, based on what inforamtion is stored in the objects. This is where you need to put prices on all the questions they need to be able to answer about the data. the important thing to remember is to try to use the client's knowledge to extract the questions and data. You will most likely not know enough about their business to ask all the right questions. Getting them to ask the questions is the key. Now this won't elminate scope creep, but if you get them thinking about this, you'll find that you'll get most of what you need and over the next week they will undoubtedly think of more things as they do their day to day jobs. This way you should be able to contain 99.9% of scope creep to within the first week or two of the project, plus the clients have automatic "buy-in" on the project because they helped design it. Well this is probably long enough, sorry if this is all old-hat for everyone. Hope this help a few.
Brian D.
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
-
Jack