Technical Project Resources

Common IT Project Risks

The information in this guide is intended for general purposes only. For more specific guidance around your organisation’s projects, please get in touch with our team.

In this section, you will find:

In our work as technical assurance providers, we work with project managers and tech professionals to identify and manage risks every day. As a quality assurance provider that works across all projects from corporate to infrastructure, people to technology and everything in between, we’ve come to learn that the risks in IT are often made up of many more small factors that, combined, can create a real problem for the business if not adequately managed. When we consider what organisations rely upon technology for – payments, financial information, health information, personal information, connecting systems, automation and so on – it’s easy to see why the risk aspect of IT projects is treated with such priority.

So what are the most common IT project risks? This is actually quite a hard question to answer as the field of information technology and digital projects vary greatly. In this guide, we’ll aim to surface some that we see apply to many technology projects we provide assurance services for, but you should always make sure your project or programme is receiving ongoing assurance and risk management specific to the variables in your business and the project activities. If you need help with technical assurance on your project, get in touch with our team, and learn more about what we can offer.

Out-of-scope feature requests

Out-of-scope feature requests

Developing a technology-based solution requires careful planning and attention to detail around the development and design of each component. While modern-day Agile development methodology encourages continual feedback and refinement, it too must be subject to project scope in order to ensure the final outcomes are correct and the budget is adhered to. More rigid, linear methodologies like Waterfall have less of the continual stakeholder feedback loop, and more getting involvement at key sign-off stages.

Whatever approach your tech project adopts for the delivery method, out-of-scope requests are likely to come up – and need to be addressed appropriately. Sometimes a feature request or change makes a lot of sense and would provide a great deal more value to the business. In these moments the

project manager may talk with the steering committee to determine if this warrants an adjustment of the scope, budget and delivery dates. It’s certainly possible for this to happen, but more often than not these suggestions or requests will form part of a later phase to add more features beyond a minimal viable product or agreed set of features.

The risk of requests that are out of scope being worked to without a formal adjustment of the timeline and budget is that project managers and their delivery teams will overspend time and money. Sometimes a seemingly minor addition can take an entire day or more to add in, throwing timelines out.

For a technology project, the scope must be protected and project managers should default to staying within scope unless there’s an extraordinary request that is generally agreed upon as being vital for the best outcome of the project.

Slow or low productivity

Productivity of a delivery team is so crucial to a project’s success. Maximising the outputs of a single workday is perhaps the most valuable aspect of the project to focus on. Productivity issues, despite what some may think, aren’t usually down to the lack of care or talent in your team. Rather productivity can be hampered by things like:

  • Too many meetings throughout the day create transition costs
  • Unclear briefings on the phase, sprint, and workday
  • Interference of the delivery team by stakeholders or other business units
  • No protection of the delivery team’s time from other non-project requests
  • Poor communication around project progress and expectations
  • Bad culture in the office
  • Not enough support for the team
  • Highly technical Skills being underutilised on menial tasks
  • Lack of milestones and, therefore, loss of motivation

It’s a big problem if your productivity is low – the same amount of progress can take 2 days or 2 weeks depending on everything around the delivery team and how the project’s being managed. Of course, there are situations where individuals aren’t engaging with the project to the expected degree, and these should be navigated on a case-by-case basis. If the whole team’s productivity is low, however, there needs to be a look into some of these more systemic issues.

Becoming overly dependent on external vendors

Large IT projects will typically involve engaging with one or more vendors and 3rd party suppliers – who provide both technologies and people to help the project deliver its requirements.

Unfortunately, there are too many instances in which organisations rely heavily on their vendors to own and maintain the solution – without having sufficient internal resources of their own. A vendor that doesn’t have strong organisational oversight can inadvertently create unclear scope and delivery that doesn’t perfectly meet business needs. This can be amplified with engagements of vendors who are based offshore; which can introduce timing and interpretation issues as well.

The best mix is a competent internal team and leadership who know how to best interface with third parties to get the most out of the relationship – and create the best final product. The organisation needs to prioritise building up the capability of their people and understanding of their own solutions – so that if required, vendors can be changed without interrupting business continuity.

Bugs or errors in code

