How to De-Risk and Deliver a Multi-Year IT Project


In this ar­ti­cle, we would like to share our learn­ings in tam­ing the risks that come with multi-year IT pro­jects. Considering when pro­jects of this mag­ni­tude go wrong, the loss could crip­ple or­gan­i­sa­tions.

Managing the risks could raise anx­i­ety when most parts of the process are not eas­ily con­trol­lable. Guiding the pro­ject smoothly from be­gin­ning to com­ple­tion de­mands a high level of adapt­abil­ity in pro­ject man­age­ment.

We’ve bro­ken our learn­ings into a few sec­tions, listed be­low:

  1. Agile and multi-year pro­jects

  2. Governance, hu­man re­sources, and risk man­age­ment

  3. Responding to change

  4. Contracting

  5. Managing fail­ures

  6. Automation

  7. Trust

  8. Conclusion

1. Agile and Multi-Year IT Projects

Traditional pro­ject man­age­ment and other pro­ject de­liv­ery tech­niques dwell on the pro­vi­sion of fea­tures. Stuffing pro­jects with un­nec­es­sary fea­tures is not the Agile for­mula for de-risk­ing.

Agile sim­pli­fies its method­ol­ogy to rely only on the fea­tures that are ac­tu­ally nec­es­sary to launch and run. Everything af­ter this should be an it­er­a­tion on the pre­sent of­fer­ing.

You may won­der how Agile tech­nol­ogy takes on com­plex pro­jects while in­sist­ing on the econ­omy of fea­tures.

The sooner the launch of a multi-year IT pro­ject, the bet­ter.

This launch is cru­cial when the pro­ject pos­sesses enough fea­tures to pro­vide the in­tended out­come.

In the­ory, this seems easy, right?

Build as lit­tle as pos­si­ble to sat­isfy de­mand then it­er­ate on what you’ve built. However, when mod­ernising a legacy sys­tem this can be dif­fi­cult.

If this is the case, there are two path­ways to take:

A: Firecracker legacy mi­gra­tion - Gather knowl­edge about the legacy ap­pli­ca­tion and use this in­for­ma­tion to build the new ap­pli­ca­tion.


B: Divide and con­quer - Divide the legacy sys­tems data­base out piece by piece un­til the ap­pli­ca­tion is com­pletely mod­ernised.

This can be flex­i­ble though. One of our cus­tomers has had suc­cess us­ing mul­ti­ple fire­cracker mi­gra­tions.

To achieve this, we re­leased a part of the re­build of their legacy prod­uct first. With this re­lease, they got fan­tas­tic feed­back from key stake­hold­ers. This first fire­cracker un­locked the next larger fire­cracker mi­gra­tion.

As we like to say, for it to be Agile, it must be re­leased.

2. People, Governance and Education

The launch­ing of any soft­ware de­mands peo­ple, gov­er­nance and ed­u­ca­tion changes in a com­pany. For large or­gan­i­sa­tions with es­tab­lished struc­tures, these changes may seem chal­leng­ing and ap­pear to put the pro­ject at risk.

However, we have de­vel­oped and tested strate­gies that help com­pa­nies nav­i­gate these changes.

These have been sum­marised be­low.


We know that every pro­ject in­volves peo­ple. Allowing stake­hold­ers to buy into the pro­ject pre­pares their minds to make the nec­es­sary ad­just­ments it might en­tail.

To en­sure no one is put off or the rug is­n’t pulled out from un­der­neath you, the best ap­proach is a top-down and bot­tom-up strat­egy.

The Product (Project) owner should be a sin­gle per­son who has con­trol over the pro­ject. So, what is their role?

It’s the pro­ject own­ers re­spon­si­bil­ity to ‘pre-brief’ what the in­ten­tions of the pro­ject are and al­low for C-suite or board con­sid­er­a­tion to be in­putted along­side the strat­egy and cul­ture they are try­ing to ex­e­cute. This will mit­i­gate the risk of the rug be­ing pulled out from the pro­ject with a change in strat­egy.

Once the di­rec­tion is ap­proved, the prod­uct owner should al­low for any­one whose teams or processes are go­ing to be af­fected to put their in­put in through qual­i­ta­tive in­ter­views.

Once cap­tured, the two can be merged and the prod­uct owner should out­line the prod­uct strat­egy and gain com­mit­ment to the plan from all stake­hold­ers, even if some groups fun­da­men­tally dis­agree.

This will mit­i­gate the risk of peo­ple/​prod­uct fit, or stake­hold­ers work­ing to un­der­mine the pro­ject in­ten­tion­ally.

A quote block that reads "It is almost impossible for projects to succeed when a stakeholder is actively working against them."


