Build using what others have done
Technology must advance and change to make a difference in an organization’s performance. Software becomes easier to use. Hardware becomes faster. Incorporating those advances raises productivity. The challenge is how to build the changes into the IT services structure.
I have experienced a frequent and expensive strategy. It is a nasty and widespread tendency to disregard using what others have done. This is especially noticeable in new IT team members.
Why propose replacing rather than modifying what is already in place? The dominant reason given: replacing it is faster. The truth behind proposing replacement most often comes from technological bias rather than speed. Almost always the complete replacement is not quicker or cheaper. The organizational impact cost wrought by the technology flip can be much higher.
Most IT professionals were drawn to a technology career because technology brings an organization that which is new. We like making things better. We especially favor using what we have done and used before. Doing what you’ve done before feels faster and less risky. You KNOW how long what you did before took. Working with what someone else did is a vast unknown.
It has to do with working from a comfort zone. Proposing a complete replacement as a solution to move to a technology that an individual knows well feels comfortable to the individual. In the process it pushes the organization out of what is familiar. Examples of the individuals who are the change proponents are someone new to the organization, or a current team member enthralled with a new technology passion.
As a rule, extending or modifying what you already have gets what you want quicker and cheaper. How to select modify or replace is driven by balancing the cheap-fast-good mix of options.
Cheap
One of the costs of ‘modify versus replace’ can be straightforward. The comparison may be the amounts necessary to continue the current solution versus its replacement cost. The organizational cost of modification versus replacement is both subjective and contingent. It is measured in work disruption. The more changes are required, the more likely there will be disruption. An error-free implementation may well be invisible to end users. The organizational cost of that happy outcome is zero. Yet the option with more changes is the more likely one to become visible as disruption. The less changes, with the least number of affected users from a change, the lower the risk of disruption.
The seven step ITIL Continual Improvement Model focuses on the organizational cost when asking ‘where a we now?’ . In performing baseline assessments, it does not favor modification or replacement. Neither does the ‘Where do we want to be?’ step. When moving to answer ‘How do we get there?, the model moves into the practice of Change Enablement. Change enablement includes ‘ensuring that risks are properly assessed’. There’s a reason why ‘Change’ is in the practice name focusing on risk assessment. It is these ITIL risk assessment practices that help determine the likely organizational cost or modification versus replacement.
The calculus supporting the better option is bound by the cheap-fast-good math. Complete replacement usually has more changes, and changes with a much larger impact footprint, than modification. Augmenting existing solutions usually has a lower organizational cost. Building a new service with what others have done lowers the disruption risk and potential organizational cost.
Fast
Time requirements when implementing any solution are:
- Learning the particulars of the current solution
- Learning the supporting technology (whatever parts aren’t already familiar)
- Development
- Testing
- Implementation
- End user and support training
Modifying the current solution requires that you figure out what the last guy, gal, or lineage of guys and gals, did. That takes learning time. Replacing a solution requires that you only learn what the current solution does. You then map the requirements onto your preferred technology. You’ve probably done this before. Complete replacement wins this learning the particulars race.
What needs to be modified may use a technology which isn’t your strength. That increases the learning time. The familiar solution proposed as replacement may not require any learning time other than brushing up on parts relevant to meeting the requirements. Another time win for complete replacement.
Maybe the current solution uses a technology which isn’t one you like. If it isn’t your preferred technology, learning the technology seems onerous. Nothing worse and more difficult than learning a technology which is not your favored and/or familiar solution. The burden of learning a hearsay to the true faith becomes heavy and grows learning time. Yet another time win for complete replacement.
Proposing a solution that involves moving to a technology about which we know a lot more increases our value to the organization. It reinforces our faith in the solution we already know. It reflects the belief that ‘anything not using my preferred and familiar technology can’t be a good solution’.
While we sometimes go for something we’ve never done before (risky), we usually want to extend what we already know. It is safe and it, on the surface, seems to be a faster solution. Faster, that is, than learning and using what is already there or a solution that can be acquired.
Development is where the time balance may begin to swing away from a replacement option. Much depends on the number of touch points with dependent systems. Dependent systems include other applications and the hardware environment. The technology to be modified usually has all of this in place. Replacing the solution with a new technology may require working out how to integrate it. In the switch to the familiar solution, the time required can be estimated – but it still takes time. The integration time is usually minimal when modifying the existing solution. This time requirement favors modification over replacement.
Like development, the testing time requirement is driven by the number of dependent system touchpoints. The existing solution should have a set of well-established tests. Replacement requires building new tests. The more touchpoints, the more tests needed. Modification claims the time advantage.
End user and support team training may be extensive with replacement. Let’s assume a change requires the end user to use the application differently. . Whether modified or replaced, the training time is generally less for a modified solution. The IT support team may be looking at having to expand their knowledge to troubleshoot and maintain a replaced solution. Modification usually wins in the training time requirement match up.
Summary of time cost
Good
In many cases, the ‘where we want to be’ is the same for both modify and replace options. Swapping out the backend technology with a ‘replace’ may look exactly the same to the end users. A visible change may be only the addition of a new user-facing feature which would look the same with either option. In those instances, the ‘Good’ value of the change would be the same.
Sometimes replacement introduces a new technology that will enable new capacities and solutions. The proposed change may do everything the current system does. The replacement may enable future changes that are not be possible or easy with the current solution. With a nod to technology bias, it may open up the using the deeper knowledge base of the person proposing the replacement. The future capacity would be the ‘Good’ to be factored into modify versus replacement selection.
There are watch-outs in bowing to future capacity or past knowledge of the person proposing the replacement.
For future capacity, you need to factor:
- the likelihood of using the capacity. Are there specific projects this addresses rather than an amorphous ‘it would be good’.
- whether the replacement adds a service rather than replace one. If you would end up with the new technology and still have to support the one which it partially replaces, you’ve increased support cost.
- how it plays with the rest of the system. Hopefully this was considered as part of the organizational cost assessment.
Selecting a replacement to suit the knowledge and bias of the person making the proposal can be dicey. The individual proposing the replacement is the usually the sole source of knowledge for the replacement technology. That is likely to remain that way for a while before the rest of the team learns to use it. If that person leaves the organization, you may be stuck with an difficult support situation. Going back to the original technology may not be possible. It may also be costly and embarrassing.
If you do gamble with replacement and onboarding a knowledge set invested in one individual, be sure that the replacement technology can be supported by third parties while the team learns it.
Building Using What Others have Done
The reality of cheap-fast-good generally favors modification, extension and re-use. In most cases those options support the lowest total cost of ownership. This inclination away from replacement runs head-on into the technology bias of IT team members with different favorites than the current infrastructure.
Yet there are times when replacement IS the right choice. In that instance the technology bias of the existing IT team creates an inertia against replacement. In those cases, making the changes small and quick provides a means to make the replacement.
