All software solutions providers want to provide their clients with the perfect solution (at least I hope they do). And all clients want to give their solutions providers as much help in achieving this as possible (again, or so I hope). Yet it seems that often neither of these aims is achieved.
So what can we do to maximise client happiness and the provision of perfect solutions in the shortest possible timescales? Well one answer is to employ prototyping.
Prototyping at its simplest is where the solutions provider gives the client a glimpse of what they’re working on. The client then has the opportunity to give feedback to the provider letting them know how close they are to what the client wants.
In an ideal world, of course, prototyping wouldn’t be necessary. The solutions provider and the client would have been able to express to one another all that needed to be expressed about the project and this would be written down in an immutable specification. This specification would unambiguously state exactly what was required for the client to have what they wanted and so would give enough information for the provider to create the code or website.
Ahh to live in an ideal world!
Of course what really happens is that the “specification” (if one is written) is full of ambiguities, as is anything written by humans.
The solutions provider, unaware of this, creates their magnum opus, based upon their interpretations of the ambiguities and confidently delivers to the client. Upon seeing this work of beauty the client promptly, and unreasonably, has a hissy fit screaming about how this is nothing like what they asked for.
The client, unaware of the ambiguities, patiently waits an eternity for the slothful solutions provider to finally deliver the simple piece of work that they need. They are then dumbfounded when what they are given is plainly wrong. Moreover, the provider becomes ultra defensive claiming that this was what exactly the client had asked for.
Enter ‘the prototype’.
By agreeing in advance that the provider will prototype the work (be it a website or a suite of applications) both parties have the opportunity to find out if work is progressing in the right direction.
This prototyping can take the form of showing design work to a website client (yes there really are people out there who don’t do this!) or giving the client access to new web pages or areas of functionality as they become available. The key here is to do this often and with the understanding that this isn’t the final product.
From the perspective of the provider, the sooner a ‘problem’ is identified, the less the problem is compounded (think angle of divergence). This reduces the time lost to rework and so reduces the likelihood of slippage.
From the client’s standpoint, the more often they can see the work the more assurance they have that things are progressing as they would want. They also get the opportunity earlier in the project to identify things that have been forgotten. OK, so these forgotten items may still incur an additional cost as they weren’t part of the original scope of the project, but better to find that out when the missing items can be worked into the project rather than finding out on the day when it all “goes live”
If you’re a client looking to get a website or some bespoke software, ask your provider how often they intend to prototype. It they don’t intend to do so, look for another provider.
If you’re a provider working with a new client, ask them how much prototyping they would like to see. If they don’t want to see any – insist that they see some (as a bare minimum the basic design for a website).