I got an interesting question from one of my students this semester when I was introducing my class to the beauty of the system development life cycle.
After I told them that to be successful, software projects must have a strong business foundation and not simply be a technological initiative, one of them asked me that if it was the case, then why some organizations were getting rid of old technology to replace it with the latest one?
At first, I told myself that my own theory was false, since upgrading old technology was not always a wrong decision, and could indeed motivate a software project. After all, a technological project such as upgrading from Windows XP to Windows 7 (which happened in almost any organization in the last years) is essential to an organization, and yet I couldn’t find a business rationale behind it.
So, is old technology a good or a bad thing?
The fact is that this is not the right question to ask. Old technology can be a good thing (or a bad thing), depending on how it supports business needs and organizational processes.
Too many times, I worked on projects where the main objective was to upgrade any system with a newer one, because it was [too old/unsupported by supplier/insert bad reason here]. And too many times, these projects didn’t meet budget, timeline or business benefits expectations.
Why? Because they were focused on technology, not on business needs. Almost every time, these projects were put back on track by going back to the basics: what problem were we really trying to solve by upgrading the system? To find this answer, I suggest you to cover at least these dimensions (which gave me some results in the past).
Think about your business processes…
People will usually express their needs by asking for a new technology; most of the time, it is only use as a proxy of their problems with their business processes. Their thought is that by replacing their old system with a new one (especially one that is successfully used by one of your competitors), they will become more efficient.
However, implementing a new system without addressing processes flaws is often a key recipe for failure. Your job as a good Business Analyst is to help your stakeholders express their problems and business needs, and not to take their solution as-is.
How should you do that? Asking users about how a new system can help them can bring you an interesting insight on the problems. Using well-known process frameworks (such as eTOM for the telecom industry) can also help you by guiding your stakeholders in their thinking.
… all of them
Even more hardcore system upgrades (such as hardware improvement or Windows updates) hide needs related to business processes. Does your IT department have more support tickets to handle because your system is sluggish (requiring a memory upgrade for example)?
Does your system support team have manual tasks to perform because there’s a missing functionality in your outdated version of the software (thus justifying an upgrade)?
Do your maintenance costs are on the rise because you cannot easily find resources (pieces, knowledge, etc.) to perform maintenance activities? If you struggle to find the real business need, the ITIL framework can help you get a better understanding of your IT services management processes, and identify the real need behind the technology upgrade.
Go back to the root of your problems
Too often, technology is only a symptom of a deeper problem, hidden in your business processes (see above) or somewhere else in your organization. Identifying the real causes behind your problem (starting with a good understanding of your business processes) will help you figure out if upgrading your technology will resolve it, or not.
There are many techniques out there to help you go to the root of your problems. From causal analysis, to Ishikawa diagrams, to the Five Whys (and many others; check the BABoK for more), just pick one and start thinking!
You might find out that the latest functionalities in the most recent software upgrade would not be required at all if you train your users differently, or modify your current processes to bypass your problems.
Validate that new features actually answer a business need
New, shiny things are often very attractive; just look at people waiting in line for days for the latest iPhone to get a proof of this. Unfortunately, this is also the case for many technology and software upgrades. Many HIPPOs promote such upgrades because other organizations are doing it, without checking first if it answers a business need in their own. Bells and whistles can make a lot of noise sometimes 🙂
By understanding your current processes, and the roots of your problems, you are usually in a better position to objectively assess the benefits of new features brought by a technological upgrade. Many techniques can be used to prioritize these features (such as the MoSCoW technique) and get a better grip on the real value of your investment.
By having a clear understanding of the business needs behind your next technological upgrade, you will be able to draw a clearer business case for it, thus justifying more easily the costs associated to it.
From this analysis, it’s now easier to answer my student question: old technology is not necessarily bad; it all depends on whether or not it supports real business needs 🙂
Do you like what you’re reading?
Update (2015-03-19): there’s an interesting discussion going on the IIBA LinkedIn group about this post; don’t hesitate to join the conversation!
Image credits: beglen @ flickr.com
Eric,
As always – a great write up. The one thing that you might want to consider the business value of (and it’s hard to quantify) is technical debt. I’m with you in the sense that a lot of the upgrades that happen just to stay latest and greatest seem like they might be putting more priority on tech than business need, but there’s a real case here for avoiding technical debt. Outdated software often becomes unsupported software, which means it’s left wide open for malicious attacks.
I think my favorite example of accruing technical debt would have to be an Oracle database server. Regularly patching and upgrading those systems is an expensive and difficult annual task. However, NOT doing that regularly results in a monumental project 3 years later (or an embarrassing loss of operations 5 years later).
Thanks for sharing all of these great resources to help us understand if we really do need these upgrades. Great write up!
Bob,
Thanks for your comment! I’m glad you liked the post, and I agree with you. Actually, I think we can see technical debt as a slow degradation of IT maintenance processes performance. If you do not keep your softwares updated, you will eventually need more resources to perform the same activities, therefore increasing your costs (as you explained in your comment).
In the end, technical debt will reflect poorly on your IT processes; this means you will have a business incentive to prevent accruing technical debt over time (and thus justify the software & hardware updates). The only downside to this is that it’s accruing in the long run; it’s easy to postpone one update without any visible impact, then postpone the other, before feeling the real impacts of technical debt.
Eric
Thanks for this! I really enjoy this question being asked and debated online as it is something I think it very important. Often we don’t look at why we implement technology as we just see it is a new shiny tool. I would like to use you upgrading from Windows XP to 7 as an example. Businesses often make the decision just because it is newer without understanding why or why not they should be doing it. I always say that when you present a business case there are always at least two options, the first to do something and the second to do nothing. If you take that view and you look at XP vs windows 7 you can start to understand why you need to upgrade, things like better security, enterprise features. BUT you need to say to yourself, what if we did not upgrade would this have an impact? Will the business be able to deliver better on their core product or service because you implement the new system? When you go with that view to a financial decision maker they think in a very different light. In the Windows 7 case and my benefits you would need to prove that the security was sufficiently compromised or could potentially be compromised to warrant the upgrade otherwise that benefit is not a true benefit.
Ryan,
I think you nailed the tool that most organizations are missing: a solid business case to support new technology implementation. Identifying the business needs driving the new technological choice is not easy, but identifying quantitative benefits is much harder. However, in the end, it will be much easier to convince management with this information.
Thanks for your comment!