This tac­tic in­volves a metic­u­lous record­ing of the pro­ject and the changes it would ne­ces­si­tate in the or­gan­i­sa­tion.

From ex­pe­ri­ence, one of the is­sues of soft­ware de­vel­op­ment that put many multi-year IT pro­jects at risk is the lack of ad­e­quate doc­u­men­ta­tion to help every stake­holder un­der­stand what was done and the changes made to achieve it.

We rec­om­mend the fol­low­ing:

  1. Keep a cen­tral pro­ject space

  2. Document de­ci­sions

  3. Monitor con­tracts and pro­ject spend monthly

  4. Record all meet­ings

  5. Trust your ven­dors but val­i­date their work and cal­cu­la­tions


Ensuring that the stake­hold­ers have ac­cess to the soft­ware early enough to test it be­fore it goes into pro­duc­tion is key.

Offering them ac­cess al­lows them to raise ob­jec­tions and to re­quest spe­cific ad­just­ments to be made at an ap­pro­pri­ate time.

This is es­pe­cially im­por­tant where cus­tomers are al­ready in­ter­act­ing with an ex­ist­ing prod­uct. It’s im­por­tant you don’t give cus­tomers ac­cess to a raw or un­fin­ished prod­uct.

An ex­am­ple of where this has worked well has been us­ing a stag­ing en­vi­ron­ment. Once the pro­ject is in the fi­nal stages of de­liv­ery, or be­fore it’s moved to prod­uct, you can use a stag­ing en­vi­ron­ment to give all stake­hold­ers early ac­cess with­out go­ing to pro­duc­tion.

Using our Dev Ops process we have the fol­low­ing en­vi­ron­ments avail­able:

  • Local — is the lo­cal de­vel­op­ment en­vi­ron­ment where the de­vel­op­ers work with their com­puted Integrated Development Environment IDE and Codebot. All code is then pushed or pulled from the GIT Repo.
  • Beta — is a cloud-hosted en­vi­ron­ment on ei­ther AWS or Azure that en­ables the lat­est re­lease of the ap­pli­ca­tion to be tested by the prod­uct owner. It does not con­tain con­fi­den­tially or live data.
  • Staging — is a dummy pro­duc­tion en­vi­ron­ment. It should only con­tain soft­ware and data that is be­ing tested as a can­di­date for pro­duc­tion for a wider pre-re­lease test.
  • Production — is the live ap­pli­ca­tion that is avail­able to all in­tended users with live in­for­ma­tion.

3. Responding to Change

Adaptability to change en­sures that the func­tion­al­ity of Agile is not teth­ered within the bound­aries of a plan.

The idea of pri­ori­tis­ing re­spond­ing to changes rather than stick­ing to a plan of­ten raises the ques­tion of Agile be­ing re­ac­tive. Yes, Agile could be seen as partly re­ac­tive. However, this is in recog­ni­tion of the fact that plans could fail, and when they do, they need to be sal­vaged.

We do this through a sci­en­tific method by hy­poth­e­sis­ing so­lu­tions for what we don’t know based on what we do know. We val­i­date these as­sump­tions through ex­per­i­ments, tests, mea­sure­ments, and it­er­a­tion.

For ex­am­ple, one of our cus­tomers needed to in­crease the rate of con­ver­sion of their book­ing tick­ets. In re­sponse to this, we ob­served the an­a­lyt­ics of the end-users in and out of the book­ing process. We also stud­ied their be­hav­iour and dis­cov­ered that some of them were con­fused by the book­ing process.

We hy­poth­e­sised that im­ple­ment­ing a joyride (fun on­board­ing walk­through of the book­ing process) and sim­pli­fy­ing the process would help. We mea­sured a 15% in­crease in the book­ing process from that re­sponse.

From the sci­en­tific process, more in­for­ma­tion of­fers more data to work with.

However, to avoid drift­ing from fo­cus while re­spond­ing to changes, a strat­egy that helps Agile im­mensely is to take every ac­tion with the soft­ware’s end-users in mind.

In mak­ing as­sump­tions, we gen­er­ate prob­lem state­ments that con­sider the busi­ness and the end-user out­comes of the hy­poth­e­sis.

4. Contracting

We know that one of the strate­gies that go a long way to de-risk multi-year IT pro­ject de­liv­ery is to carry clients along in the process and to take into con­sid­er­a­tion the im­por­tant points in their feed­back.

Standing at the other end of the con­tract, the client is an im­por­tant stake­holder in a pro­ject whose needs make up the ba­sis of our soft­ware de­vel­op­ment.

