End-user developers are everywhere. The key is getting them to work for you.
Know any end users at your organization who create their own macros with Excel? What about folks who keep Web site content fresh by themselves instead of relying on someone in IT? If that's the case, then your organization is among the legions that are home to end-user developers.
Such developers often spring up from necessity: Employees without IT training increasingly need to access and manipulate data, yet they no longer want to wait for IT to provide the tools. For their part, IT people have better things to do than to constantly re-tweak database queries, reformat reports or fine-tune business rules. Now a variety of end-user development tools old and new promise to help both sides.
But before you ask your end users to take development into their own hands (or look to stamp it out as a scourge), there are issues to address, both technical and political. Tossed unceremoniously into their laps, end users may resent the extra work development entails. And for IT, putting tools into the hands of end users can result in problems with data quality, access, security and more. But handled effectively, end-user development can lead to happier lives for both users and the IT people who support them.
Margaret Burnett, a professor of computer science at Oregon State University, defines end-user developers as "end users who create or customize some kind of software so that it works on unanticipated inputs". Classic examples include end-user created spreadsheets, but other applications fall into the category, including e-mail filtering and Web-based tools such as wikis and content management. Burnett says more end users than ever are developing software, and the data that those end-user programs touch is becoming mission-critical.
But rather than being something to fear, end-user development can be a worthy goal - if properly approached. "End users should not only be allowed to develop their own software but be encouraged to do so," says Shawn O'Rourke, CIO at the National Council on Compensation Insurance (NCCI), a workers' compensation information company. At NCCI, IT determines the tool set standard (Microsoft's Office Suite in its case) and provides the necessary training to users. For the most part, NCCI's users rely on Excel spreadsheets and Access databases to manipulate information, including aggregating data on the fly for ad hoc customer enquiries about emerging compensation trends. Yet O'Rourke says the effort to maintain a good end-user to IT balance is ongoing. For example, a user may be a whiz at using a particular Linux-based analysis tool at home and think it would make a perfect addition to Excel. Yet NCCI as an organization doesn't support Linux, so O'Rourke would quell any effort to introduce the idea. O'Rourke says it's not enough for IT to reject tools and explain why, however. To maintain good feelings all round, IT should also suggest a suitable alternative whenever possible.
Easy Does It
It's also essential to keep things as simple as possible. Errors are a fact of life in application creation, but they can become a much larger problem in the relatively uncontrolled world of end-user development. (For instance, various reports have shown that 30 percent or more of all spreadsheets have errors.) To reduce mistakes, it's essential to have an intuitive user interface. In end-user development circles, typical interfaces include "natural-language" programming based on familiar syntax (such as "profit=revenue-costs") or drag-and-drop and pull-down menu approaches. At Romco Equipment, a provider of heavy construction machinery, CFO Craig Burkert uses Quantrix Modeler, a quantitative modelling software, to create financial reports. About a year ago, intrigued by its capabilities to use natural language programming to write financial formulas, Burkert began playing around with the software. Burkert says he now creates models that are less error-prone than when he used Excel.
Burkert uses Romco's intranet to post financial reports for regional managers based on models he creates with the Quantrix software - in the process, highlighting data that wouldn't jump off the screen with Excel. For example, a manager may notice an increase in freight expenses for January that normally might not garner much attention. But if that increase reflects a change in policy, Burkert can easily throw a spotlight on the trends. Regional managers also have secure access to the appropriate models and can manipulate the data themselves using familiar terms such as "gross revenue". With Excel, Burkert had to create multiple spreadsheets for each region and time period, an unwieldy process that invited errors. In addition, says Burkert, spreadsheets created by one person aren't necessarily intuitive for others to use. A tool such as Quantrix, which allows regional managers to manipulate their own views of the data, is a big improvement.
Burkert admits that getting up to speed with the software took some work on his end, and training managers at the company to become adept themselves requires an ongoing commitment. "Most people tend to be comfortable with the applications that they use, such as Excel, so don't underestimate the effort it will take to introduce [a new tool]," he says. As for Romco's IT department, Burkert says they evaluated the software for its performance and the quality of its code, but left to him the final decision about Quantrix's overall usefulness.
That kind of partnership is ideal for end-user development tools. While CIOs such as O'Rourke say it's important to evaluate all tools in the context of an organization's overall IT architecture, it's often the end users who first try a tool and then bring it to the attention of IT. The use of end-user development tools "grows organically at an organization", O'Rourke says. "It takes a lot of interaction back and forth between IT and the business to see that they are deployed effectively."
That's what happened at Isis Pharmaceuticals when the CFO first started playing around with a workflow and data sharing tool from Intuit called QuickBase. Over time, QuickBase spread throughout the organization, and now, it is used for everything from product development to clinical diagnostics, according to John McNeil, vice president of informatics. The object-oriented design of the software isn't something that McNeil himself would have built from scratch because it's not relational technology. Yet the code reuse that QuickBase provides end users has allowed a high quality of programming that McNeil finds impressive.
As McNeil and others see it, end-user development, when done right, bridges the gap between what end users want and what IT ultimately delivers. More often than not, this gap rears its head from the start in the requirements phase of projects. "Gathering requirements - getting them right - is hard," McNeil says. "Most software projects fail at that point, which means in real life, you end up writing software twice." End-user development can certainly reduce the burden on IT, even if end users produce a prototype instead of a working application.
Apptero and iRise, for instance, offer software to help end users mock-up applications, complete with a real application's logic, look and feel, and functionality. Through Web-based (or mock Web-based, in Apptero's case) menus and icons, minimally technical end users can create prototypes and then send them to IT for development. Such tools can be a big improvement over - or at least an enhancement to - inches-thick requirements documents.
Judy McConnell, a senior business analyst at health-care provider Sentara Healthcare, used iRise to create a model of an intranet application to let employees request reimbursement for local travel. She says it was a big improvement over the animated PowerPoint slides that she previously employed to collect requirements, a process that could take days. In a couple of days, iRise created a working prototype for McConnell that demonstrated everything from initial data entry to sending a confirmation e-mail. Using iRise, McConnell could simulate any functionality she wanted, something that proved critical to the IT folks for whom she built the model. And unlike the PowerPoint slides, McConnell could send a working link to others at Sentara to try out the model for themselves.
But there can be a downside to all this simplicity. Tools such as iRise can result in unrealistic expectations for end users who may want to prototype an entire system simply because they can, even if that system isn't technically feasible. For example, McConnell used iRise to prototype an HR portal that would ultimately require real-time interaction with various PeopleSoft systems. But she says links with PeopleSoft proved cumbersome at first (a situation that was quickly resolved, but one that the prototype couldn't anticipate).
With iRise, as with any tool, end users should only focus on the interfaces and navigation, and should leave the back-end connections to the experts in IT. But sometimes end users will prefer that everything be left to IT. As part of the District of Columbia's human services modernization program, residents can apply for health-care benefits via a Web-based application. Currently, developers hard-code eligibility requirements into an iLog business rules management system. But eventually, case workers, social workers and other nontechnical personnel will be able to change specific eligibility figures. So when, say, the US federal poverty income figure changes, it will soon be up to case workers to make that adjustment. Donna Ramos-Johnson, associate director of the modernization program in the office of the chief technology officer, says that developers will be happy to unload these maintenance duties. End users, on the other hand, aren't thrilled to be taking on the job, a conflict that she admits could become a challenge in the future.
Power to the People
But given ongoing financial restraints in IT and the rapid advancements in technology that let end users create powerful applications, Oregon State's Burnett and others say that end-user development activity will only become more prevalent. One interesting tool from a small company called Agent Sheets even lets end users interact with Web-based applications using their voices. But speech recognition (perhaps the ultimate example of an intuitive interface) is not going to factor into wide-scale end-user development efforts for a while. Yet as Burnett of Oregon State says, that doesn't matter. End users will continue to develop their own software applications, and do so in increasing numbers. CIOs and their IT departments had better get used to the idea. Better yet, says Burnett, CIOs should learn to take advantage of end users' do-it-themselves tendencies by helping them help themselves.
Eliminating User Error
When it comes to ensuring that software developed by end users is reliable, CIOs have two strategies, according to Margaret Burnett, a professor of computer science at Oregon State University and project director at a research consortium called EUSES (for end users shaping effective software).
First, CIOs can take advantage of human nature by appealing to people's inherent need for social regard. As Burnett sees it, end users who work on software development collaboratively rather than in isolation tend to instinctively produce a better product, with the idea that doing so will earn them the esteem of their peers.
Mary Beth Rosson, a professor of information sciences and technology at Pennsylvania State University and a EUSES colleague of Burnett, concurs that there's a huge psychological component to good end-user development practices, and notes that making the debugging and testing process more enjoyable is another approach that can yield positive results. "There should be emphasis on making the activities of programming and debugging more fun for the non-sophisticated user," Rosson says. She highlights that games and adding a sense of competition to the process are just a couple of techniques that can increase user motivation to find and correct errors. For example, EUSES researchers are working on a technique called WYSIWYT (for what you see is what you test), a system that colour codes the cells of spreadsheets based on whether the end user has tested the formulas in those cells. As an end-user developer tests formulas, the cells in question turn from red to blue. According to Burnett, the unobtrusive nature of the WYSIWYT approach is one of the most effective ways to entice end users to find and correct errors in their own software programs.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.