In my ongoing effort to remember the key notes from events and conferences I have attended, some thoughts on Rethinking the Customer/Citizen Experience; 2017-11-24. The overview blurb was:
We will look at transformation through the lens of both the ultimate end-user experience, and the internal employee perspective which inherently must be connected to successfully implement change.
Personas and Small Things Create Big Results
Two key themes that came out of the event. The first was the use of personas to aid in develop a good customer experience. The second was the importance of implementing big things through a series of small steps.
Developing a persona is an attempt to understand behaviors of customers/clients. These are done to help frame development and make changes. The recommendation is to limit the number of personas to less than six and ideally 3-6. A single persona is then used to track a collective journey through a process journey. One description of a persona is as follows (Adapted from Agile Modeling):
A persona defines an archetypical user of a system. The idea is that if you want to design effective software, then it needs to be designed for a specific person. Personas represent fictitious people which are based on your knowledge of real users. Unlike actors, personas are not roles which people play. In use case modeling actors represent the roles that users, and even other systems, can take with respect to your system. Actors are often documented by a sentence or two describing the role. Personas are different because they describe an archetypical instance of an actor. In a use case model we would have a Customer actor, yet with personas we would instead describe several different types of customers to help bring the idea to life.
It is quite common to see a page or two of documentation written for each persona. The goal is to bring your users to life by developing personas with real names, personalities, motivations, and often even a photo. In other words, a good persona is highly personalized.
Personas and the Public Sector
According to PwC, personas have been used successfully in various public sector organizations including the Canadian federal government. My Spidey-risk-senses however went up over two aspects:
- The volume of the personas. Governments do things that no one else wants to do, given the myriad of our product lines; can we realistically develop personas for the breadth of services provided?
- Personas as a Cause Celebre. What is the risk of personas becoming a political nightmare? Our society has become increasingly sensitive and intolerant to labels. What are the risks of not having the right personas to meeting a groups demands or having to remove a persona because it does not match an external groups political objectives?
Personas But Tread Carefully
The answer is to use personas but create them through engagement with those they represent. As well, some political mettle is likely required to explain to role of a generic persona that provides a model or analog to society at large (heck, is this not the description of a representative democracy!). Nevertheless, have an emergency risk mitigation plan for either the creation of politically mandated personas or for suppression/modifications of personas for similar political imperatives.
Other than these risks, using a customer experience focused technology methodology can be highly applicable to the public sector. Like most things though, the proof is in the execution and delivery. This leads us to the second part of the morning’s presentation –
Small Steps to Implement Big Change
I am a big fan of the Agile method (e.g. small successes building over a few weeks to a larger objective) versus waterfall. My observation for governments though is that the larger organization has a hard time with Agile. It is easier to understand and support a multi-year, multi-million dollar project (e.g. put a man on the moon by the end of a decade) than approve the objective but in a series of short sprints (e.g. what do you mean you plan to have 520 sprints to get a man on the moon!).
Of course I am not being entirely fair to governments in saying this. After all, it was Apollo ELEVEN that landed on the moon, Apollos ONE through TEN were examples of very LARGE sprints. Nevertheless, here is my thinking about any project:
- Large objectives are fine (moon, replacing an aging system, etc.)
- The objective must be broken into a series of steps (phases, projects, etc.)
- Each step in turn should not exceed the following:
- Six months in length
- $500,000 in expenditure
- 25 people for the entire project team.
- Only start upon the successful completion or closure of a prior step.
- Turn over is limited but also encouraged, e.g. no more than ~90% of the team is the same project to project but no less than ~50% of the team has changed.
- The above measures can be an average for a system, thus
- Subsequent phases can get larger but only after smaller projects have successfully concluded
- Professional judgement and risk tolerance is encouraged so that the above is a strong guideline and not a set of absolutes.