How to Become a Chief "Unplanner"

Every government has weird bylaws. Here in Canada, in Victoria BC you cannot have $ two bagpiper’s$  playing on one street at the same time. And before you get ahead of yourselves, my US friends, it turns out that in Arizona it is$  illegal for a donkey to sleep in a bathtub$ . They can stand in a tub but they are not allowed to have a snooze there.

Most of the stories behind the strangest bylaws are usually from a one off incident that escalated politically and then, as governments do, bureaucracy becomes the answer to solve a public outcry. Obviously, there are times when great laws are developed this way but these situations, over the last hundred or so years, have left a lot of bureaucratic detritus for public servants to wade through. The babies were never thrown out with the bathwater because the bathwater was never thrown out.

This does not just happen with bylaws. It happens with processes, technologies, and systems within governments. Everything becomes a Frankenstein system as new processes, technologies, systems, and laws are tacked on to the old ones resulting in inefficient systems that are unnecessarily complicated.



The many reasons this occurs...

We work in systems that are always looking for progress. We want to look forward rather than backwards. This is particularly relevant in the case of the bylaws like the one from Arizona. It was created so long ago and civil servants don’t want to spend their time cleaning up bylaws from 100 years ago. Along with this, we are looking to be efficient.

It often seems faster to make a few changes to an existing system or process rather than creating new work for ourselves reimagining how a process holistically should be done. And politically it can be quite disruptive to do this.

New projects often go through more of a public process and can get flagged by politicians or the public, which may mean cancelling the project or having it shift with prevailing political winds.

There’s also fear of loss of work or loss of value for employees. Many are trained on specific technologies or processes. They have spent years becoming experts, and change can be difficult. Along with this there is also a perception that it would cost more and take more time to build new.

Arguments for Chief Un-Planners

This is where the role of Chief Un-Planner comes in. While not an official position, I have long dreamed of taking on this job. A Chief Un-Planner has the task of unravelling overly complicated processes, creating some disorder in areas that have become too rigid, and making room for less bureaucracy wherever possible.

This position would benefit civil servants, citizens, as well as external stakeholders including technology companies and other businesses.

Internally, it would create clearer channels for projects with less confusion between departments. This would give staff more time for more important work. It would also create an environment where technology, processes and systems were more modern as a normal function of the working environment, rather than years behind what is happening in other workplaces.

These modern systems would help to create more ease working with external vendors and other stakeholders. Governments often create extra work, particularly for smaller or more innovative companies, because our systems are out of sync with processes and technologies that are the norm for these businesses’ other clients. Governments often lose out on some of the more innovative companies because the processes are too time consuming and overly complicated. With limited resources, they will often look for other organizations to work with that are easier to work with. Or they will raise their prices to accommodate the extra time and effort it requires to work with governments and associated agencies. This is a huge loss to the public service in terms of innovation.

How to be a Chief Un-Planner

I used to think there would be one Chief Un-Planner per city but recently I have come to believe that we can all be Chief Un-Planners. It is more fun than LEAN (sorry LEANers!) and is very flexible.

There will probably be little reward for it and there are no badges to earn, but when done well will create projects that are a pleasure to work on as the focus can be on the project itself and not so much on fighting old systems, processes and tools.

There are many ways to Un-Plan. Here are some examples of possible ways to Un-Plan in your government workplace.



Tip To Tail Workshops

This human centred design process brings together all the groups that may touch a project and they work through the entire process together. For example, we used this tool when we were developing a data governance policy. We had a facilitated workshop that included: front line library staff, branch managers, library senior management, tech support staff, tech device management, tech senior managers, procurement, clerks, legal, open data and smart city staff. In a perfect world I would have also included the public in the workshop, but we did have data from them from a series of public engagement workshops prior to this activity. As a group we were all able to see the effect of our work right from the customer interactions through to all of our internal systems.

In our organization, the ‘clients’ for the tech staff are other departments and not the public. Seeing the effects of a variety of decisions, and how they ripple through the entire process, helped us all make decisions that smoothed the process and reduced redundancies, instead of making unnecessary add ons that create confusion. It also provided opportunities to ask why each department had certain processes, which helped with an overall understanding. This all created a more streamlined process and sped up the next stages of policy development.

Work With What You've Got

