Citizen Development Governance | In-Depth Guide

More and more companies are turning to their business users to solve business problems with bespoke apps. However, this creates a whole range of new challenges for your IT team. Today we’re diving deep into citizen development governance.

Citizen developers are ordinary, non-technical employees, who have been empowered to create solutions for their teams, rather than waiting for the IT specialists to do it for them.

This can offer huge value, but only if your team has the right governance framework to work within. Today, we’re looking at how to achieve exactly that.

First, though, let’s start with the basics.

What is citizen development governance?

Citizen development governance is the sum of all of the rules, policies, procedures, and workflows that you put in place to maximize the value you derive from your team’s output.

We can break this down further into two more specific goals:

1. Maximizing efficiency, ROI, and quality of output from citizen developers.
2. Mitigating against threats, risks, or other security and compliance issues that you might encounter.

(G2 )

Like any kind of governance, you can turn to a variety of tools, techniques, and strategies for managing your developers.

For background, check out our in-depth guide to citizen development .

We’ll dive into some of these in more detail a little bit later, but for now, we can break them into the following categories of governance:

• Policy-level governance - The rules, principles, and goals that underpin your citizen development program.
• Process-level governance - The specific procedures that employees follow when creating, sharing, or using custom solutions.
• Technical governance - How the specific tools you provide to citizen developers determine the actions they can take.
• Monitoring, review, and oversight - Any measures your IT team puts in place to oversee and assess the implementation, process adherence, output, impact, and value of your citizen development program.

Naturally, there’s a large amount of overlap between these.

Your governance policies should be the starting point for all other measures you put in place. The idea is to craft effective structures for your citizen developers in the abstract - that is, at a policy level - and then decide on specific measures to implement and enforce these.

We’ll look at how to build citizen development governance policies in more depth shortly.

But before we get to that, we need to take a look at the specific challenges that your governance policies will address.

Governance issues for citizen development

Since one of the goals of good governance is to mitigate against potential negative impacts of citizen development, one starting point here is thinking about what can go wrong.

So, let’s think more specifically about the things we want to protect ourselves against.

Accountability gaps

One of the fundamental challenges here is the fact that you’re essentially delegating development tasks across the entirety of your business. The larger the organization, the more problematic this becomes.

The core of the issue is gaps in accountability.

There are a few key scenarios where this is particularly obvious.

These include:

• Support & maintenance.
• Development issues.
• Lifecycle management.
• Administration tasks.
• Error responses.
• Usage monitoring.
• Compliance tasks.
• User management.
• And more.

So, the question is who’s responsible for each of these issues within your citizen development program?

There’s no one-size-fits-all approach here. Indeed, you have a few different options, including the original app-builders, your internal developers, your support team, or other IT colleagues.

The key thing is that your citizen development governance policies clearly outline who is accountable for each of these issues. You should about longer-term issues, such as what happens if the original developer leaves the organization.

(CISCO )

Security issues

Security concerns are one of the top drivers of internal resistance to citizen development. Many IT managers are skeptical that on-the-ground, non-technical employees are up to the challenge of creating tools for modern, secure businesses.

However, the key variable here isn’t so much citizen developers themselves, as it is the tools and frameworks that they use and the processes you build to support and manage them.

In terms of security, the jumping-off point is thoroughly documenting all of the security risks and threats you want to prevent. Since different teams will be building tools to handle different resources, you can start with quite high-level issues.

You might then drill down into specific data sets or other assets that are leveraged within specific departments. So for example, your sales team might encounter different cyber risks than your production floor.

Of course, there are some policy-level measures we can put in place straight away, but for the most part, you’ll address these risks later, with the more practical end of your governance strategy.

Lack of oversight

This is a bit of a strange one. One of the real benefits of citizen development is bringing shadow IT under the watch of your technical team. Even so, a lot of companies struggle to get enough oversight of what their teams are up to at a more granular level.

This is starker in some citizen development programs than in others.

For example, it’s comparatively easy to oversee activities with a relatively small number of citizen devs, who have a specific, limited mandate. By contrast, if just anyone can build whatever tools they want, things are a lot messier.

So, you’ll need to think about who’s responsible for monitoring which employees are building what, as well as how and when. We can also ask the same questions about different tools’ end users.

Again, you have a few different levers available to you here.

The key is to determine the extent of oversight you need. You can then build this into your subsequent decisions. For example, by limiting your citizen developers to a single tool that gives your IT team total visibility over their creations.

(G2 )

Error reporting and handling

Handling errors and bugs is a surprisingly fraught issue. To understand why let’s take a little step back and think about how this works with more traditional software procurement.

Normally, this would fall on the shoulders of one of three teams:

1. The vendor, for external tools.
2. The responsible in-house developers.
3. Your support team.

Obviously, external vendors are out. At least, excepting cases where the problems occur with your citizen development platform itself, rather than the specific apps created using it.