Based on this premise, we bring our clients into full dis­clo­sure through our Scrum process, which of­fers them an up­front es­ti­mate of time and risk.

Despite not be­ing fully Agile, we have no­ticed that this is one fea­ture our clients ap­pre­ci­ate more than the tra­di­tional pro­ject man­age­ment tech­niques.

The key we found is to con­tract for the es­ti­mated time based upon the Scope, but en­able vari­able scope. This en­ables the team to pri­ori­tise the back­log to en­sure de­liv­ery in a fixed time.

The trade is that not all of the scoped re­quire­ments may get de­liv­ered, but the ones on the cut­ting room floor are the lower pri­or­ity ‘should’ and ‘could-haves’, not the ‘musts’.

These are the 2 main keys to con­tracts:

  1. Fixed time, vari­able scope
  • Fixed time, vari­able scope = Yes

  • Fixed time, fixed scope = No (this would be con­sid­ered Waterfall, not Agile)

  • Variable time, Fixed scope = No

  1. Product owner pri­ori­ti­sa­tion
  • Must have

  • Should have

  • Could have

A matrix that shows the relationship between fixed and variable time, scope and quality

Also, we have seen that com­mu­ni­cat­ing risk man­age­ment de­ci­sions is more man­age­able when clients fully un­der­stand the scrum process and know what to ex­pect from each pro­ject it­er­a­tion.

Our scrum process in­volves up­front es­ti­mates of pro­jects in blocks and con­tract­ing for that block. This up­front es­ti­mate of­fers our clients an un­der­stand­ing of what the pro­ject is likely to be.

However, the trade-off in this process is that we must mea­sure our progress based on the es­ti­mate.

This re­stric­tion adds gov­er­nance bloat, re­quir­ing re­ports which in ideal sit­u­a­tions should be sep­a­rated from the pro­ject. But our clients ap­pre­ci­ate the progress re­ports, which helps the pro­jects cruise smoothly to­wards ac­com­plish­ment and change tac as the wind does.

5. Managing Project Failures

We are the first to ad­mit when we fail some­times.

No con­tract comes with­out risk.

However, we take the time to study the rea­sons be­hind our fail­ures when we ex­pe­ri­ence them.

This knowl­edge helps us to ef­fec­tively de-risk pro­jects by stay­ing alert to the pos­si­ble causes for pro­ject fail­ures when they show up. From our ex­pe­ri­ence, the sig­nif­i­cant rea­sons why multi-year pro­jects fail and how to de-risk them are as fol­lows:

Product Ownership

It poses a great chal­lenge when the prod­uct owner fails to un­der­stand the need or ben­e­fits the pro­duc­t’s end users hope to de­rive from it.

When a prod­uct owner un­der­stands the busi­ness, the de­vel­op­ment team find it easy to com­mu­ni­cate how to de­velop it.

It’s of­ten the case for peo­ple to as­so­ci­ate pro­ject fail­ure with over­shoot­ing the bud­get. However, the real fail­ure is de­vel­op­ing a prod­uct that the end-users don’t ap­pre­ci­ate.

Product Market Fit

When the stake­hold­ers as­sume too much about the mar­ket or end-user with­out test­ing the prod­uct to mea­sure how it would be re­ceived, it of­ten ends in pro­ject fail­ure.

Releasing pro­jects early enough is a strat­egy for de-risk­ing. The early re­lease al­lows us the op­por­tu­nity to gather feed­back from the mar­ket and ad­just where nec­es­sary.

Stakeholder Engagement/Education

We learned to ini­ti­ate every stake­holder on the de­tails of how the pro­ject could af­fect their op­er­a­tion and what our process is.

This pre-in­for­ma­tion al­lows them to buy into the pro­ject and par­take in the de­ci­sion-mak­ing re­gard­ing the pos­si­ble changes be­fore the prod­uct is launched.

It is al­most im­pos­si­ble for pro­jects to suc­ceed when a stake­holder is ac­tively work­ing against them.

Also, when the stake­hold­ers do not re­ceive ad­e­quate train­ing on the pro­ject de­vel­op­ment process, they could en­gage in ac­tions that work against the pro­jec­t’s progress with­out know­ing it.

Failing Trust

Failing trust from the cus­tomer or other stake­hold­ers on the de­vel­op­ment team cre­ates un­nec­es­sary pres­sure that may neg­a­tively af­fect the qual­ity of the prod­uct.

To mit­i­gate trust fail­ing, it’s rec­om­mended to pro­vide feed­back early and of­ten. This goes both ways. It’s when these feel­ings are har­bored that re­sent­ment builds and trust low­ers.

Fixed Time

We be­lieve it is only rea­son­able for pro­jects to have time­lines.

