It is amazing what people can do together. By marshaling resources, leveraging each person’s talents and experience, virtually any technical data communications challenge can be met and overcome.
However, it is exactly this strength that can lead to an amazing weakness: The creation and reinforcement of the design, engineering, and deployment of a “Self Licking Ice Cream Cone” or SLICC for short. Defined, a SLICC is product or service that works as designed, but misses the mark on customer requirements, cost, operational improvements, or are technically obsolete when deployed.
SLICCs are not created on purpose, but in the government and even in the commercial world, they are produced sometimes two scoops at a time. What causes this? What causes smart and experienced people to create these generally expensive but less effective products or services?
In general, it all starts going off track because of the “second system effect”. This effect, coined by Fred Brooks, product manager for the somewhat ill fated IBM OS/360 project and author of the book “The Mythical Man Month”, suggests that after developers are successful in creating their first system, the same team may fail spectacularly on their next or “second system”. In short, Brooks concludes that the second system retains concepts from the first system and also includes all the items that they were not able to include in the first system.
Thus, the requirements of the system become can be driven based on the legacy systems, concepts, and the opportunity for engineers to focus on what they were not able to do previously. Instead of looking at current trends and customer requirements, the Project Managers and others dutifully monitor the progress of the developers to ensure the SLICC comes in meeting requirements and on-schedule. Unfortunately, these requirements may be inward focused, not what the market or internal customer really needed. Cynically, sometimes these requirements are put in place to ensure long-term employment for the organization.
Most of the time, commercial companies have two different mechanisms that are supposed to avoid or mitigate the effects of a SLICC. The first is a proper Product and Marketing organization. Functioning correctly, these groups are responsible to understand the marketplace for their products, including technical, operational, and pricing requirements needed for market success. For well run companies, even if Product and Marketing makes mistakes, test introductions (especially Internet-type betas) enable changing the product to meet customer needs or removal from the market to cut losses.
Unfortunately, many times in the government environment, there is no marketplace pressure. Projects are created to provide “technology insertion” or “technology refresh” to existing systems. Unfortunately, as indicated above, in many cases the same team that implemented the current system will be in charge of the new project – a “second system”. Through no direct fault of their own, they will see this as the opportunity to improve on the previous system and introduce features they could not previously deploy but potentially missing the mark on the end-to-end improvement from the customer’s perspective. In the end, they create a SLICC.
How can this be avoided in a government controlled network infrastructure? In spite of not having a direct competitive marketplace to provide pressure to move products and services towards success (other than relative budget reductions) it is possible to create an environment that provides a good facsimile. The organization’s equivalent of a Product Manager, the Enterprise Architect needs to do several things:
- Interact with end-users of the services to understand what problems they are encountering end-to-end and what is limiting their ability to be successful and meet their customer’s needs
- Understand that the technology and services being developed and deployed are most likely not unique to the government and needs to reach out to companies providing like services and understand their approach
- To make up for a lack of direct marketplace, the Architect must develop a target set of parameters that a new service must achieve
The key parameters to success must include functional, operational, and costs components so that any develop product or service is measured not against the government’s existing technical and operations approach but against commercial analogues. For example:
- What is the technical cost for moving a bit end-to-end in the network?
- What is the technical cost for increasing the capacity of the network?
- What is the engineering effort required to provision a new customer requirement
- What is the operations effort required to provision a new customer?
Too often, the comparison for a “technology insertion” or “technical refresh” is relative to the current government baseline approach. This leads to an expectation that a 10% or a 20% cost reduction is a great accomplishment. However, when compared to commercial technical and operations practices, the current approach may be several factors more costly. Only by realizing this fact, is it possible to take a comprehensive view of making significant changes to the technical, operations, and business approaches of a system and being able to realize much larger cost savings.