So, our remaining options are individual citizen developers or the support desk. Each approach has its pros and cons.

The upside of relying on your existing support team is that there ought to be suitable processes and infrastructure in place already to facilitate the extra workload.

By contrast, it would be a big undertaking to create a system for individual citizen developers to receive, monitor, and action support tickets. So, this might not be viable for large or distributed user bases, although it’s perfectly reasonable within small teams.

On top of this, your support desk might not be thrilled to learn that they’re going to be responsible for dozens or even hundreds of new internal tools that have been built by non-specialists.

So what, tough toenails?

Not quite.

One strategy we can implement to improve the experiences of our support teams is to try and achieve a high degree of homogeneity across our citizen developments. Homogeneity means that the basic structure and underlying technology is similar across different apps.

For example, if they’re built with reusable components, design templates, and other common elements.

Unsuitable solutions

But what happens if your team builds tools that just don’t cut the mustard?

How do we prevent unsuitable tools from getting rolled out? Say for example that one of your citizen developers messed up a formula variable in a dedicated calculator tool and no one caught the mistake.

Not only would this be a waste of everyone’s time, but it could also lead to seriously impaired decision-making.

Again, we can think about how this works in more traditional development methodologies.

Specifically, we have testing and QA teams for this express purpose. But how do we achieve a similar result without overburdening these teams?

Again, homogeneity is the key here. That is, when we limit the number of elements that are actually unique to any given application, we also reduce the workload for responsible testers or other colleagues.

In fact, with the right combination of homogeneity and scope limitation, it’s possible to move towards more streamlined approval processes, rather than the more arduous, labor-intensive QA processes that you might use for traditional developments.

Overlap, redundancy, & efficiency issues

Citizen development governance also seeks to ensure you actually see the efficiency dividends that you expect. The simple truth is that these are far from inevitable. In fact, things could just as easily go the other way.

After all, we’re talking about letting non-developers loose to build custom tools.

As such, we’ll need strong coordination efforts for things to go smoothly. For example, it would obviously be a waste of time if different members of your team output multiple versions of similar tools.

Basically, we want one hand to know what the other is doing. At a policy level, this might involve designing structures and decision-making processes for determining which projects should go ahead in the first place.

Similarly, it’s worth thinking about the specific policies we can put in place to ensure that projects move efficiently from initial ideation to deployment. As ever, this is about balancing your requirements with the reality of the resources you have available.

Communication & documentation problems

Finally, communication and documentation are huge issues within citizen development programs. Basically, the challenge here is that non-specialists usually don’t have a strong grasp of what needs to be documented and what doesn’t.

What seems like a common-sense solution to a non-developer might actually be a major deviation from accepted best practices.

This has some wide-ranging practical implications.

As an obvious example, it’s much more difficult for other colleagues to support, maintain, or manage a tool when they don’t understand how it’s supposed to work in the first place.

There are two policy-level levers we can pull here.

1. The training requirements before an employee is approved for citizen development.
2. The specific guidance given to employees concerning what needs to be documented.

In other words, your citizen development governance policy must provide clarity in terms of what’s expected of employees.

Who is responsible for citizen developers?

This is an interesting question. We’ve hinted already that governing citizen development poses such a challenge because you’re essentially distributing responsibility for building tools across your entire organization.

On the one hand, this helps to bring shadow IT into your internal technical team’s oversight. On the other, it provides more autonomy to non-technical teams to come up with innovative solutions of their own.

So who is ultimately responsible here?

Your IT team are the ones who decide exactly what can be safely and effectively delegated. They also delineate what’s permissible conduct within the limits of your citizen development program.

Other teams and individual colleagues are then responsible for their adherence to these policies. We can also hold them responsible for the quality and efficiency of their own output, except to the extent that this is determined by the tools or training they’ve been provided.

Take a look at our guide to empowering citizen developers .

What happens when something goes wrong?

This leads us back to accountability. Say you had a data breach relating to one of your citizen development projects. Our first task would be figuring out if the issue was a gap in our policies or a failure to comply with them in the first place.

In either case, this helps us to determine who’s accountable.

More importantly, we can think about the specific steps we need to take to prevent a similar issue from occurring in the future, whether that’s a process-level change, additional training, or implementing extra security protocols.

Of course, there’s also the issue of your immediate incident response. There’s not much point sitting around playing the blame game if you haven’t solved the actual problem.

Sometimes your IT team will need to step in. Other times, it will be faster and easier for the original developer to respond. So, we need some way of categorizing incidents and issues, in terms of severity, complexity, and urgency.

Check out our IT incident report template to find out more about how Budibase can play a role here.

Creating a citizen development governance policy

So now we have a good grounding in terms of what our citizen development governance policy will cover and what it will achieve.

Next, we can turn our attention to the specific steps you need to follow to draft a successful policy of your own.

