olly - Fotolia
Citizen development is inevitable, as the need for software outpaces the professional programming resources available to make it. Companies have worked to support citizen development for over 40 years, from human-readable programming languages to low- or no-code development platforms. But, in that time, enterprises still haven't worked out the issues with the citizen developer model.
There are two models for citizen development output: simple reports and complex projects -- the latter providing more of a challenge. A 2018 survey by CIMI Corporation showed that organizations considered 54% of citizen development projects they undertook to be a failure after the first year, based on at least semi-formal IT audits. Adopters rated another 28% of these projects as having marginal results. Less than 20% of survey respondents said they considered their citizen development projects a clear success.
Enterprise survey respondents listed four primary reasons for failures: poor choice of personnel, lacking guidance, no IT involvement and scope creep. Address these problem areas head on, and it will help shape a citizen developer model that has a higher chance of success.
1. Find the right candidates
Not all non-programmers are alike; some are more adept with low-code tools than others. In the survey, enterprises responded that roughly a third of citizen development candidates actually have a credible chance of success in the role.
It's not only a matter of training, but also staff selection. As many as half of all citizen developers picked from line organizations are "qualified by position," meaning they have a supervisory or management role in the organization that needs the development work. Organizations rarely even know what skills to look for to create citizen developers. One company responded that it sought "someone good at math," which proved to have little correlation with the creation of credible code.
One way to deal with this skills problem is to have IT professionals qualify citizen developers. However, this process is difficult to manage unless the IT organization is actively involved in framing the citizen developer model, from projects to development platform to policies.
Enterprises deprioritize candidate qualifications -- without IT participation -- with the use of no-code development platforms. Some low-code platforms suit citizen developer use cases, but they're generally meant to perform routine tasks for programmers, not support non-programmers. Also, when programmers or non-programmers misuse these tools, such programs tend to expose low-level capabilities that exacerbate all other factors in citizen developer project failures.
2. Put up guardrails
Citizen development projects can easily and unknowingly violate enterprise security, governance and business-case requirements. Line-of-business (LOB) workers neither set nor pay particular attention to IT policies. Thus, these workers are unlikely to enforce these policies as part of the development work. As no-code development platforms gain prominence, such tools open areas of IT where compliance and governance are critically important.
LOB departments that turn to citizen development out of frustration with IT's progress on their projects are especially vulnerable to this problem. Workers' frustration creates an almost institutional rejection of IT oversight, and even a tendency to evade IT restrictions. The best approach is to establish a direct line from internal audit and governance teams to all LOB organizations involved in citizen development.
3. Chum up with IT
IT professionals must coordinate and maintain the framework in which citizen development takes place. Within the successful citizen development projects in the survey, roughly 75% were executed within a technical framework set by the IT organization, some with ongoing IT involvement. Citizen developers should maintain a working relationship with IT -- in fact, it might be the single most critical factor in successful projects.
Organizations must overcome the apathy, and sometimes antipathy, they feel toward IT. The best approach is to establish the citizen development model, including the roles, rules and tools. IT should help with a light touch in project review and approval; project complexity and information-use factors especially should trigger such oversight.
4. Reject the creep
LOB-developed applications usually experience scope creep within the first year, and organizations should often redesign or reconsider them based on the changes.
Enterprises cited scope creep issues like shifting one-time reports into a regular part of operations and deeper application integration with core IT resources to enhance functionality. Some enterprises said the scope challenge was so severe that they needed lengthier IT project reviews when stakeholders proposed enhancements than when they conceived the project.
Scope creep arises because the citizen developer is less likely to carefully assess the right approach to and impact of a change than they are when faced with a whole project. Citizen developers rarely use formal project methodology, and the developers who make application changes might not either, which means a lot can slip through the cracks.
Project management tools can maximize success in a citizen developer model. Most no-code development platforms include project management features, but organizations don't place enough importance on those features when they make a purchasing decision. Also, don't just assume that LOB workers given a no-code platform will use the native project management features -- or any other available system. Enforce project management with proper training, tools and oversight.