Innovation in local government: PaaS, process and agility.
Customers expect councils to be as innovative as any other service provider. Process, agility and platform as a service can help make that happen.
Great experiences are increasingly driven by innovation. And with the modern customer seeking out great experiences in all facets of their lives, innovation applies more than ever to councils. In fact, innovation has become intrinsic to council business in their role as the people's government.
As a concept, innovation is actually pretty easy to embrace when you know what to look for. It is, in fact, just the middle cog in a three-part process that begins with invention and ends with adoption. Adopted services, processes and technologies then go through several maturity stages over their useful life before being replaced through obsolescence and new waves of invention — voila!
This is important to understand because as I discussed in a recent post ‘When should city government leadership know about emerging technology?’, city government leaders need to know where to focus their energies. I'm sure you will agree it is not on invention.
Rather, I believe attention should be targeted at just a subset of innovative ideas relevant to the professional disciplines within the sector.
Once that innovative solution has been identified, the council's full energies can be brought to bear at the point of operational adoption.
Executive leadership teams then use regulatory controls and risk management to govern significant programs of investment throughout this part of the operational lifecycle.
At this point they are often looking for speed and longitudinal benefits, but also sustainable outcomes. These ambitious dichotomies (read: very hard to simultaneously achieve) are characterised as business agility.
The innovation toolbox.
In order to deliver agility, the organisation itself requires capability in the form of a reliable toolbox. Ideally this special toolbox is stocked with a tested set of innovative business rules, processes and technologies to operationally support adoption of the organisation's targeted innovation which might be a new or enhanced service, technology or partnership.
Each instrument in this virtual toolbox is intimately familiar to their users and can collectively be categorised as a platform.
Platform + Agile.
The concept that orchestrates these two elements is called Platform + Agile. It is an organisational frame devised to avoid big bang, big risk projects by allowing the organisation to deliver quick, meaningful wins using repeatable and reusable organisational tools.
As a sector that invests equally large sums of money year-after-year into assets, project management and technology, city government provides an ideal canvas for the Platform + Agile approach.
Over the last couple of years, I've been working with a number of councils to realise transformation strategies based on the Platform + Agile approach.
And even though (or maybe even because) 80% of what they do as organisations is project-based, and even though (or maybe even because) they are always at pains to control their outcomes, it has been hard and often fruitless work.
Why? I believe the reason is that the '+' in Platform + Agile stands for ‘process’.
For that reason, city government leaders who are serious about governance and innovation and lean-management practices must be at pains to ensure that implied process management is fully extracted from all Platform + Agile projects or strategies.
Put simply, extracting process management means enabling its effective practice within and on behalf of the organisation.
According to NFL coaching legend Bill Walsh, 80% of the game's outcome on match day could be controlled with the right level of comprehensive planning and preparation.
That is the philosophy of Platform + Agile; to control manageable play-by-play parts of a bigger game to deliver numerous small wins throughout the afternoon that ultimately add up to an overall victory on the day, and eventually a Super Bowl championship.
Walsh's control of the game didn't happen simply because he made sure his teams knew the rules of play and then played by them.
The San Francisco 49ers’ success throughout the 1980s happened because of how they applied, then relentlessly practised, the strategies and tactics codified in their own playbook. Essentially that playbook was a system of Platform + Agile processes.
In the business of city government, where every day is game day filled with risk and public scrutiny, this mindset allows organisations to deliver smaller more frequent project successes at lower risk.
Now before you think this is beginning to sound like a strategy wrapped in philosophy bundled in an enigma, while the overall approach is conceptual (until you do it!), the component parts of Platform + Agile are actual things. Let's now take a look at them and the main challenges I've seen in their adoption.
The Platform in Platform + Agile refers to cloud-based PaaS technology. Here are some examples which illustrate the deep vein of functional capability in these rich platform toolkits:
- Amazon Web Services
- Microsoft Azure
- IBM Cloud
The power of operating a Platform strategy is not just enabled through the benefits of cloud. It is essentially the power of micro-segmentation throughout the cloud stack, plus the Service Oriented Architecture (SOA) available through the partner networks that allows smaller pieces of work to be delivered more frequently.
The depth of offerings, and the diversity of the solution architectures extends in some platforms to well over 80 technologies that you might otherwise have to buy at great expense from more than 50 different vendors. And they literally work together at the click of a button.
However, the real killer app for the organisation is the increase in the skills capability of staff who become proficient in working within a singular technology platform, codebase, and partner ecosystem.
If I hear you say: "that sounds like a lock-in", then fair play. That has generally been the case. But there can be no short-term commitments to platform, nor for transformational change.
Platform capability allows you to take a big problem, break it into small problems, win fast benefits for the business and move on to the next project - all within the same system environment. Win! (Remember my Bill Walsh story from before?)
Now let me briefly address the challenge as I have seen it.
Because PaaS is a relatively new set of technologies and concepts for a lot of people, for illustrative purposes I'll just use your financial ERP as the basic example.
You have a financial ERP business system. The software provides all the functions you need to transact all the financial requirements of the business, from receipting to payments to budgeting to purchasing to contract management - and the list goes on.
Each of those functions is kind of like the equivalent of all the SOA components within a platform except we're now talking about storage and compute and analytics and artificial intelligence and mobile services and security and more: all the building blocks required.
The financial software will provide massive organisational benefit when you get all those functions up and running and correctly applied to your specific businesses requirements.
Where are the business processes?
But while there is some inherent workflow in the software there are NO business processes. And you can't just do one function - you need to go big bang and probably think that you'll be fine despite all the data to the contrary regarding big bang projects.
You see, specifically for ERP, somewhere between 1995 and today we confused workflow and software automation with process, and ceded control of our organisations to software companies that promised to deliver out-of-the-box process management.
PaaS works the same way. Each of the identified platforms will provide you with terrific, out-of-the-cloud software infrastructure, on a common platform, with repeatable tools.
Executives must be at pains to ensure that implied process management is fully extracted from all Platform + Agile projects or strategies.
Let's get agile.
Now the agility part is a little easier to grasp. Agile is essentially a just-enough-just-in-time way of doing something. As a discipline, it is often tied to software development, or if you are not in that space, organisational Project Management Frameworks (PMF).
The challenge for many businesses, especially the mid-market for which Platform + Agile is a godsend is that an organisation-wide PMF doesn't exist, or its delivery is outsourced to a range of Prince2 or PMBOK consultants. Maybe even multiple examples of both.
This results in the second big problem: a lack of repeatability, scalability and ultimately agility itself across the management and governance of the program of work (multiple project portfolio).
You can't do it without process.
Design (process) trumps your building medium (software code or concrete) every time. It is a fundamental law of all design be it computing, engineering or whatever.
Yes, you can buy platform technology and yes, you can employ or deploy agility frameworks and resources, but neither are self-guided, fit-for-purpose solutions. For that you need Platform + Process + Agile.
The difficulty in engaging executive leadership in the Platform + Agile strategy is that the overall program is neither pure technology nor pure lean management.
So on top of having to manage the confines of procurement processes, over-zealous ERP or platform vendors, and figure out which project management approach is being used this week, overall ownership is a problem. If the CEO or executive leadership group wants Platform + Agile then the path is clear.
The curiosity about ownership is that executives who show an almost complete disinterest in the operational nuances of technology projects will simultaneously show an equal but opposite interest in organisational improvement.
The secret is in communicating how using Platform + Agile can deliver just-enough-just-in-time or minimum viable product outcomes for what would otherwise be big, scary, doomed-to-fail organisational projects.
And that's it.
The main challenges you'll need to look out for or learn from if you are operating in this space are:
- Assumed levels of ownership of the overall delivery strategy
- Assumed levels of business processes within the Platform + Agile components.
Now finally, can you take organisational and process design too far and ultimately slow down organisational agility?
Of course you can.
But to use that as a premise for not establishing proper process management, independent of the solution or partner provider, is a massive show of distrust. In many cases I would even say naive and untenable.
If chasing the big bang dream is the goal, then your only requirement is to get everyone in the organisation, regardless of their specific job, to do their job at the highest possible level for several years. Probably higher than they have ever done it before. And then count the cost.
I prefer a method driven by a process of incremental success. Where organisations can divorce the business process from the solution, and build the inventory of skills, both attitudinal and technical that will lead to lots of progressive improved outcomes. And maybe even a Super Bowl moment reserved for the chosen few.
Which sounds more achievable?
About Peter Carr.
Peter is an Asia Pacific micro-influencer, technology analyst, and trusted executive advisor who is excited about humanizing cities, people, process, technology and data. He helps professionals make better business decisions involving technology.