In my previous post, I talked about the benefits of having a skunk works of federal developers. How can this team help with your Commercial Off The Shelf (COTS) software choices? Your internal development team cannot (and should not!) build every piece of software you need. They should focus on unique, mission specific processes that general tools cannot satisfy. For common office functions, the commercial and open source worlds have rich options to solve your needs. Developers can help you make sustainable, well-informed decisions. Especially if you are using open source products, this arrangement helps ensure that the quality of code you get is equal to the quality you purchased.
Notice I said “the quality you purchased” and not “the quality you asked for”. This is another key area where having skilled developers on staff can make a huge difference. People in the business lines, don’t really know what to ask of IT. Teams meet and have discussions to get a general idea of the problem. Then the tech folks rush to recommend a technology or a tool that will fix everything. Then these vague ideas are recorded as requirements for the contractor or product. So, the best you can hope for is “the quality you pay for”.
The idea is save money by using COTS. However, unless the organization modifies its workflows to match the COTS product, then expensive customization is required. This gets expensive fast. Often organizations cannot adjust their complex processes and regulations to fit the COTS (often commercial focused) processes. Thus, saving money has two paths: either go COTS and adjust your processes or build custom software as cheaply as possible (like with your skunk works team).
For best results with customizing (either home grown or COTS customizations), involve a skilled developer early. A skilled business analyst can work with a developer to document the level of effort for features (like between implementing a drop down versus a type ahead suggestion field). Then the technical team can answer questions like: How much more effort is this? What is the real benefit to the end user? Is the trade off worth it? These seemingly small decisions can become huge problems downstream if the business line and IT focus on software features rather than the underlying work processes.
In another example, open source and Big Data initiatives exacerbate the need for skilled developers. Not many agencies have data scientist skilled in R programming to wade through data analysis. Thus, the task falls to developers more comfortable with general tools such as Python and Hadoop. If you don’t have members of your team who can craft a solution using the available technology tools, then you risk wiping out on the Big Data wave instead of surfing it.
So, I say, find the code slingers in your organization or hire them. If not, then look to innovation factories like GSA’s newly minted 18F group to help you. Find small, skilled teams of business analysts, project managers, coders and testers. Let them find business problems. Give them the freedom to build creative solutions. This small expense will reap huge benefits in efficiency. Your business lines will love your services. It just takes patience and the willingness to break from the norm.
- NOTE: All views and opinions are those of the author only and not official statements or endorsements of any public or private sector employer, organization or related entity.
Chaeny Emanavin is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.
Gartner has been pushing an idea called the “Pace Layer Model” [drdobbs.com] that tiers applications into one of three groups depending on how quickly the business requires the application to change. Essentially, your applications are either systems of record (annual changes), differentiating/LOB apps (quarterly changes), or innovative/experimental (monthly, weekly, or even daily changes). It’s not uncommon for organizations to make a category error in their thinking and try to apply the wrong tools (like COTS packages) to the wrong layer.
Yes! This is what I had in mind when I wrote this. I didn’t realize Gartner had research out already. That is exactly it. You run into issues when you apply the wrong tool (COTS, home grown, etc) to the wrong layer. You must have the flexibility to make the quarterly, annual, daily, whatever changes, so the tool must be as flexible as you need. For highly volatile apps, like for a business line that isn’t sure what they want or you’re trying to innovate, you need to be a flexible as possible.
Thanks for your comment!