By Ben Norton

This first post in our series about our experience working in large, marketing focused software deployments looks at the importance of remembering how important the end-users are.

A wise person of indiscriminate origin (maybe we made this one up), once said that new technologies only gain traction with their intended users if they:

  1. Solve a problem that needed fixing.
  2. Mimics an existing human behavioural trait.

Email is a great example of meeting both criteria:

  1. The problem – it is the speed and cost of analogue written/traceable communications.
  2. The existing behaviour – it is our need to communicate one-to-one or to many in ‘real-time’ (without the vulgarity of actually having to speak to anyone).

So, it’s vital to start with the end in mind

Retaining this clarity of purpose (what problem are we fixing/what existing behaviour are we enabling) on larger, enterprise level software implementations is really hard work. By the time you have engaged the myriad clever people with specializations (Program/Project Management, Business Analysis, Technical Architects, Testing, Developers….) and thrown all of these agendas, personalities and egos into the mix (not to mention cultural and geographical complexities), it’s hardly surprising that the poor old end-user is often forgotten. Also, big technologies are complex and really can do some seriously clever stuff. The challenge is striking a balance between putting an ashtray on the motorbike (because you can) and responding to actual user needs – not least of which is delivering a tool that they can easily use.

If you build it, they won’t come

Understanding what these end users need is addressed in the ‘requirements gathering’ phase of the project. Again, because it’s IT, this has been smothered in acronyms (so you clearly understand exactly how little you understand); BA, BRD, PID to take the top off the tip of this iceberg.

Bottom line: sitting with a carefully selected group of end-users and having them describe their processes and needs is where you start (and where you should remain to some extent).

This process generates ‘Use Cases and User Stories’. At the same time, someone needs to get ‘the business’ on the couch in a darkened room and interrogate what it wants the tool to do. Finally, it kickstarts an important trend of user engagement that will be crucial to long-term success. People tend to play nicer if they think they are being listened to….

A note to the uninitiated – these two sets of objectives often have some – (ahem) – agenda based differences. Seriously though, gathering this info and then establishing a workable compromise between the two is central to success.

In the next post, we will talk about how to keep these objectives stapled to the collective forehead for the duration of the project.

Share This