Introduction
Once upon a time your computer systems were cutting edge technology. Your IT department was a shining light of innovation and your staff were young and creative. Now your staff are older, wiser, more experienced, and they need to be because the resource pool to maintain and enhance your ageing technology diminishes by the day.
Eventually, there is but one solution, a legacy modernisation project. You could opt to replace your system with a package solution, but would this jeopardise your USP? You could rewrite it all manually, but how long would that take, and at what cost?
So, legacy modernisation it is, and you will be faced with a seemingly daunting task. It could involve replatforming, language replacement, database replacement, data migration, or all of the above!
The Business Case
Within IT the need for replacement is obvious, but creating a viable business case that stacks up against other business priorities can be a problem. License fees may be a factor, as could the cost of remaining on your current platform. A good third party consultancy should be able to help you put together a compelling business case, including ROI in speeding up future delivery using more modern technology, and the potential costs of not doing the modernisation.
The Opposition
The business will have new product launches, regulatory projects, new and enhanced websites and any number of other initiatives that they see as higher priority than a purely IT based project, and that is to be expected. What may be more of a surprise is the opposition from within IT. Your experienced staff, who have lovingly nursed these legacy systems for, in some cases, decades, would rather adopt a manual approach to the whole thing. This manual approach could take further decades, and certainly see them through to retirement, and maybe a little post retirement consultancy. We’ve all come across Bob who sits in the corner, and who is the only person who knows how to fix the creaking batch job that runs for hours overnight, and that stops the entire business when it fails!
However, the complaints should not be dismissed. These are the teams that know the systems intimately. There is probably very little documentation, and the knowledge is primarily inside their heads. You should listen to them, encourage them, and involve them at every stage, because one way or another you will need them.
There will always be the suggestion of additional development that could be achieved at the same time. The argument usually stems from the premise that whilst you are changing a particular module you could add to or amend its functionality. My answer to this would be ‘No!’. You will have enough on your plate just delivering the modernisation, and functionality changes will inevitably increase costs from your technology partner.
The Technical Solution
You will probably come to the conclusion that an automated strategy is the best way forward, using a tool to convert your language / database from old to new. But what is the ‘new’? Your existing suppliers may be able to help, but they will also have a vested interest in keeping you on their technology, which may be a part of the problem. You may already have the technology available within your estate, for instance you are already using a particular language or database, which takes that part of the decision away from you.
Once your technical decision is made, that is the easy part! You will no doubt be able to find some vendors who have done this in the past, and some vendors who maybe have not done it exactly, but have done something similar. But you should not take their word for it. A Proof Of Concept is a very good first step, giving the vendor the opportunity to understand your system, get to grips with the complexities and nuances that are unique to your estate, whilst providing a small part of the conversion. Prior to the POC they should have given you a ball park figure for the entire conversion, after the POC they should have refined this to something that can be written into a contract and your business case. POCs are generally done at cost price, and some vendors may offer it for free! Once you have proven the technical solution you are then into the main execution. This will probably be done in segments or clusters, and in general the technology partner will suggest delivering the simplest first, gradually increasing in complexity as the project progresses. This is a very good approach as it gets the project traction at an early stage. However, you may want to include some complexity in an early phase for your own peace of mind.
Your Team
You reach the point where you have dragged all interested parties to the table, the business case has been agreed in principle, and you are ready to build your project team. On your side this is fairly obvious. You will need your senior technicians, DBAs, Operations, etc. You will need test teams, which we will come on to later, and you will need the business. Although the net result of your conversion project may be that nothing has changed, the ultimate sign off to agree that nothing has changed must be the end users.
Then it gets interesting! You will probably have executed dozens or even hundreds of projects, but legacy modernisation projects are inherently different. You are new to this, whereas technology partners and specialist consultants do it every day. You may want to bring someone on board who has done this before, who can manage your third parties, and even help you to select the right vendor for your particular circumstances. They can guide your decisions and your project manager, they can oversee your test strategy, and advise on additional tooling to monitor performance or manage defects. They will be invaluable in creating your business case, and they will know exactly which questions should be asked when undertaking due diligence with your chosen technology partner or partners. The role of the technology partner is outlined below.
You may be fortunate and have an in house Test Manager and testing teams. If you do not you should look for functional testers who have specific experience in legacy modernisation projects. You should also engage a user acceptance testing team who would work alongside the business users to validate the final product. You can expect the technology partner to unit test their outputs, and you can commit them to supporting functional testing and user acceptance testing. You might also want to consider producing a number of standalone tests that can be executed by your technology partner to form part of the acceptance criteria prior to the start of functional testing.
At this stage you may have a year-long project (or even longer), one or more third parties, your own team of internal and external resources that will all be timesheeted, the usual project documentation, and a number of critical milestones that will drive vendor payments. This is a huge task for even the most experienced project manager, and if you do not generally have a PMO function in place you should certainly consider it for your modernisation project.
One of the most important things to remember about your team is that for the project to be successful every component must be successful. If your technology partner fails, the project fails, so you should give them as much support as possible.
The Technology Partner
Your technology partner should be accessible. All too often they are happy to sit in their office on the other side of the world, joining conference calls and discussing the weather across different timezones. However, working remotely may be alien to your organisation, so they must be prepared to travel as the project requires. It is very rare that a technology partner would need to be on site for any long period of time, but it certainly helps to establish a good working relationship if you have at least looked them in the eye.
Your technology partner may have an impressive portfolio of case studies, but it does no harm, indeed it is your duty, to check them out. Ask your technology partner to provide a list of client contacts that undertook a legacy modernisation project as similar to your own as possible. It may be that your chosen partner uses an ‘any to any’ tool, in which case they may not have actually converted your particular type of database, but they have done some that are equivalent. This means that there will be a learning curve for themselves as well as you. I would not eliminate a vendor for this reason, but you should bear in mind that they will be enhancing their own portfolio whilst executing your project. You should select a reasonable number of contacts, anywhere between three and ten, that you should email them with a questionnaire based on their experience and tailored to your requirements. Questions that you might want to ask include:-
What was the size of your estate?
What was the structure of your project team?
Did you undertake a Proof Of Concept?
Did you consider other vendors?
Was the project delivered on time?
Was the project delivered on budget?
Was there a reliance on one or two key people?
How did defect management work?
Did the delivered project meet your expectations?
What went well?
What went badly?
Would you recommend the vendor?
You can also take the opportunity to gain insight into some of the internal problems that you might face:-
Was there any internal opposition?
How was the project funded?
What impact did the project have on the rest of your portfolio?
How did you structure your team including the split between internal and external resource?
How was it tested?
I would generally recommend around twenty to thirty questions at this initial stage, and once you have gathered responses you should choose two or three for a site visit where you can dig deeper into their particular project. You should ensure that you have both management and technical resource involved in the site visits to really understand the nature of their project, and their engagement with the technology partner.
You should consider the resource profile of your technology partner. They will have one or two key individuals. Are these employed by the technology partner or are they contract resource? Is there a risk that there is no replacement if they are not around?
For database migration projects your technology partner should be able to generate the data migration modules and the i-o modules automatically. This is a huge help to the project in terms of consistency and speed of development. If they cannot do this it casts doubt about their overall capability with this technology.
You should consider the working practice and methodology of your technology partner. If they are agile and you are waterfall, or vice versa, that could signal problems ahead. You should include questions around this within your due diligence exercise.
In some instances a senior representative from your technology partner can be included in your project steering group.
The Test Strategy
Testing a project of this magnitude is always an interesting challenge. As stated above you may want to consider providing a number of test scenarios that the technology partner can execute to prove that their delivered code is fit for purpose. Each cluster will need to be proven before being accepted (and paid for), and to avoid friction further down the line this should be agreed up front. Functional testing is where your technicians can really offer some value as that is their area of expertise. If you are lucky you could even get your systems documented at this stage, but in my experience that rarely happens.
The user acceptance testing can be a real problem, as you are potentially changing every line of code in your estate. Do you have agreed tests? If you do they probably won’t go far enough. The business requirements are simple. The system must do exactly what it does today! Your user acceptance team must be able to evaluate every nuance of a batch job, every path through an online system and every outcome of a web transaction. That can lead to thousands of test cases. You will probably have to consider a trade off between a fully documented and tested system that may elongate your project by a number of years, and a risk based approach where you place an increasing reliance on the accuracy of the conversion, only documenting and testing your most critical functions.
Acceptance criteria are key to a successful testing function, and these can be driven by quality gates into and out of each phase of the project.
Performance is always a concern in a project of this nature, and you should ensure that you have a team that can execute this testing as well as tools to monitor it in test as well as production.
An implementation strategy is vital, and it should be agreed up front so that it can be tested throughout the project. You should consider how to de-risk the implementation by breaking it down into manageable chunks. ‘Big Bang’ should be avoided wherever possible!
The defect management process must be established in advance, including permitted thresholds for each category of defect. Penalties are generally defined for a breach of defect thresholds, but in practice these are rarely invoked. Most vendors will provide a recommended approach to defect management, but do not be afraid to impose your own. This is your project and your team will have an accepted way of working. Defect management tools are important too, and you should be comfortable with the tools in use. I have seen vendors insist on using their own in house tooling, which is an added complexity that you can do without. The challenge should be for them to integrate your defect management output into their own tool, if that is the way that they want to work. There should be no impact to the project’s defect management process because of this.
The Statement Of Work
This is probably the most important document in the entire project. You will have a contract in place with the technology partner, but the Statement Of Work (SOW) is what defines the deliverables, the milestones, the contingency, and anything else that is material to the project. The SOW must be unambiguous, and it must cover all eventualities. Getting an SOW changed mid-flight can be harder than getting it agreed in the first place.
You have probably agreed a fixed price for the project, and you have probably defined a change request process whereby the technology partner can make an additional charge for changes to scope.
However, it is also worth including a buffer fund whereby the technology partner can invoice for a reasonable amount of time and materials for unforeseen situations of complexity or rework that arise in flight. Including this gives both parties some breathing space, and unforeseen situations are extremely common when tackling an entire estate. Remember, if your technology partner fails you fail too!
If you are delivering in a series of clusters then each cluster should be clearly defined, including all artefacts. This could include database tables, data, code, JCL, documentation, etc.
Your technology partner will probably say that cash flow problems are the biggest single issue for them in any project. You should structure the milestones so that they can always stay ahead of the game. Each milestone should have an aspirational date, a value and an acceptance criteria. As stated above this can include test scenarios that must pass for the cluster to be accepted. You should also ensure that the project is not front loaded, and that there is sufficient incentive for the technology partner to finish the job. Milestones associated with the end of functional testing and user acceptance testing are usually included, as is a warranty period that can be broken down into smaller milestones by month. Every milestone should allow for concessions. It may be that a cluster does not pass because of one line of code that is more easily fixed in a later cluster. There should be a mechanism in place to defer this fix without affecting the milestone payment.
Consider where your milestone payments are due to fall, and whether your organisation makes use of ‘payment holiday’ periods, where all supplier payments are suspended during business critical times such as financial year end (yes that really does happen.) The SOW should also include installation standards that must be adhered to, and the compliance with these should be included in any cluster related milestone.
One of the more difficult items to establish within the SOW is the on site / off site presence. You do not want to make demands when it is not necessary, but there are advantages to defining a minimum number of on site days, including the skillset of the on site personnel, for instance, you might want to insist that the technology partner’s technical architect is on site for a minimum of 20 days over the course of a year.
A frequently observed phenomenon during a project of this nature is that on site working engenders a great working relationship as technicians come together. However, the relationship definitely suffers once the technology partner is off site, and the longer the absence continues the worse it gets. A remote technology partner tends to be an easy target!
You should consider the key individuals on all sides of the project. You have Bob in the corner, they have Jim who lives and breathes their tooling. There should be provision to replace Bob and Jim where necessary, and there should be notice periods defined for their lack of availability. So, if Jim is to be off for two weeks the project needs to be given reasonable notice of this. Obviously, illness and certain other circumstances can be excepted from this.
Consider the project reviews that will take place, and ensure that these are documented. Consider also the length of time it may take for a database design review to approve your proposed design (or that of your technology partner.) Bear in mind that this could also affect milestone payments.
The idea of the SOW is to be explicit. There should be no secrets and no surprises.
The Logistics
The project should start with a kick off meeting. The nature of this should be the same whether you are having a POC or going straight into the overall conversion. However, it is a good idea to have a second kick off meeting following the successful conclusion of the POC. The kick off meeting should be on site, with as many people as possible, both internal and external, attending. The technology partner should have already been on site previously to demonstrate their capability. There is no harm in repeating this now. The SOW should be discussed in great detail, and ways of working should be established.
Onboarding can be problematic. How easy is it to onboard people at your place of work? How easy is it to get company equipment, such as laptops etc? You may need to think of this well in advance to get the process in motion.
Other logistical questions include:-
How easy is it to share information?
How will code and other artefacts be delivered to the technology partner, and how will they deliver it back to you?
Do you have the relevant VPNs set up?
Are there any geographical restrictions for your code or your equipment?
Are there any unusual circumstances that you will need to apply for an exception for?
Are there any regulatory issues that need to be considered?
If any of these need to be contractual, include them in the SOW.
Travel and expenses should be agreed across the project. Generally, an estimate of travel and expenses can be included in the project budget, but there should be rules defined to ensure that your technology partner and its employees are not living the high life at your expense.
Test Data / Environments
Test data and environments is a topic in itself that I will address in more detail another time. For now it should be clear that you need functionality available that covers the entire scope of the estate. How is data created? Is it obfuscated? Is there any barrier to giving your technology partner access to it?
Do you have lower level environments available, and can the technology partner use these to execute the test scenarios that are required to meet the acceptance criteria?
How flexible are the environments? Is functionality available to roll dates to test month end and year end processing?
What is the support profile for the environments? If your technology partner is five hours behind you will the environments be supported during their working hours?
Summary
A legacy modernisation project is undoubtedly one of the biggest challenges faced within an organisation. With good planning and controls in place it can be as successful as any other project.
My advice is to break it down into small chunks, manage the scope and always take the path of least risk.
The information above is for a project involving a single technology partner. For each additional partner you add another level of complexity, and risk!
For more information please email enquiries@legacyit.co.uk
