Productivity in information technologyThe secret to extreme productivity in IT is dead simple. It's so simple, that most people think they know it and are doing it already. Few are. Very few are.
Now this may seem obvious - and it is - but few people in IT realise that they don't know what the customer needs. They think they do - and the customer thinks they do - but in reality they don't - and, more accurately, can't! You see, in most cases, no one can know what a particular customer really needs. The customer certainly can’t. How can s/he? Unless s/he has an intimate understanding of what IT can deliver, s/he can’t possibly know exactly how it could help her/him - and even then it's highly unlikely that s/he would get it right first time. The IT provider can’t either. How can s/he? Unless s/he has an intimate understanding of the customer’s business, s/he can’t possibly know exactly what form of IT system is needed.
Few people realise that this gap exists. And as a result, most people carry on as if it doesn’t. So requirements keep changing. The wrong thing gets delivered. Masses amount of rework is done – which someone ends up having to pay for. Projects go over time and budget. Companies lose credibility and profitability. Share prices plummet. Everyone blames someone else – but no single party is to blame. It’s all the result of the technology gap. The solution requirement is some way in which the two parties can co-operate to bridge the technology gap. IT’s productivity solutionIT’s productivity solution – what everyone involved in IT should focus on, all the time, in every situation – is
Prototyping outputs is making mock-ups of the end-product for the customer to interact with and clarify his/her thinking in the process. A prototype is different from a user requirements description. It’s a dummy of the real thing.
Prototyping enables IT providers and their customers to develop extremely well-defined solutions before engaging in the costly and time-consuming delivery of the final product.
As soon as the customer sees the final product, s/he realises that what s/he ordered isn’t exactly what s/he needed! Prototyping is also hard for non-IT people, because they don’t know what they don’t know. Although they are keenly aware of their ignorance of IT, they don’t realise that no one can possibly know exactly how IT could be applied to their benefit. They assume that, because IT people understand the technology, they know how it can be best applied to the customer’s business. This is simply not true. A relentless focus on successive prototyping before engaging in delivery, impacts on productivity dramatically. Sure, it lengthens the discovery part of the development cycle but, in the process, it shortens the (much, much longer) delivery part of the cycle dramatically. A word of warningPlease be aware that as simple and straightforward as this solution might appear, most people find it incredibly difficult to discipline themselves to do it. Unfortunately, short of hiring (and paying for) a genius who knows what the customer needs before the customer does, there is no way one can avoid the process of establishing exactly what the customer needs. Better to discover it after a few cheap rounds of prototyping than after one long (and expensive) development effort! |
|||||
|
|
|||||
 |
|
|
|||
There is a massive
gap between what the IT provider knows IT is capable of and what the
customer would use it for, if s/he knew what it had to offer.
It is only when the customer sees the end product that
her/his thinking clarifies. Until that point, s/he has had to rely on
his/her imagination, which is limited to what s/he knows.
Prototyping is hard for IT people, because they are
very technology focused. They know that there is a technology gap but, for
the most part, they don’t realise that it prevents the customer from knowing
what s/he really needs – at least until after what s/he has ordered is delivered.