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