I’ve been in the position before of the client, where I was paying a programmer or some such person to develop something for me, and I relied on that technologist to do all the work, producing something that I had dreamed up in my head.
A very important fact that all clients forget, including myself, is that to dream up something in our heads takes about 1 millionth the time it takes to execute on that vision and produce something meaningful.
Thus, there is always that constant tension between technologists and clients where the client is constantly pushing for “deliverables” and “results” as the technology guy or gal busts his or her butt to get done what the client wants. The problem is that because the client does not understand exactly what goes in to producing the results (if they did, they wouldn’t need a consultant, they would just do it themselves) then they grossly underestimate the amount of work needed to “get it done.” And often the technologist (me included) underestimates time and effort as well because the technologist wants to get it done quickly, get the project, and is not always aware of all the requirements. Oops? Did I use that word? “Requirements”?
In our fast-paced “get it now and for free” world, requirements are often left by the way-side and an ad-hoc client/technologist relationship is formed where the client says “can you?” and the technologist says “I think we can” and the client says “when can I see something?” and the technologist says “tomorrow” and the client says “OK” and away we go.
So often times some sort of result or deliverable can be produced rather quickly, even if it does not have all the functionality (or any of it) required.
Then what invariably happens is that the requirements which are NOT written down in the first place ( because there is a mutual understanding and trust between client and technologist ) change… yes they do, they change all the time. They are changing as I write this.
And so a cycle begins… of the technologist making adjustments to process and technology that underlies the deliverables, and client assesses and makes comments and asks questions and wants things to be different… which is fine.
We just need to understand on both sides what it means.
What this means is the following:
1. Rapid application development (RAD – which is the ad-hoc process described above… a loose version of it) is great, keeps all parties involved in the conversation, and results in better products most of the time.
2. RAD does NOT decrease total time to market, completion, or total cost.
3. It takes work and frequent updates to maintain the relationship and TRUST between technologist and client.
4. It is an ongoing relationship which can be indefinite so boundaries need to be set.
So if you’re in one of those ad-hoc relationships with a client and you’re performing magic or miracles every day for them and they are still asking for “deliverables” because they don’t understand everything you’re doing you can do the following.
A. make them read this post
B. document decisions, progress, requirements as you go so that you can refer the client back to the progress you have made and the path that has led you to where you are now
C. define a stop to the changes and perform triage on the requirements (that you are now documenting) so that there is a point at which you can put a check list down with all items checked off and say “I’ve completed what you asked”.