We regularly read headlines about the failure of major IT projects. Despite using the latest methodologies such as agile working and devops which promise to ensure projects stay on track, spectacular failures still occur. There are also many more major IT projects which are delayed, run over budget, or fail to deliver the promised ROI.
As IT companies we clearly have to shoulder much of the responsibility for ensuring that projects are successfully delivered. We have to scope the work thoroughly once a contract has been awarded, align roles and responsibilities appropriately, and ensure we have appropriate escalation processes in place to manage any issues that occur so we can resolve them before they have a serious impact on delivery.
However, there are two sides to any IT project, and the customer also needs to play their part. If they cannot provide a firm foundation for an IT transformation, it will run into problems further down the line. In more than 25 years managing infrastructure and cloud projects, there are four issues that can make or break even the most thoroughly planned IT project.
1. Have a project sponsor with the influence to push things through
Every major IT project requires a sponsor – but not all sponsors understand what their role involves or have the ability to drive the project through. To be successful, they should have the seniority and influence to champion the project within their organisation and the time to be actively involved. Most organisations will be working on multiple change projects concurrently, and if the sponsor cannot make their voice heard, particularly at critical times, their project will struggle, be delayed or even abandoned.
In one organisation, we were working on a project that involved making changes to the payroll systems. The organisation was also implementing Making Tax Digital. With appropriate negotiations and planning, both projects could have been delivered successfully. However, our sponsor did not have the influence to explain why our project was required and to convince the organisation of its benefits, so to avoid perceived disruption it was simply shelved.
If the sponsor sees their role as being a figurehead, and is not prepared to get actively involved, they cannot be effective. It’s important that they understand what the role involves and have sufficient time available for the duration of the project.
One straightforward and very effective way in which a sponsor can get involved is through leading on project communications. This ensures that they are seen to have their name on everything whilst demonstrating to their organisation that they are serious about the project.
2. Know your stakeholders
A complex project will have multiple stakeholders across different departments. It is vital that an organisation involves all of them all from the beginning and obtains their buy-in to all significant decisions. Fail to do this and you may have to make significant changes part-way through when it becomes clear that what is planned will not meet everyone’s needs or expectations.
In one recent project, our team was working alongside our customer and subcontractors to develop a detailed network design. When a critical link that was due to be upgraded kept failing, the project was put on hold so that this could be stabilised and a revised configuration was agreed. The organisation then decided to bring in another department which had not been directly involved in the design process. This new department had very different resilience and failover requirements which came to light when working out how to test different failover scenarios. Their colleagues had simply not understood these requirements when drawing up the initial design, and so had not incorporated appropriate resilience. As a result, a third design had to be developed.
3. Manage risk appropriately
Some organisations are more risk averse than others. This is frequently for historical reasons – perhaps their last upgrade did not go smoothly or was unpopular with their users. For others, the nature of their business means that they cannot afford to have a critical business system down for more than two hours, and they fear the impact of planned changes. Upgrading Active Directory (AD), for example, should not impact critical Line of business systems, but if an organisation’s past experience has been that connectivity was broken when upgrades to AD were implemented, and hence critical information (e.g. payments) were disrupted, they are likely to be highly risk averse when considering future changes, even to the simplest components.
IT providers will address this through creating a risk register at the beginning of a project. However, if an organisation does not acknowledge its appetite for risk and have an open and honest discussion about its concerns so that they can be addressed, problems can occur at a later date. It is also vital that the project sponsor buys into whatever is agreed.
Problems can also arise from ‘snipers’ who raise objections at a late stage based on information which has not been shared, so it is important to try and surface all potential risks at an early stage. For example, we were working on a project to migrate email to a new system and install an identity management system to provide an authoritative source of identity. After a considerable amount of testing, we were ready to migrate the first 200 users. The day before the migration, one of the customer’s IT team told us that the old mail system relied on having a middle name as well as first name and surname – a dependency which they had not thought necessary to reveal earlier, despite working on the project for some time. As the middle name was not being parsed through the system and not tracked as a critical element, the whole project had to be re-defined.
4. Document your iceberg
A poorly understood and documented starting point is perhaps the biggest potential pitfall for any IT change project. It is vital to know as much as possible about the existing environment and any dependencies before making changes. Ideally, a supplier needs complete and unfettered access to the areas that will be impacted. However, many organisations provide incomplete, inaccurate or limited information, and there may be third party suppliers involved who are unwilling to share their knowledge. We have gone on site and been asked to fix things that have never worked but which IT were unaware of or had not documented.
However detailed a supplier’s due diligence, organisations who provide incomplete information are in effect asking their supplier to work with one hand tied behind their back. As a result they risk major time and budget overruns.
Being prepared saves time and money
Every major IT project will have its own challenges, and even with the most extensive planning, the unexpected can still occur. However, if organisations understand their responsibilities and put these four things in place, they significantly increase their chance of success.
Drew Markham, IT strategist, Fordway