customer needs drive transformation

Technical assurance: six factors to consider

Submitted by Stephen Moffitt on
Fri 15/07/2016

Technology projects can fail for an infinite number of reasons during development. Technical assurance can help mitigate this risk; however, the risk of failure does not end at acceptance. Projects frequently fail even after successful delivery because no one had planned for their ongoing existence.  Addressing six key factors early on in the project scoping and planning process will help reduce the risk that all the time and resources spent on developing a new technology project are not wasted within a couple of years.

6 factor star

Technical assurance 6 factor star

Six long-term technical assurance factors

While some of the factors in this star diagram seem obvious, they have a slightly different focus here than usual. They are focused on the product or service after the project is closed. As part of our technical review and assurance, we look for answers to these questions, either explicitly or implicitly in the project documentation. What I want to do here is briefly describe each of these factors and what we would expect to see.


This seems rather obvious. Of course you know why you are starting this project. You have the business case or something similar outlining the problem or opportunity the project is supposed to solve. From a technical assurance perspective, however, we are looking for something different. Why should this product or service exist in a year or more? If you are going to invest significant resources in a project, you should be thinking, not just about today’s problems, but how this could also help tomorrow.


Usability, user testing, user experience. These are all key aspects of development projects, right? Unfortunately, this is not always the case. So many projects have been delivered only to discover that their intended users don’t like it or need it. If you are going to build something, make sure you really know who are developing for and that what you deliver is at least something they can get excited about, even if they never thought they needed it before.


In most development projects, some external partner or supplier is involved after the delivery. It’s important to think about how that relationship will continue, particularly when it comes to ongoing development. Since the project has a road map or product backlog that will guide the ongoing releases, the relationship with these partners is key. Planning for this up-front will reduce the risk of delays in the ongoing release cycle.


Technical projects, particularly customer-facing ones, increasingly face some sort of regulatory or legal requirements. This may be around personal data, intellectual property or compliance. As part of the project scoping, these issues need to be factored in.


Here I am talking about how the new product or system will integrate into the larger technology architecture. As part of the technical assurance, we would be looking at:

  • How data gets to and from the new system
  • How it fits into the enterprise architecture
  • Where it sits in the infrastructure, e.g., is it standalone or is it in the same data centre/cloud


When we look at the sustainability of the project, we focus on questions like:

  • Are there sufficient, and sufficiently skilled, resources to maintain the system or product once the project is completed?
  • Is there a development roadmap for further releases?
  • Is there sufficient, dedicated funding for ongoing support and enhancement once the project budget closes?
  • Has there been sufficient knowledge transfer from the development team to the operations team?

Including these six medium to long-term factors in the initial scoping and planning of projects will greatly reduce the chance of the resulting product or service failing and insure that the money invested in the project is well spent.