There are many ways to deliver a technology project, ranging from pure textbook approaches to organisation-specific methodologies built from hard-won experience. Sometimes it is better to deliver incrementally; other types of projects (for example, a data migration) are better suited to a ‘big bang’ – do it once and move on.

Whatever the project outputs are, there are a number of things that are vital to a successful delivery and without which projects can lose direction, fail to generate the expected business value and waste valuable resource:

Proactively Select the Methodology

“The answer’s agile, what’s the question?” Agile is embedded in most organisations now in some form and to varying degrees of maturity. Often, this is in the shape of Agile Scrum (or variations of it), which tends to be the most familiar, though this is frequently used alongside Kanban and SAFe concepts for larger projects/programmes. Waterfall is usually discounted straight away, although the instinctive desire to fully understand up-front what is being built and when it will be delivered, should not be ignored.

Typically, when a project is initiated, the delivery methodology used will be the organisational standard (“we do agile here”), but the decision to use this is often made without any real assessment to validate that it is the right way to run the project. As a result, delivery is structured to fit into a model whose full benefits are not achieved or that is amended to suit that project specifically.

We collaborate with customers to assess project needs and organisational/stakeholder readiness to reach a proactive decision on the right approach to take, identifying how the project needs to be configured to align to that approach and where it needs support to remain aligned. In this way, we can help get the project started on the right footing and ensure that the full value of the chosen approach is realised.

Define the Governance

Every project needs strong, robust governance, where external parties are used to provide services and cost and quality management are at a premium. With agile projects, this becomes even more important, as finite budgets require sprints/iterations to be limited and organisations often do not have internal capability to operate continuous improvement, meaning that the project must deliver a fully functioning product (even if MVP) before the money runs out.

In practise, it is often necessary to use agile as a development methodology (i.e., not a project methodology) and to wrap it in a project management approach that defines milestones, fixes product increments and schedules releases (and business readiness activity) at specific points in time. In this way, development can take advantage of agile practises – time-boxed periods of development, early demonstration of value, reviews, and elevated levels of collaboration – while the overarching project benefits from clear (and clearly understood) delivery objectives. Key to this is scope control and the ability of the project, through the Product Owner, to manage its outputs versus allocation to continuous improvement or future phase.

Define the Success Criteria

How do you establish whether your project has been a success or not? On-time and under budget? Did it go live? Or are you tracking KPIs and business benefits to prove the value of the solution? Success has different meanings to different people/teams – it could be cost savings, removal of technical debt, greater process efficiency, improved visibility of data and insights. However, it is defined, success requires both a clear vision for the project and a way to measure its value.

The vision is important, and it takes effort to ensure that the project remains on the right track. It is essential to reinforce the vision regularly – stakeholders and, more so, project team members, which are not necessarily involved at the business planning level, can lose sight of the bigger picture – and it needs to be communicated regularly to keep everyone informed and aligned.

Value, aligned to broader strategy, should be laid out in the business case for the project and it should be part of the project manager’s remit to work closely with the business to define value and how it will be tracked. Most technology change has a business impact (though it may be difficult to link, say, infrastructure upgrades to business user experience) and therefore there needs to be consultation with the business to establish value and the metrics that will be used to show the (hopefully) positive impact of the project.

CloudSource Blueprint

We often see IT-led projects that do not focus enough on business engagement and these both create organisational risk and miss the opportunity to engage and energise the end user community. At CloudSource, we build business change management into all our engagements, whether applying the principles to programme planning or mobilising a dedicated change function, to increase the likelihood of successful adoption and sustainable, positive change.

Successful project delivery requires making the right decisions early about how it should be run, and then backing these up through the implementation with the right governance to manage the quality of the deliverable through to the live release and beyond.

If you want to learn more about CloudSource’s tried and tested approach and the ways that we have helped our customers deliver business value and successful digital transformation, please reach out to us.

Email: ozlem.kilavuz@cloudsource.uk.com

Teams: +44 (0)1156 782 043