Software as a Social Construct
By Evan Terry
When coaching a sports team, you have to know your players and what they are capable of achieving before you can craft a game plan for a successful season. Each player’s skills must be assessed during training camp, and their abilities matched against a coach’s potential plays, in order to determine if the team has a likelihood of being able to execute those plays with any reasonable chance of success.
Unfortunately, too many companies do not realize that the same applies to their IT organization. Although it might first be counterintuitive to think of an IT organization in the same way as you would a sports team, the parallels are striking. Like a sports team, each team member is a specialist, usually hired for a particular skill or type of experience they bring to the table. Interpersonal team dynamics play a role in an IT organization in the very same way they do on a professional sports team.
What makes the parallels harder to see, however, is the mistaken belief that corporate software is entirely a question of “engineering”; that it is based on science, and that IT organizations are groups of technical engineers working on solving technical problems.
In fact, this is very often not the case. IT organizations operate in an environment most traditional engineers would envy; physical realities often don’t play a serious role in the design or execution of projects. Inefficient software designs can be propped up by overcompensating on hardware. When faced with difficult technical challenges, the software’s requirements or design can be compromised. Expectations of reliability and operational efficiency are often low. IT organizations suffer from inertia, difficult personalities, and a lack of standardization as much as other areas of the business. Deficiencies in staffing or organizational structure will be reflected in the final product.
In order to avoid these problems, many companies hire consulting agencies for assistance with techniques, technologies, or skills that are found lacking. This is often not helpful. Elegant designs understood by highly paid consultants are often picked apart and disassembled by implementation staff unwilling or unable to understand them. Sophisticated approaches requiring knowledge of cutting edge techniques are hard pressed to succeed when left to an organization that is rooted in 10, 15 or 20 year old approaches to development, implementation and support. The lowest common denominator of an organization generally governs the solutions that can be implemented within it. A solution out of step with the corporate culture in which it must exist is of little or no value.
Rather than bring in consultants, many companies choose instead to purchase solutions from outside software vendors. This is attractive, since the vendors present a completed solution. However, while possibly successful in the short run, the result is often a silo solution, no more interoperable with the rest of the business than the homegrown legacy systems already in place. Not to mention the risk of folding years of custom-coded business processes into an off-the-shelf software package sold by a company with no understanding of the quirks of your company’s IT organization. A generic solution to a custom business problem is no solution at all.
So how do you avoid these pitfalls? In order to be successful, your company’s IT strategy needs to be compared with the skills and personalities in your organization. Assess your organization’s ability to work effectively in implementing new technology. Which departments are seen as “difficult to work with”? Where are the weak points in your internal governance processes? How willing is your business customer to explore changes to their business processes? Where are the data quality problems and why do they exist? By evaluating the way your organization operates and identifying the areas of difficulty, you will be able to anticipate where new initiatives will be successful, predict which technologies and software tools will provide you with a realized return on investment, and focus your attention on areas that need improvement. Only then should you seriously consider hiring a specialist partner to assist you.
Other points to keep in mind: don’t use technology to resolve organizational or departmental responsibility issues or to address data quality problems. Avoid creating silos of new technology, or implementing tools without considering how they fit into your software and management strategy. Push consulting agencies to show how their solution will fit your organization and ultimately be supported by it. Ensure that software vendors adequately explain how they will integrate their product with your existing systems, not just that they can.
In the end, try to see software as a social construct. Corporate software is constrained by an IT organization’s personalities and governance structures. The usual laws of physics simply do not apply. Just as you would not try to resolve a sports team’s interpersonal conflicts by running a new play, neither should you try to fix institutional IT problems through the implementation of new technologies. Approaching a technical problem using an approach that cannot or will not be accepted by your organization is a certain recipe for failure. A wise coach understands that the best play to run is the one your team can learn, understand, and execute. Most IT departments would do well to take a page from that playbook.
© 2012, Evan Terry. All Rights Reserved.
