Select Page

We help businesses to realise the benefits of their IT investments through objective decision making within the portfolio of change initiatives and efficient and cost-effective project execution.

Delivering the Change

Leveraging our experience of delivering change initiatives of all sizes (from large business transformation programs with hundreds of people to smaller, more targeted projects) we partner with internal, external and other third parties resources to deliver the plan through the most relevant delivery methodology for your organisation and the type of change:

  1. Intitiating the project
    • Scoping the deliverables
    • Building the team with internal, external and partner resources
    • Clearly refining the deliverables into a realistic plan and timeline
  2. Executing the plan
  3. Providing management support and coaching (as required) for the business sponsor and key leads to deliver the business change and the benefits realisation.

 Project Types, Complexity, Risk, Capability and Culture

The type of the change and the risk appetite, technical skills and management culture of the organisation will influence which type of methodology is most appropriate to the efficient and cost-effective method of delivery.   Many organisations may have their preferred methodology which we work with as needed. If not, then a change assessment can help in defining the technology delivery and change management strategies.


Standalone Change

This may be the development of a web application, a business process change, a complex technical document or many other types of change . The key characteristic is that there are limited (or no) dependencies on other changes within the organisation i.e. This change/project can be delivered as a standalone piece of work. This type of change naturally lends itself more to an agile approach as the delivery is in short cycles and the value can be incrementally realised as the project progresses.  The main benefits are that changes in requirements can be handled efficiently and secondly the client may determine when sufficient value has been realised and complete the project.

Program of Projects

These are usually a sequence of inter-related initiaitives to the same (or linked) technology platform, that either have dependencies or there is a natural sequencing. These may be many small changes, several large initiatives or a combination and can be executed in parallel, however the delivery sequence is usually critical and a change in one stream of activity may affect changes in other streams. Depending on the level of dependence these can be delivered via an Agile or Hybrid Agile approach, to incrementally deliver value but supporting the likely integration testing and preserving the sequencing required.

Transformation Program

These are usually significant business (process) changes that often require a change of technology system. These may be internally developed applications, they may be hosted web services or they could be a large integrated platform, such as SAP or Oracle, etc… The characteristic of these projects is that there is a fundamental business change that then requires the underlying technology to support it. Generally the programs require a multitude of skills and are implemented as a sequence of roll-outs to help manage the delivery and minimise the risk to business operations. The business process change is a significant component and is critical the realising the benefits of the program.

Risk Management

Depending on the size and type of the change initiative, the risks associated with the delivery will require to be managed.  The delivery and operational risk can be managed through a simple framework that assigns ownership for the action plan to mitigate the risk as far as possible.

  • Identification
  • Assessment
  • Control
  • Review

A risk may not be fully mitigated, but the residual risk can be closely monitored and any new risks can be assessed and assigned.

Delivery Methodologies


This type of approach can be utilised for both technology and business changes.
The requirements are captured as a list of user stories, describing the business need. These are then estimated for size and the user stories (the backlog) are prioritised into short cycles (2 week sprints for example) of deliverables.
The content of each “sprint” being determined just before the start of the cycle, which allows re-prioritisation or change of requirements very efficiently.
The teams are usually small with all the relevant skills needed to deliver and implement the change.  At the end of each sprint, the change is delivered to the users or business teams to actually ustilise, thus value to the organisation is realised incrementally through the life of the project.  Once sufficient value has been established then the project may be closed, and we can help structure the delivery contract for our clients to give this flexibility.

Managed or Hybrid Agile

This is usually used for complex programs of projects with many dependencies or for complex system landscapes where the technical changes must be heavily integration tested before implementation. The approach uses the Agile approach through the build and test phases of the project ensuring work is completed and delivered to a staging location, but the approach then aligns systems at a Stage Gate for integration testing, prior to final delivery to the production landscape.
This type of approach works well for programs of projects and for complex system landscapes where there are limited automated test tools available to execute quick cycles of development/test.


From a delivery perspective this is the least risky, as each stage of the project is executed in sequence with a Stage Gate, at the start and end of each phase; allowing the management team to validate that work is complete and of sufficient quality before continuing. This allows multiple opportunites to assess the state of the project and the investment as to whether to continue.  However no business value is realised until the end phase once everthing is implemented. This type of approach can have an extended timeline, due to the sequential nature, and once the requirements are captured at the start of the project in the Analyse and Design phases, it is more complex (and usually very expensive) to revise the requirements subsequently.

Technology (Hardware and Software) Phases

Regardless of the methodology, each execute the same phases of activity, however in different manners, timings and resources. 

  • Analysis – scoping of the project, identiying requirements (or user stories), clarifying the delivery methodology and confirming the benefits realisation plan
  • Design – functional and technical deisgn of the target solution, with 
  • Build – the coding, configuration or construction of the infrastructure
  • Test – Project and user testing to ensure that the solution meets the defined requirements
  • Implement – introduction of the changes into the production landscape, either as a “big-bang”, a phased implementation and roll-out to the user community

Change Management

For technology projects involving a business process change, then the management of introducing the change into the business community is critical to the adoption and success of realising the projects benefits.  This stream of activity covers:

  • Process definiton and documentation
  • Identfication and agreement of the new interaction between teams with the revised or new processes
  • Training material development and delivery to the relevant business communities
  • Operating procedures (as required) to support process execution
  • Compliance, legal and statutory documentation


Are critical  to the successful realisation of the project benefits.  The communications actitvities provide awareness to both the project team and the wider business community:

  • Project plan, timeline and impact to the teams
  • Status of the project and change
  • Project implementation timings
  • Training planning and impact to operations