Blog

I received a phone call recently from a prospective client who said her association tried online voting the previous year using a system built by internal IT staff, but with their IT services now fully outsourced, and that IT staffer now a former employee, they no longer had access to that system and were shopping around for something new. I sidetracked our conversation long enough to inquire why, with the plethora of options already on the market, did they consider it prudent to start from scratch reinventing a wheel that’s been polished by companies with years of experience specializing in elections. By her own admission, she did not have a good answer. It was something to the effect of, “Well, we had someone on staff already being paid a salary. We thought since we were paying him, we should get our money’s worth and avoid paying an outside company to provide the service.”

That is flawed rationale for many reasons, and while I wish I could say this was the one and only time I’d ever heard of an organization taking this approach, it unfortunately happens far too often, particularly in the association sector.

While the impetus for this article was the above exchange with a prospective client concerning election services, this article’s message is not exclusive to election systems. Any organization, considering any software-based solution to a business need, should think twice before giving the okay for internal staff to undertake development work on things that are already on the market. Among the myriad reasons for this, some are outlined below, then discussed in greater detail.

1. As goes the employee, so goes the system.
2. Poor, if any, documentation.
3. System pales in comparison to best of breed options.
4. Dependence on other systems means a lack of portability.
5. Staff’s attention will be drawn away from other value-producing activities.
6. Breadth of experience breeds excellence.
7. It’s more expensive in the long run.

1. As goes the employee, so goes the system

The perfect example of this is found in the very first paragraph of this article. The one person who understood how the system worked no longer works there! While it’s possible for a system to be reverse engineered, reverse engineering often takes longer and is more expensive than the initial construction! It’s much wiser to partner with an established company devoted to supporting its system even as your own internal staffers come and go.

2. Poor, if any, documentation

Generally a person involved with developing a system should never be involved with writing the documentation for it. He/she is too close to it to understand what needs to be spelled out clearly in the documentation, and writing coherent, easy-to-follow instructions in plain English is an entirely different skill than understanding how to architect and develop software. Therefore, even if an in-house developer were to take the time to write documentation, it’s unlikely to be useful to a successor—though there can be exceptions. Writing is a skill unto itself, and technical writing is a specialized niche underneath that that is best left to the companies with an interest in making the investment in doing right.

3. System pales in comparison to best-of-breed options

This should not be taken to mean that all the good developers work for software companies, and the rest elsewhere. There are many non-software organizations with very capable developers on staff. But what is meant by best of breed, and why is it nearly impossible for internal staff to match it on their own? Among other things, it means:

• No matter what is thrown at a system, that system will hold up and handle it elegantly, and most definitely not be brought down by it.
• It will be backed and built by a company focused on doing one thing better than everyone else. Every workday they will talk about enhancing the system’s capabilities and value. Will your internal developers obsess over every detail of a single system? No, they will aim for adequate; complete the build; and move on to whatever is next. Not because they’re lazy, because they have other things competing for their attention and they can’t afford to put the same sort of effort into a system that a company dedicated exclusively to that system can.
• Money’s a powerful motivator. Internal staff is paid on salary and as long as they perform well, will continue to make the same salary going forward regardless of how many bells and whistles they add to a system. But for-profit companies are driven by competition and their own desire to survive. A little extra investment in usability, or some value-added feature, could mean the difference between winning and losing clients. For the in-house developer, this motivation doesn’t exist.

4. Dependence on other systems means a lack of portability

When a system is developed by internal staff, it will be developed to operate in the technology ecosystem in place at the organization at the time. Eventually that ecosystem will change and the system will need to change with it. That could be costly and time-consuming. It makes no sense for staff to develop a system capable of porting across multiple systems. The cost is too high. However, specialists need to develop their system from the outset to serve as many clients as possible, which means working in numerous different technology ecosystems. This means your organization may make all the changes you desire to your own technology ecosystem without very much, if any, disruption to a specialized piece of software provided by a vendor.

5. Staff’s attention will be drawn away from other value-producing activities

Developing a specialized system can become a major time sink. First generations of systems always need to be revisited. Either to correct things that perhaps weren’t thought all the way through initially, or simply to make enhancements that come up after having lived with a system for awhile. Either way, the person(s) doing the developing will likely make better use of his time:

• Attending trade shows to keep up to date on the latest developments in his profession.
• Simply surfing the web to review the many options already available to do what his organization wants to do.
• Taking full advantage of the trial accounts available for so many systems.

6. Breadth of experience breeds excellence

Companies dedicated to providing a service are going to provide it across a broad range of clients. That presents a broad range of challenges and over time, as those challenges are met, the service matures, becomes more flexible, more feature-rich. In a word, better. See Vertical Versus Horizontal Election Providers for more.

7. It’s more expensive in the long run

So the notion that you’re not getting your money’s worth from on-staff developers unless they spend their time developing should be fully debunked by now. But in the event further points are needed, consider that:

• Soft costs, like staff time, are still costs. If a best of breed system can save staff time, it’s probably a better way to spend money, rather than paying internal staff to build and maintain a custom system.
• Your organization’s brand has value. A mature system that operates reliably and intuitively in the eyes of the end users—often the members of an association or customers of a business—reflects well on your organization’s brand. What is the cost to your brand when a less evolved, homegrown system causes end users difficulty or simply a less elegant experience?

Conclusion

I’ve seen large organizations with large budgets using clunky, homegrown solutions. What do the smaller organizations with smaller budgets do? They shop the market for solutions. They have no choice; their budget won’t permit them to hire the sort of talent that could develop solutions in-house. The irony is that the smaller organizations can often run the more technically advanced solution for all the reasons stated above! This hasn’t always been the case. In the 1990s and even early 2000s, the vast array of solutions available today didn’t exist. If an organization wanted something specialized, it may have actually made sense to hire consultants to do a custom build, or even hire internal staff to do it. Walking on Mars, for example, will still require some systems that have yet to be developed. But for common business needs, and even some that aren’t so common, there’s probably a solution already available no matter how specialized it might have been a decade ago. Would you ask internal staff to create a social network from the ground up? Of course not. You aren’t going to out-Twitter, Twitter.