Here’s what you’ll want to include, in the rough order you should present it.

1. Goals and objectives

First, you want to outline the goals of your citizen dev program.

This achieves a few key aims:

• Providing a benchmark to measure progress against.
• Securing stakeholder buy-in.
• Identifying and addressing shortcomings in your strategy.
• Forecasting business value.

The important thing here is that you choose quantifiable goals. So, you should have a specific figure in mind in terms of reduction in labor hours, costs, or project turnaround times.

2. Competences, responsibilities, and separation of concerns

Next, we need to decide just who’ll be responsible for what. This includes:

• Who can become a citizen developer.
• What kinds of tools they can build.
• What role will be retained for the IT team.
• How these two users will interact and hand over projects.

You can demarcate responsibilities in a few different ways. One option is to draw lines in terms of the stages of development. So, you might allow on-the-ground employees to create a data model, design UIs, and even build automated processes.

You’d then leave more complex deployment, security, and other configuration tasks to the specialists.

Alternatively, your choice of citizen development platform might allow you to codify some of these tasks. For example, with one-click deployments.

At this stage, we can also think about who is responsible for different lifecycle management tasks, like support, maintenance, and user admin.

Check out our guide to working with citizen developers to find out more about establishing clear responsibilities and roles within your program.

(Maruti TechLabs )

3. Approved technologies

This part of your citizen development governance policy is truly make or break. Choosing the right tools for your team is probably the biggest factor that determines the success of your initiative.

So what exactly are we looking for here?

Like any other software procurement decision, there are several concerns to balance, including:

• Cost.
• Pricing structure.
• Functionality.
• Usability.
• Integrability.
• Security.

Essentially, need to identify the tools that will meet your requirements and then select the one that does this most cost-effectively.

Of course, this is a lot easier in theory than it is in practice. For instance, key decision points like security and usability can actually be pretty tough to assess without sitting down with each individual platform.

Your approved technologies should also include the wider suite of tools you’ll use to support your citizen development efforts. This includes anything you use to manage workflows, visual assets, hosting, usage monitoring, and other related activities.

An effective citizen development governance framework provides clear guidance to users about exactly what tools should be used for different purposes - and why.

Take a look at our guide to choosing citizen developer tools .

4. Vetting, approvals, and sign-off processes

Next, we need to define the specific workflows and processes that will govern how and when users can roll out new tools.

We want to answer a few basic questions here. The most important is determining what criteria we’ll use to decide if a specific app is ready for go-live or not. We can also think about who makes this decision.

For example, does the citizen developer simply publish their tool when they’re satisfied that it does what they want? Or, will the IT team play a role in assessing its functionality, security, or UX?

Will this differ across different departments or different categories of tools?

It’s also important to think about any tools you’ll bring online to codify these processes. It wouldn’t be very efficient if each developer had to email the IT department to ask for sign-off.

As such, you’ll more than likely need to implement approval apps to manage this.

5. Monitoring, auditing, and oversight processes

Similarly, you need to build out governance processes for monitoring usage and success, both in terms of individual tools and your citizen development program more widely.

Are other employees actually using your new tools? Do they find them effective? Are they saving you money?

Is your citizen development program providing value?

Naturally, this is highly tied to the goals you set in the first step. The key thing here is figuring out exactly how you’re going to measure your progress towards these.

Again, it’s best if you can take a systematic approach. Most often, this means providing dedicated dashboards for monitoring key metrics and insights.

6. User admin, lifecycle management, and support

Finally, your citizen development governance policy must cover how your employees’ output will be managed and administered once tools have gone live.

First, we can relate this back to what we said about roles and responsibilities. So, whose job is this?

You should also think about the measures you can put in place to maximize efficiency across these tasks. After all, it’s unlikely that these will be anyone’s primary responsibility.

To a large extent, these concerns can also be built into our choice of platforms.

For example, you can greatly reduce the admin burden placed on your IT team by selecting a citizen development platform that offers free SSO, like Budibase.

Similarly, the greater the homogeneity across your new tools, the lower the support and maintenance burden will be.

(ADT Mag )

Citizen development governance and Budibase

As we’ve seen, the single biggest thing you can do to optimize your citizen development governance is choosing an appropriate app-building tool in the first place.

We’re biased, but we think Budibase is the clear choice, for just about any business. Our winning open-source, low-code platform offers incredible development experiences, without compromising on functionality.

It’s the perfect solution for empowering citizen developers or making your existing dev team’s life easier, faster, and more productive. We offer free SSO, optional self-hosting, customizable RBAC, intuitive design tools, third-party integrations, and more.

Budibase is the perfect solution for creating custom web apps to meet all sorts of business problems.

Don’t believe us? We’ve created more than 50 free deployable app templates to show off what our platform can do.

Sign up to Budibase today to get started, for free.