Technology projects specifically combine high-level business strategic activities and very fine detail down to individual lines of code needing to be perfect. In short, there’s a whole lot that can go wrong in this project type. By its very nature, development needs testing and QA across it – no one should be expected to code perfectly without checks or balances. However, it is a business risk if code relating to a business system that interfaces with customers or sensitive data contains flaws or bugs. These could be exploited or simply prevent the solution from working.

Risk mitigation for code-related issues is often based on ongoing testing and a layer of quality assurance. IQANZ’s technical assurance is an example of this – we guide at the project management level but have specialist team members who understand the intricacies of code, design principles and technologies to provide technical advice.

Incompatibilities between systems

Digital transformation or any sophisticated business technology requires different systems to interplay with each other. Together, they help the organisation deliver to its customers and keep operations running efficiently. Before a project gets underway, significant work needs to occur in platform capability testing, where proposed systems are put through their paces and tested for their ability to talk to each other.

When systems that are proprietary or simply required to be used by the business are not compatible with each other out of the box, the development effort to address this can be significant. It’s a risk to the project’s budget and deadlines if this requirement isn’t identified at the start. A business should look to their platform providers in the first instance to provide confidence that systems will work and, if not, further details of what would be required to make this possible.

Understanding the complexities of the current systems

It’s worth noting the factor of old ‘legacy’ systems. It’s typical for large organisations to have to develop around these older platforms – and rarely is it practical to do wholesale replacement over the whole tech stack.
For that reason, IT teams must ensure that there is enough knowledge in the business around these older systems and how they might be impacted by the project’s solution. We routinely encounter situations where only a few staff have this knowledge and it can be difficult to navigate through this without additional vendor or contractor support.

Key people leaving

The IT job market is incredibly tight for employers; there are far more requirements in businesses needing specialist tech skills than those looking for jobs. Naturally, this high demand makes earning opportunities high for experienced tech professionals, creating many job opportunities. Whether it’s contracting roles or permanent positions, tech professionals have a lot of choices in New Zealand in this era. Unfortunately for businesses looking to preserve some continuity of delivery and knowledge in their technology project, the job market creates attrition issues, and key people do leave.

This presents a massive risk. Without a careful effort to document and foster knowledge sharing between experienced knowledge project team members and others in the business, the project can be left exposed to them leaving and stalling while the knowledge deficit is made up for – either through internal upskilling or hiring another experienced person in a highly competitive job market.

No aspect of your IT project should sit with one person alone. Implement collaboration, documentation and training as part of your project’s cadence to avoid this happening in the areas that really count.

Privacy and security considerations

It’s well documented that security remains one of the biggest risks and areas of focus for organisations. And while steps are taken to protect BAU infrastructure, projects equally demand careful processes and practices to ensure that in-development platforms don’t create security flaws that can be exploited. During different stages of the project, system integrations and datasets are tested and in various states of completion. Any IT project needs to work closely with the security team to develop strategies for protecting the wider business.

Complexities of data migration

One common yet high-stakes phase of an IT project is the migration of data from legacy systems to the new solution. This is particularly important for any project that involves changing or replacing data warehousing where management of data will involve a number of steps to plan, protect and execute the transition.

In terms of privacy, it’s worth remembering that all personnel involved in the project including contractors need to adhere to privacy policies. For projects relating to the management of sensitive data, there may be organisational security clearance processes to go through. Project managers should factor this into their resource planning to ensure that contractors have cleared the hurdles before getting into their work.

Disaster recovery planning

Losing ground on a project due to unforeseen circumstances that take systems down or worse, lose data, is frustrating and very costly to organisations. The field of disaster recovery has been greatly aided by the advancements in cloud infrastructure, allowing businesses of any size to remain operational or reduce the recovery time by a significant amount.

It’s important to not exclude any IT project progress, systems, development site, data or other digitally-held assets from your disaster recovery plan. The initial step is having a frequent, reliable backup process in place, but this is only one part of the puzzle. Get in touch with us to learn more.

Estimated time frames are too tight

Planning enough time for each phase or deliverable might seem elementary to a large organisation that launches projects frequently, but it continues to be an issue we encounter as technical assurance specialists. With the myriad of tasks required to build a solution, hundreds of variables can cause a timeframe to blow out. Of course, there’s no practical way to anticipate every possible variable that would create a shorter or longer timeframe, so we suggest building a healthy contingency time into each phase. There should be a reasonable period of time for completing a task and another 20-25% buffer for unforeseen issues and rework.