However, we have learned from ex­pe­ri­ence that stake­hold­ers should be will­ing to ac­cept that cer­tain ac­tiv­i­ties car­di­nal to the soft­ware de­vel­op­ment could take longer than the pro­jected time.

The rigid mind­set which pro­ject own­ers have about the pro­ject and the sub­se­quent pres­sure on the de­vel­op­ment team when they are run­ning be­hind sched­ule of­ten com­pro­mises the qual­ity of the end prod­uct.

Our strat­egy for de-risk­ing this chal­lenge is to pri­ori­tise the de­vel­op­ment process so that cus­tomer pres­sures do not jeop­ar­dise the pro­duc­t’s ben­e­fits for the end-user.

A quote block that reads "The real failure is developing a product that the end-users don’t appreciate"

6. Automation

The op­por­tu­ni­ties our cus­tomers ex­plore for au­toma­tion in­clude:

Target Application

The risk in au­tomat­ing pro­jects lies in not know­ing what could be au­to­mated.

From ex­pe­ri­ence, we have learned that what­ever can­not be done man­u­ally can­not be au­to­mated. There has to be a process for any task to be built into the soft­ware.

Automation Development

Repetitive tasks get in­tol­er­a­bly mo­not­o­nous.

We achieve au­toma­tion de­vel­op­ment by train­ing Codebots to write repet­i­tive tasks. Handing repet­i­tive tasks to Codebots en­ables us to speed up the de­vel­op­ment process for fu­ture im­ple­men­ta­tions with­out sac­ri­fic­ing qual­ity.

This al­lows pro­vides a stan­dard­ised plat­form for mod­erni­sa­tion.

As the bots are up­dated to the lat­est ver­sion of the tech­nol­ogy stack, every­one re­ceives the ben­e­fit of the up­date.

This mit­i­gates the risk of parts of the stack or the en­tire ap­pli­ca­tion falling into legacy, e.g., not aligned with the pre­sent busi­ness process or lat­est tech­nol­ogy set for con­tin­ued work and se­cu­rity.


From the per­spec­tive of re­leas­ing pro­jects, Dev Ops al­lows us to au­to­mate the stages from code writ­ing to test­ing and those tests pass­ing and re­leas­ing to en­vi­ron­ments.

DevOps saves us the stress of man­u­ally pulling down the old data­base, up­load­ing the new code, merg­ing, and re-re­leas­ing.


Our au­toma­tion of de­liv­ery re­lies on cloud host­ing. Cloud host­ing en­ables us to have global avail­abil­ity and makes mon­i­tor­ing easy.

7. Trust

As men­tioned through­out this ar­ti­cle, trust is one of the key pil­lars of suc­cess.

With trust comes col­lab­o­ra­tion. One of the biggest con­trib­u­tors we’ve ob­served to suc­cess­ful pro­jects is the trust both the team and prod­uct owner place in each other.

Things will go wrong - it’s how the team re­sponds to the is­sues that is key.

One of our cus­tomers has taught us a lot about this. When some­thing goes wrong, they don’t get an­gry at us for the is­sue or as­sign blame, they want to know the rea­son why so every­one can learn and en­sure it does­n’t hap­pen again.

This has led to the team in­creas­ing ve­loc­ity and also a sig­nif­i­cantly re­duced risk of team turnover.

The key to this is that the cus­tomer im­me­di­ately voices their ob­served cri­tique or pain point but reaf­firms their trust in the team to iden­tify, re­solve and learn.


The cost of a multi-year IT pro­ject makes de-risk­ing an in­evitable con­sid­er­a­tion from the be­gin­ning.

Prioritise flex­i­bil­ity in pro­ject man­age­ment and soft­ware de­vel­op­ment. De-risking is more about hav­ing al­ter­na­tives and en­sur­ing that cus­tomers get prod­ucts that the mar­ket or end users ap­pre­ci­ate.

Agile method­olo­gies con­tribute to speed and qual­ity as­sur­ance in to­day’s com­pet­i­tive mar­ket­place. This adapt­abil­ity is the ul­ti­mate risk man­age­ment fea­ture of Agile that makes it a more re­li­able op­tion for de-risk­ing a multi-year IT pro­ject de­liv­ery.

However, you’ve got to be pre­pared to change and adapt your processes through peo­ple first.

Think you’ve got a pro­ject we might be the right fit for? Book a free prod­uct strat­egy ses­sion with us to­day.

Discover Software


David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

What is Agile Software Development: How to Start with a Problem

16 October 2020

The Advantages of Agile Project Management

09 September 2020

What’s the Best Agile Project Management Method For You: Scrum vs Kanban

11 September 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion