Getting projects DONE with agility

“Projects are bad for building business agility” - A phrase that might be familiar to you, and in a world where products seem to be the fancy term, this might not be the most popular thing to say. I have supported numerous clients moving from “Projects” to “Products. " Moving to a product operating model could be a very long time, and our work has seen the duration range from 6 months to 24 months.

This transformational change has a better chance of success if approached in tiny incremental changes over time, giving the organisation ample room to learn from the multiple experiments.

This post discusses some intermediate steps an organisation might take to transform from a project model to a product model. 

Start with a clear Business Outcome:

Organisations typically package a project to build new capabilities or extend or remove existing ones. These capabilities can be likened to work that needs to be done, but the reason for doing such work should be the Outcomes the organisation hopes to deliver. Some projects would have a business case used for seeking budget approvals, and it seems that the business case is “forgotten” once the budget is approved. This business case is very similar to business outcomes except that the outcomes would be written in terms of value to be delivered to the users and the customers. 

An example of a business outcome could be:

“Enabling our teams to self-serve infrastructure needs in the cloud, cutting infrastructure lead time by 50%.”

The business outcome is the goal to be delivered at project completion; it should be written in conjunction with all required stakeholders, and it could be communicated to the product team regularly. The business outcomes should drive the work necessary to deliver the project. i.e. It should be used to create, adapt, and order the items in the backlog.

Measure progress towards delivering the Business Outcomes: 

Traditional projects are measured as delivered “on time”, “within the scope”, and “on budget”; these metrics are important, but because they do not measure the outcomes delivered to the customer, I will refer to them as Vanity metrics within the context of this post. The best metrics for any initiatives are those that are collected from the consumers (users) of the capabilities delivered.  It is a fallacy to assume that we understand the needs of our customers; many organisations have been proven wrong many times over, and the only way to determine if the capabilities delivered have provided hypothesised value is to solicit for the users.

The metrics selected for every project should allow the project team to change tactics if they do not trend towards a successful delivery of the business outcomes.

Nominate and Empower an Outcome Owner:

An outcome owner drives and steers the team towards delivering the outcome defined for the project; the "outcome owner" collaborates with all stakeholders and makes decisions throughout the project's lifecycle. The organisation empowers an outcome owner, and as a result, everyone respects their decision; the "outcome owner" is accountable to maximise the value that the project delivers; the individual is accountable for Return on the Investment (ROI) and any other measures of values as deemed appropriate for the project. In addition, this individual is accountable for market research and constantly scans the competitive landscape for new opportunities.

Within the organisation, the outcome owner should collaborate with other outcome owners on different projects to ensure that work is not duplicated and that there are zero instances of multiple projects delivering similar outcomes. It is worth pointing out that a project should have one outcome owner.

Short-lived projects:

There is an inherent more significant risk associated with long-lived projects, and we believe that software projects longer than six (6) months are already too big and carry a substantial amount of risk. We advise our clients that project duration should not exceed six (6) months and some of the shortest projects we have executed run for about six (6) weeks. Suppose an organisation decides to run their projects indeed using an agile approach. In that case, the project team should collaborate to decide on the shortest amount of time that makes sense to deliver a valuable outcome.

Once that is decided, the project team should comment to create an appropriate backlog based on the objectives agreed to be worthy of the investment.

Leverage shorter-term goals to iterate towards the Project Outcome:

In this article, we have discussed how the project backlog is a hypothesised list of items that the project team believes will deliver the outcome; there are no certainties. Taking an agile approach to delivering the projects would require frequent inspection and adaptations of the progress towards the overall objective for the project. This means that the project team would need to have built some capabilities to release frequently to their users and gather feedback from the users of the built product.

The approach we suggest is for the outcome owner to propose a set of intermediary objectives organized in a roadmap with alternative paths through the roadmap based on the evidence collected as the project team iteratively and incrementally executes towards the project objectives.

As we continually discuss organisational transformation, such as moving from project ways of working to the product operating model, clients are increasingly interested in an approach they can use to complete in-flight projects. When we are presented with opportunities to deliver projects using an agile approach, we aim to help our clients with this. 

Many of the ideas shared in this post are inspired by the Professional Scrum Framework for Solving Complex Problems. Depending on your role and what you want to achieve, you might want to check out our training schedule or contact us to discuss how we can help transform your organisation.