Often we buy new technologies, create new processes or systems because we don’t realize we already have the tools we need. For example, we were developing Innovation Challenges as a new model of procurement. The general idea was to have a series of small challenges each year that would invite tech companies to respond and develop prototypes. These prototypes would be installed and tested. The one that worked the best within context would be chosen for the full project.

We were convinced that we were being renegades and would require a new set of procurement regulations in order to carry out this project. But we knew it could be done as many other cities had been implementing these challenges across the globe. We spoke to several of our colleagues in Materiel Management. As this was an unusual request, we were told that it could not be done in our current system. We kept asking until we found the creative thinker of the group who also had a clear understanding of the current process. We walked through our idea with them and tested it out against the system already in place. As it turns out, nothing we had planned contravened the current procedure. It was just not what they were used to doing. The process was flexible but the ‘We Have Always Done it This Way’ habit was strong.

Build It Into Your Systems

When we buy new technologies the focus tends to be on the buying, implementation and the immediate needs of the organization rather than considering the process as an interactive process. For example, if the business planning process added a few simple features many years of frustration could be avoided. To start, when you’re writing your annual business requests add in a section that outlines the lifecycle of the tool, process or system.

Nothing lives forever - not even technology. This is not about years but about the uses of the tool, system or process and what to look for when it is nearing the end of its life cycle. It may feel strange at first but as you work through the process each year these will become more clear.

After you have procured and implemented the technology have a yearly review. This should be done based on the criteria that was originally set out and be weighed in on by everyone using the tool. Each year, as more criteria are getting checked off, you are given a heads up that it may be time to start researching, preparing for staff training and budget planning. In this way everyone can move ahead together, with relatively few surprises. This is particularly important for large, complex or heavily used tools, processes and systems.

Be The Public (or at least talk to them)

No public process should take more than seven steps, and this is probably too many. With all the internal silos and old processes building up it can be incredibly frustrating as a member of the public to get anything done. They have no idea that the process includes ten different internal groups, seven different technologies and one system designed by Randy in the 1980’s that no one really knows how to upgrade, but has become an integral system.

Your residents are used to the ease of Shopify, Uber and Amazon. A complicated system for something that seems like it should be simple can create frustration and distrust.

Shifting your focus to be more citizen-centric in how you build or deploy tools or processes doesn’t have to be done all at once. Each year choose one process. Create a user journey process that can be documented. This process can be undertaken by your team members, staff from other departments and, if possible, members of the public. Through this process you will find some easy fixes, some that are more complicated, some that seem complicated but are actually pretty easy if you talk to the right people, and some gnarly messes that will take money, time, and change management to fix. Fix the ones you can and share the results with other departments. Often they are the same issues that others are having. Then these conversations can move up the ladder.

This can be the difficult part, higher ups don’t always like hearing about big thorny issues, but when you start building it into your systems you have data to back your ideas up, and hopefully, it can become a normal part of the way teams work.

Second Guess Your Work, and Your Colleagues' Work

When complaints come in, when you are adding in a new public wifi network in a park, when you are looking to innovate traffic signals, don’t forget to ask ‘why’ along the way. It will annoy everyone you work with. And it will make your lives easier in the long run. As you are building the security for the wifi system, obviously ensure the data is safe and secure, but don’t keep adding terms for the sake of adding terms. There will be a million contingencies and ‘what ifs’ but ask yourself - is there already a law, security feature or process that we already use that will cover that occurrence? Ask why it is important and how it will affect user experience for the public. Talk through the risks and rank their importance. All risks are not created equal. Using human centred design processes can help to develop a process to work through all of these questions prior to a projects’ release. It can feel onerous to go through this but will, in the end, save time, money and frustration when you have been able to eliminate rather than add on to tools, systems and processes.

Lastly...Ditch the Goat

Admittedly, this is not something I have seen done but I figured I would throw it in in case anyone is in a position to give it a try. The public hates red tape. They love stories of governments finding ways to create less of it. It would be a great, and fun, story for any city to have a purge of old bylaws all at once. Nothing too recent as that could create trouble, but look at the bylaws over 80 years old. Look for the goats. Package them all together and have a one time by-law expulsion of all the odd ones. This would accomplish three things - clearing out some old bureaucracy, getting some good attention, and, hopefully, create a mindset where being able to periodically clear out bureaucratic detritus is done on a more regular basis.

I hereby anoint you a Chief Un-Planner. Go forth and unplan. Let it be a bit messy, be more comfortable with complexity and understand that not all risk has the same value.