Tight timeframes don’t just create a risk to meeting a deadline – the deliverable and outcome itself can suffer. Completing an important system upgrade by an unrealistic set date can cause teams to rush through their work and accidentally skip important steps. The knock-on effects of this could be as bad as security flaws that put the business and its data at real risk. A timeframe is there to help provide a reference point for when the business expects to see the outcomes of the project plan. But if that date comes and the product is not ready, it should not be released.

Managing risks in a project portfolio IQANZ

User testing uncovers problems that require rework

There’s no technology project we could think of where testing wasn’t part of the mix. Testing must be conducted to ensure that the solution is fit for purpose, has all the important bugs ironed out and gets stress tested against cyber attacks. Of course, the inference with testing a product or system is that the testers may find things that need rework.

The risk here is perhaps less about the user testing findings and more when an organisation hasn’t left adequate time to go back and address these findings. Rework is often time-consuming but crucial, so budgets will often need to be revisited. That contingency, as mentioned earlier, if healthy enough, will allow for some buffer, but the project timeline itself should adequately account for post-testing development work.

Business users aren’t considered enough

We can’t stress enough how important it is to involve the users within the business. The amount of rework that can be avoided by having active feedback loops at each phase from business case development to feature requirements and scope should involve representation from across the business. There are golden nuggets to be found within the various users of a technology solution – often creating shortcuts to delivery.

When business users have been involved right from the start, the eventual integration of that solution to BAU operations will typically be a lot smoother. There’s a sense of input that makes users more receptive to the finished product, even if there are aspects that still need to be refined, involvement creates buy-in and ideally advocacy within the business.

The most significant risk – not considering risks

Becoming an organisation that front-foots technology risks is an excellent investment of time and resources. Your projects will be delivered cheaper, the outcomes will be better, and the business will not be as exposed to issues. The governance around your technology project must treat risk management with as much importance as delivery. Large IT projects need dedicated risk personnel, but risk management is the job of everyone from the leadership team to the steering committee to the project management office and even the delivery team.

The risks that hit projects and businesses the hardest are often the ones they don’t see coming. Identifying risks now is the first step to softening the blow should those events arise. Plan, and keep your project protected.

Need guidance on your IT project?

IQANZ provides specialist assurance services for technology projects across the private and public sectors. We apply proven assurance methodologies along with a high level of technical expertise to help guide projects and programmes to success. If you’re interested in getting independent, expert help on your technology project, get in touch with our team.

Where to next?

Read our other technical project resources:

Common IT Project Risks

Common IT Project Risks

Risks are present in every project, but technology has a degree of complexity that makes risk management even more crucial.
Learn More >>

Designing a portfolio delivery plan IQANZ

Resourcing A Development Team

IT projects require a number of skills to deliver. We explore the process of resourcing your development capability.
Learn More >>

Guide to portfolio governance IQANZ

Preparing An Organisation For New IT Systems

Digital transformation brings with it new platforms, software and systems. How can organisations prepare for this properly? We explore this in our guide.
Learn More >>

Building a balanced project portfolio IQANZ

Waterfall IT Project Management

Waterfall is one of the more popular project management methodologies in technology initiatives. We discuss why.
Learn More >>

Secret to successful portfolio delivery IQANZ

Scrum and Agile In IT Projects

Scrum has become the most popular Agile methodology for projects.
Learn More >>

Prioritising projects in an organisation IQANZ

Scoping An IT Project

IT projects are complex and need clearly defined parameters to be delivered within budget. Read more about scoping tech projects in our guide.
Learn More >>

Latest Technical Project Articles

What to Look for in a Quality Assurance Provider: 8 Key Attributes for Project Success

What to Look for in a Quality Assurance Provider: 8 Key Attributes for Project Success

Sep 23, 2024

When it comes to selecting a quality assurance provider for your project, the focus should not only be on technical expertise but also on the soft skills that truly make a difference. With years of experience in quality assurance, I’ve identified several key attributes that define an effective assurance provider, helping you navigate the complexities of your projects with confidence. Let’s explore the eight essential qualities your assurance provider should bring to the table.

read more