Users Don’t Know What They Want

I have developed quite a few systems, and worked as an architect and systems integrator on many more and it’s always been pretty clear to me that in general users don’t know what they want.  Even if the user takes the trouble to write a specification, in the end it won’t meet their requirements for at least one of the following reasons:

1. The most likely is that they are not the customer, they just happen to be nominated as the customer’s representative.  If you are lucky it’s because they are respected by the customer community for being in touch with their needs, unfortunately that’s rarely the case.  I once had a customer who described his requirement for an aerodynamics analysis platform as, “I need a mega-floppy Unix box”. At first I thought he was joking but that really was the limit of his capacity to explain his requirement.  The guy could do computational fluid dynamics but he had no concept of his needs.
2. Even if the customer rep really understand the requirement they often don’t have the skills to communicate that requirement
3. If they can define the requirement they don’t have the skills required to manage the inevitable trade-offs that need to be made to get the product to meet quality, time and cost targets.
4. If they can do all of the above they will probably fail because they will take away from the development team the essential feeling that they are responsible for project success.  The Project manager will probably love having a customer like this because, its takes a whole load of responsibility off the development team and places it on the customer.  Unfortunately in the end a failed project is a failed project, regardless of whether you can blame some poor customer representative or not.

Don’t get me wrong though I am not arguing against customer involvement, for two reasons:

1. Sometimes you get a really great customer, who you should really hire as quickly as possible!  Then employ them as a solution manager, product manager, solution architect or whatever term you like to use for the person on the development team responsible for defining the spec and making sure the product meets it.
2. If you can reach real customers, and find a way to engage them in the project then they can add real value.  That’s why some great open source projects have been built, because the developers interact very closely with their user community, who often also happen to be their testers and sometimes their developers.

So what’s my perfect customer engagement model?

1. Ensure that the development team takes responsibility for project success.  This means that if the customer rep says something that might compromise project success the development team don’t just role over and say yes they fight for what they believe.  I call this partnership.  I don’t go in for this “customer is king” idea where the relationship is long term, needs to be built on trust and is judged by long term success criteria, (I work in IT Outsourcing).
2. Make sure that these three roles are filled in the project team.  There are loads more roles but these are the ones that are most often forgotten.
   1. Someone who owns the whole solution, the person who makes sure that there are no gaps and that the solution meets the needs of the customer and the service provider.  This person needs to worry about Process, Organisation, Location, Data, Application, Technology, Security and Service dimensions.  It’s not just a Technology role.
   2. Someone who owns the user experience, the person who makes sure that when all of the bits of the solution get integrated together and delivered to the user it looks and feels like it was designed to be used, and that it fits into the users existing tools and processes
   3. Someone who owns the delivery of the service, (remember I am talking systems integration not software development), i.e. the same role as the user experience guy but from the perspective of the team or teams that are going to provision, manage, support and make money from the service
3. Make sure you write these three documents, again there are often a lot more, especially on big projects but these are the core three that tend to be neglected:
   1. A Conceptual Architecture.  The document that describes at a high level all of the key concepts that people need to agree to in each of the Process, Organisation, Location, Data, Application, technology, Security and Service dimensions.  This document provides the framework off which all other documentation hangs.  The Solution Owner writes this document, it’s the “contract” with the rest of the team.  If anyone in the team can not deliver his bit of the solution consistent with the Conceptual Architecture they need to pipe up and resolve the issue with the Solution Owner.  All the way through the project the Solution Owners job is to ensure Conceptual Integrity is maintained.
   2. A Functional Specification.  The document that describes, in terms that the user can relate to, what functional capabilities are being delivered to him, which ones aren’t being delivered and any constraints in terms of devices, operating systems, network connectivity scenarios etc.  This document is the bible for the engineers on the project; it defines what’s got to be delivered.  Whereas the Conceptual Architecture describes all the bits that are needed in order to deliver and how they relate to each other.  The User Experience Owner writes this document and agrees it with the customer.  It’s the “contract” between the User Experience Owner, the developers and the project manager and the user, it binds everyone together and as such is probably the most important document on the project.  The UE owner maintains this document as the project progresses and it’s used to manage change with the customer, to define the structure of the acceptance testing and as the basis for user documentation etc.
   3. A Service Definition.  The document that describes
        i.      How users provision, access and interact with the service
       ii.      The volumetrics, (number of users, amount of data, number of transactions)
      iii.      The service levels, (response times, hours of operation, hours of support etc)
      The Service owner writes this document and agrees it with the customer.  It’s the contract between the development team, the user and the service delivery organisation.
4. Note in all three cases above the documents are written by their respective owners.  Bits of the document are not carved up and delegated.  The owner has full editorial control and ensures the integrity of the whole.
5. Make sure the project manager is not too powerful.  I personally quite like the team model that Microsoft uses in concept, although I have never had the chance to use it.  On most of my projects I like Customer, Solution Architect, Account Manager and Project Manager to work as the team.  Each person on the team needs to feel ownership of success, but focused on their perspective.
6. Engage real customers, often real users through interactive mechanisms that allow iterative refinement of the solution in a real business context.  I am not a huge fan of getting everyone in a workshop for a day, (fatigue quickly sets in, a few personalities dominate, no one has time to think things through).  My preference is a mix of short workshops, threaded discussion groups, blogs, regular surgeries, walkabouts.  Of course giving some real users access to your daily builds/regular builds either remotely or as their day to day working environment can also help build a great system.  Although this only works for certain types of users and products, where data contamination and business risk are acceptable.