Most technical problems have no shortage of technology solutions. Sometimes there is a clear winner, but it has been my experience that more often, multiple good choices are available. Some of the choices have specific attributes that are favorable, but rarely is one choice a clear winner.
Sometimes team members may have opposing objectives. For example, part of the team may define its success as quickly delivering a solution. Another part of the team may define its success as efficiently operating what was delivered. A solution that favors quick implementation may present a challenge for efficient operations.
In August of 2006, Gartner published an article entitled, “To Save Time on Product Selection, Flip a Coin.” The author argues that the product selection process should first focus on:
- Understanding which options are good enough from a technology standpoint
- Eliminating technologies with fatal flaws
- Choosing from the technology-safe choices using factors such as existing skill sets, infrastructure, and business relationships
After you've done this, if there is no clear winner, says Gartner, flip a coin instead of getting bogged down in more detailed analysis. While I don't see the Church making major decisions using a coin flip, the article provides an interesting counterbalance to the idea that technology decision-making is purely analytical.
It should be no surprise that an organization the size of ICS will end up with different project teams selecting different technologies. Assuming the department has been competent enough to eliminate technologies with fatal flaws, it is reasonable to assume any that "good enough" technology can be successfully implemented—this is basically the premise of the Gartner article. Unfortunately, it may be hard to succeed if, over multiple projects, all of the technologies are chosen. To help manage this risk, we’ve created guiding principles that in turn are used to create standards.
When identifying our department's guiding principles, we assumed that we didn't have to state the obvious. Principles such as being smart, honest, hardworking, and cost sensitive didn't make the list—not because they were not important but because there wasn't an interesting debate about them. The focus was on principles for which there might be plausible arguments both for and against. For example, a company could have as a principle that they favor mature technologies and vendors—and they could succeed with that. Another company could succeed using a strategy that favors innovative and new technologies and vendors.
We then created a set of these balance questions and worked with the ICS senior governing councils to figure out where our department should be. The following principles came out of this process:
- We strongly favor mature technologies and vendors.
- We prefer acquiring software over developing it ourselves.
- Internal development should be focused on business processes that are unique to the Church.
- We prefer acquiring complete solutions over integrating best-of-breed components.
- We avoid modifying acquired software.
- We prefer solutions that adhere to industry standards.
- We prefer solutions that provide uniform functionality and services world-wide.
Choosing technology standards carries all the hazards discussed earlier and adds a few more. We must balance the needs of each project over the full application lifecycle as we search for a solution that works across all of them. As we try to find the best solution across all projects, we may have to accept suboptimal solutions for some or possibly all of the individual projects.
In ICS, we have tried to strike this balance by creating the ICS Technology Menu.
When I go to a restaurant, I accept the fact that I generally can’t select something that doesn’t exist on the menu without creating some level of increased inefficiency and cost. As a general rule, when eating out we are able to make choices, but these choices are limited by what is on the menu.
The Church’s technology menu attempts to document the set of standards from which project teams can choose:
- Emerging technologies are new technologies that we find interesting but have not committed to.
- Provisional technologies are technologies that we plan to adopt. Projects can use provisional technologies if the team has received approval from the Chief Technology Officer. However, these technologies carry some risk because we may not have created a full organizational competence around them. Restricted use of provisional technologies gives us a chance to dip our toes in the water before jumping in with both feet.
- Strategic technologies are the workhorses for project teams. Strategic technologies are fully supported by the organization and generally can be used without further oversight.
- Contained technologies are those technologies which are in production but are no longer strategic. We actively and passively try to eliminate contained technologies, either through targeted replacement or simple attrition. New projects are not allowed to use contained technologies.
The ICS Technology Menu has now been in use for several years with mixed success. Besides the decision-making pitfalls described here, some simple execution challenges get in the way. Things like keeping it up-to-date and accurate are often set to the side when the organization gets busy. Occasionally, teams feel they cannot succeed with the technology options available to them, and we enter into a state of prolonged debate. At times, the menu doesn’t contain enough information to adequately guide a project team’s decision.
Despite its flaws, the ICS Technology Menu is providing much-needed structure within the organization. We intend to continue investing in creating and documenting standards. It is our belief that although standards may constrain the field of technical options, they have a reasonable upside: they limit risk and can increase efficiency, both in making decisions and maintaining the various technologies. Thus, standards can help us make choices that are both responsive and responsible.
Peter Whiting is the Chief Technology Officer for ICS.