In this article, we would like to share our learnings in taming the risks that come with multi-year IT projects. Considering when projects of this magnitude go wrong, the loss could cripple organisations.
Managing the risks could raise anxiety when most parts of the process are not easily controllable. Guiding the project smoothly from beginning to completion demands a high level of adaptability in project management.
We’ve broken our learnings into a few sections, listed below:
Agile and multi-year projects
Governance, human resources, and risk management
Responding to change
Contracting
Managing failures
Automation
Trust
Conclusion
1. Agile and Multi-Year IT Projects
Traditional project management and other project delivery techniques dwell on the provision of features. Stuffing projects with unnecessary features is not the Agile formula for de-risking.
Agile simplifies its methodology to rely only on the features that are actually necessary to launch and run. Everything after this should be an iteration on the present offering.
You may wonder how Agile technology takes on complex projects while insisting on the economy of features.
The sooner the launch of a multi-year IT project, the better.
This launch is crucial when the project possesses enough features to provide the intended outcome.
In theory, this seems easy, right?
Build as little as possible to satisfy demand then iterate on what you’ve built. However, when modernising a legacy system this can be difficult.
If this is the case, there are two pathways to take:
A: Firecracker legacy migration - Gather knowledge about the legacy application and use this information to build the new application.
Or
B: Divide and conquer - Divide the legacy systems database out piece by piece until the application is completely modernised.
This can be flexible though. One of our customers has had success using multiple firecracker migrations.
To achieve this, we released a part of the rebuild of their legacy product first. With this release, they got fantastic feedback from key stakeholders. This first firecracker unlocked the next larger firecracker migration.
As we like to say, for it to be Agile, it must be released.
2. People, Governance and Education
The launching of any software demands people, governance and education changes in a company. For large organisations with established structures, these changes may seem challenging and appear to put the project at risk.
However, we have developed and tested strategies that help companies navigate these changes.
These have been summarised below.
People
We know that every project involves people. Allowing stakeholders to buy into the project prepares their minds to make the necessary adjustments it might entail.
To ensure no one is put off or the rug isn’t pulled out from underneath you, the best approach is a top-down and bottom-up strategy.
The Product (Project) owner should be a single person who has control over the project. So, what is their role?
It’s the project owners responsibility to ‘pre-brief’ what the intentions of the project are and allow for C-suite or board consideration to be inputted alongside the strategy and culture they are trying to execute. This will mitigate the risk of the rug being pulled out from the project with a change in strategy.
Once the direction is approved, the product owner should allow for anyone whose teams or processes are going to be affected to put their input in through qualitative interviews.
Once captured, the two can be merged and the product owner should outline the product strategy and gain commitment to the plan from all stakeholders, even if some groups fundamentally disagree.
This will mitigate the risk of people/product fit, or stakeholders working to undermine the project intentionally.
Governance
This tactic involves a meticulous recording of the project and the changes it would necessitate in the organisation.
From experience, one of the issues of software development that put many multi-year IT projects at risk is the lack of adequate documentation to help every stakeholder understand what was done and the changes made to achieve it.
We recommend the following:
Keep a central project space
Document decisions
Monitor contracts and project spend monthly
Record all meetings
Trust your vendors but validate their work and calculations
Education
Ensuring that the stakeholders have access to the software early enough to test it before it goes into production is key.
Offering them access allows them to raise objections and to request specific adjustments to be made at an appropriate time.
This is especially important where customers are already interacting with an existing product. It’s important you don’t give customers access to a raw or unfinished product.
An example of where this has worked well has been using a staging environment. Once the project is in the final stages of delivery, or before it’s moved to product, you can use a staging environment to give all stakeholders early access without going to production.
Using our Dev Ops process we have the following environments available:
- Local – is the local development environment where the developers work with their computed Integrated Development Environment IDE and Codebot. All code is then pushed or pulled from the GIT Repo.
- Beta – is a cloud-hosted environment on either AWS or Azure that enables the latest release of the application to be tested by the product owner. It does not contain confidentially or live data.
- Staging – is a dummy production environment. It should only contain software and data that is being tested as a candidate for production for a wider pre-release test.
- Production – is the live application that is available to all intended users with live information.
3. Responding to Change
Adaptability to change ensures that the functionality of Agile is not tethered within the boundaries of a plan.
The idea of prioritising responding to changes rather than sticking to a plan often raises the question of Agile being reactive. Yes, Agile could be seen as partly reactive. However, this is in recognition of the fact that plans could fail, and when they do, they need to be salvaged.
We do this through a scientific method by hypothesising solutions for what we don’t know based on what we do know. We validate these assumptions through experiments, tests, measurements, and iteration.
For example, one of our customers needed to increase the rate of conversion of their booking tickets. In response to this, we observed the analytics of the end-users in and out of the booking process. We also studied their behaviour and discovered that some of them were confused by the booking process.
We hypothesised that implementing a joyride (fun onboarding walkthrough of the booking process) and simplifying the process would help. We measured a 15% increase in the booking process from that response.
From the scientific process, more information offers more data to work with.
However, to avoid drifting from focus while responding to changes, a strategy that helps Agile immensely is to take every action with the software’s end-users in mind.
In making assumptions, we generate problem statements that consider the business and the end-user outcomes of the hypothesis.
4. Contracting
We know that one of the strategies that go a long way to de-risk multi-year IT project delivery is to carry clients along in the process and to take into consideration the important points in their feedback.
Standing at the other end of the contract, the client is an important stakeholder in a project whose needs make up the basis of our software development.
Based on this premise, we bring our clients into full disclosure through our Scrum process, which offers them an upfront estimate of time and risk.
Despite not being fully Agile, we have noticed that this is one feature our clients appreciate more than the traditional project management techniques.
The key we found is to contract for the estimated time based upon the Scope, but enable variable scope. This enables the team to prioritise the backlog to ensure delivery in a fixed time.
The trade is that not all of the scoped requirements may get delivered, but the ones on the cutting room floor are the lower priority 'should' and 'could-haves', not the 'musts'.
These are the 2 main keys to contracts:
- Fixed time, variable scope
Fixed time, variable scope = Yes
Fixed time, fixed scope = No (this would be considered Waterfall, not Agile)
Variable time, Fixed scope = No
- Product owner prioritisation
Must have
Should have
Could have
Also, we have seen that communicating risk management decisions is more manageable when clients fully understand the scrum process and know what to expect from each project iteration.
Our scrum process involves upfront estimates of projects in blocks and contracting for that block. This upfront estimate offers our clients an understanding of what the project is likely to be.
However, the trade-off in this process is that we must measure our progress based on the estimate.
This restriction adds governance bloat, requiring reports which in ideal situations should be separated from the project. But our clients appreciate the progress reports, which helps the projects cruise smoothly towards accomplishment and change tac as the wind does.
5. Managing Project Failures
We are the first to admit when we fail sometimes.
No contract comes without risk.
However, we take the time to study the reasons behind our failures when we experience them.
This knowledge helps us to effectively de-risk projects by staying alert to the possible causes for project failures when they show up. From our experience, the significant reasons why multi-year projects fail and how to de-risk them are as follows:
Product Ownership
It poses a great challenge when the product owner fails to understand the need or benefits the product’s end users hope to derive from it.
When a product owner understands the business, the development team find it easy to communicate how to develop it.
It’s often the case for people to associate project failure with overshooting the budget. However, the real failure is developing a product that the end-users don’t appreciate.
Product Market Fit
When the stakeholders assume too much about the market or end-user without testing the product to measure how it would be received, it often ends in project failure.
Releasing projects early enough is a strategy for de-risking. The early release allows us the opportunity to gather feedback from the market and adjust where necessary.
Stakeholder Engagement/Education
We learned to initiate every stakeholder on the details of how the project could affect their operation and what our process is.
This pre-information allows them to buy into the project and partake in the decision-making regarding the possible changes before the product is launched.
It is almost impossible for projects to succeed when a stakeholder is actively working against them.
Also, when the stakeholders do not receive adequate training on the project development process, they could engage in actions that work against the project’s progress without knowing it.
Failing Trust
Failing trust from the customer or other stakeholders on the development team creates unnecessary pressure that may negatively affect the quality of the product.
To mitigate trust failing, it’s recommended to provide feedback early and often. This goes both ways. It’s when these feelings are harbored that resentment builds and trust lowers.
Fixed Time
We believe it is only reasonable for projects to have timelines.
However, we have learned from experience that stakeholders should be willing to accept that certain activities cardinal to the software development could take longer than the projected time.
The rigid mindset which project owners have about the project and the subsequent pressure on the development team when they are running behind schedule often compromises the quality of the end product.
Our strategy for de-risking this challenge is to prioritise the development process so that customer pressures do not jeopardise the product’s benefits for the end-user.
6. Automation
The opportunities our customers explore for automation include:
Target Application
The risk in automating projects lies in not knowing what could be automated.
From experience, we have learned that whatever cannot be done manually cannot be automated. There has to be a process for any task to be built into the software.
Automation Development
Repetitive tasks get intolerably monotonous.
We achieve automation development by training Codebots to write repetitive tasks. Handing repetitive tasks to Codebots enables us to speed up the development process for future implementations without sacrificing quality.
This allows provides a standardised platform for modernisation.
As the bots are updated to the latest version of the technology stack, everyone receives the benefit of the update.
This mitigates the risk of parts of the stack or the entire application falling into legacy, e.g., not aligned with the present business process or latest technology set for continued work and security.
Releasing
From the perspective of releasing projects, Dev Ops allows us to automate the stages from code writing to testing and those tests passing and releasing to environments.
DevOps saves us the stress of manually pulling down the old database, uploading the new code, merging, and re-releasing.
Hosting
Our automation of delivery relies on cloud hosting. Cloud hosting enables us to have global availability and makes monitoring easy.
7. Trust
As mentioned throughout this article, trust is one of the key pillars of success.
With trust comes collaboration. One of the biggest contributors we’ve observed to successful projects is the trust both the team and product owner place in each other.
Things will go wrong - it’s how the team responds to the issues that is key.
One of our customers has taught us a lot about this. When something goes wrong, they don’t get angry at us for the issue or assign blame, they want to know the reason why so everyone can learn and ensure it doesn’t happen again.
This has led to the team increasing velocity and also a significantly reduced risk of team turnover.
The key to this is that the customer immediately voices their observed critique or pain point but reaffirms their trust in the team to identify, resolve and learn.
Conclusion
The cost of a multi-year IT project makes de-risking an inevitable consideration from the beginning.
Prioritise flexibility in project management and software development. De-risking is more about having alternatives and ensuring that customers get products that the market or end users appreciate.
Agile methodologies contribute to speed and quality assurance in today’s competitive marketplace. This adaptability is the ultimate risk management feature of Agile that makes it a more reliable option for de-risking a multi-year IT project delivery.
However, you’ve got to be prepared to change and adapt your processes through people first.
Think you've got a project we might be the right fit for? Book a free product strategy session with us today.
