Skip to main content

Building the TRUE tool

Building the TRUE tool and the TRUE process at ODILeeds.

In Autumn 2017 a team at ODILeeds joined a University of Leeds project called TRUE: transformational routemapping for urban environments.

This project was part of the EPSRC's Urban Living Partnership funding round. It aims to bring the Routemap process, used to deliver huge engineering projects such as Crossrail successfully, to new challenges. Our role was to turn over a year of work done by academics into a tool that teams could use on urban transformation projects.

The project funding finished on 19/02/2018 when we presented the prototype tool. In this blogpost I describe the challenges that we faced and the process that we used to overcome those challenges. I also present the TRUE tool — which you can try right now, and the TRUE process that it is part of.

What is TRUE?

The first problem that we had upon joining the project was to understand what the TRUE process was. We had questions like,

  1. What is TRUE?
  2. Who is supposed to use TRUE?
  3. What kind of projects is TRUE suitable for?
  4. What are the alternatives to TRUE?
  5. Why is TRUE better than these alternatives?

And although the team had answers for us, we couldn't understand them. We found their explanations too complicated. They found our understanding of their answers too simple.

This conflict was common throughout the project. It was something that the TRUE tool itself eventually helped us to overcome.

 

Today we understand TRUE better. My answers to those question are,

  1. TRUE is a tool to help teams work together and make better plans for completing projects.
  2. TRUE provides the most value to teams with different specialisms, expectations, and ways of working.
  3. TRUE can help with projects like building community housing, creating a local anti-poverty strategy, or setting up an allotment. But it is also useful for a wide range of projects where team members have conflicting expectations.
  4. An alternative to TRUE is to have experienced team members and a great project manager/community leader with lots of available time.
  5. TRUE is better than this alternative because great project managers are rare and busy and rarely community leaders, and because the most interesting projects are where people are doing new things (and are thus inexperienced).

 

Using TRUE to build TRUE.

We insisted on using the TRUE process to build the TRUE tool. That way we would test our understanding of the tool as we built it. That decision means that we now have a fully-worked example of the TRUE process, which I will work through below.

TRUE is a three step process, as in the flow diagram below.

TRUE Process Outline
An outline of the TRUE process.

Step 1: Assess

We started at step 1, created a new project in the TRUE tool, and invited everyone involved in its development to join in. That meant clicking a link in their invite email and filling in around 80 questions about the project.

For each team member, the TRUE tool takes the answers to these 80 questions and calculates three important outputs.

  1. The complexities in the project, in that team member's opinion.
  2. The capabilities of the team, in that team member's opinion.
  3. The gap between these two assessments. The most important part of this output are where the project is complex and the corresponding capabilities of the team are lacking.

It was only when I saw the results of this process for the first time that I understood the value of the TRUE process. As the team leader I could see everyone's assessments of our project (though not which team member had made that assessment) and the results were very clear and very worrying.

 

Step 2: Diagnose

Everyone in our team agreed that we lacked a clear and consistent understanding of what we were building. Everyone in our team agreed that we had very different assumptions about the project and working styles. Most of the team felt that there was insufficient engagement with potential users of the tool.

There were other concerns but they didn't require major intervention.

 

The power of the TRUE tool is in identifying big problems in a project that would otherwise be missed. By replacing polite discussion with an algorithm, it surfaces problems that people are too polite or too scared to mention. By giving every team member equal weight, it gives front-line staff a louder voice. By collecting every team member's answers it distinguishes between small problems that can be solved by individuals and large shared problems that must be solved by the team. By asking structured questions, it classifies problems into issues that can be solved, rather than just collecting a long list of moans.

 

A key feature of the TRUE process is that diagnosed problems come with guidance on how to solve them. This guidance comes in the form of reference guides. So we looked up our three problems in the reference guides, and agreed a set of recommendations that would solve them. This output is called The Barriers Table.

The Barriers Table
The Barriers Table is the main output from step 2 of the TRUE process.

Step 3: Plan

Armed with our barriers table, we were ready to move on to stage 3. We assigned each item on our list of recommendation to workstreams. For our project we created three workstreams; coding, project managers, and academics. You can download our Recommendations to workstream table.

In the TRUE process, each workstream works separately and is responsible for planning actions that match the recommendations that have been assigned to them. Below is an extract of the coding workstream's action plan.

An example workstream action plan
Each workstream creates an action plan. This is an extract from the coding workstream's action plan.

The final step of the TRUE process happens when all the workstreams meet to discuss how their agreed actions can work together. Each workstream picks a colour and puts each of their actions on a post-it note.

Some actions in one workstream need to happen before others can occur. Some actions may need to be assigned to other workstreams. Some actions will need to occur together. This is all achieved by re-organising post-its.

Some of the changes that took place in our own project management at this stage were,

  • The academic workstream needed to agree on project terminologies before the coding workstream could proceed with tool design.
  • The coding workstream needed to build a final version of the TRUE tool before the academic workstream could test that their example use cases gave the expected results in it.
  • The academic workstream needed to create example reference before the coding and project management workstreams could understand what the point of reference guides was.
  • The academic workstream needed to define the algorithm for calculating project complexities and team capabilities ahead of the coding team implementing this.
  • Some of the algorithm definition work was shifted to the coding workstream.

 

At the end of the planning stage the output looks something like below. You can download a less colourful version of our enhancement map, in Excel format.

Enhancement plan
The final output from the TRUE process is a team enhancement plan.

This is the end of the TRUE process as we have built it so far. Each workstream now has a better idea of how their actions contribute to the whole team's success and they can go away and write more detailed plans and do their work.

 We have created a detailed version of the first diagram on this blog post, that shows how every output I have shared links to the TRUE process.

TRUE Process Details
A detailed view of the TRUE process.

 

What next?

Through the process of building the TRUE tool I have been won around to the value of the TRUE process. It was designed to help with projects like building community housing, creating a local anti-poverty strategy, or setting up an allotment, and I am confident that it could be useful in these areas. But it is also suitable for a much wider range of projects where team members frequently have conflicting expectations. Examples of this which we are familiar are co-production of digital solutions for communities and the health service where technologists, healthcare professionals, and local residents often struggle to understand each other's concerns, capabilities, and constraints.

Critically, the TRUE process does not replace good project management and frequent team discussions. But it does surface critical issues early enough for them to be dealt with.

 

Less positively, our task was only to build a prototype of the tool. It works and we have tested it, but there is much more to do.

My biggest concern remains the complexity of the TRUE process and the way it is described.  The words and concepts in the TRUE tool's questions are too complicated. When used by a large and diverse team, many team member will give up before answering every question. We know this because it happened in testing, with low participation rates in every project we trialled.

To work well, the TRUE process needs all team members to complete the assessment and feel comfortable sharing their concerns about project delivery. If the language used in the tool remains too complex for most team members to understand, and if there remains too many questions for most people to find time to complete, the strengths of the TRUE process are lost.

Throughout the project we have experienced a tension between the coding workstream and the academic workstream. This is largely driven by differences in incentives.

Academic success is largely judged by advancing the forefront of a field, often through additional completeness and complexity.

Coding success is largely judged by user-satisfaction and retention, often achieved through approximation and simplification.

The TRUE process has helped us to deliver a successful project despite this tension. But the tension remains an obstacle to the wider success of the tool.

 

All of our outputs

Project outlines,

For this project

  1. Barriers table.
  2. Recommendations to workstream table.
  3. Coding workstream action plan.
  4. Project management workstream action plan. (see project enhancement map).
  5. Academic workstream action plan. (see project enhancement map).
  6. Project enhancement plan.

Available on request

  • Sprint notes. These were the main formal feedback mechanism between the coding workstream and the academic workstream. They contain personal information and will only be shared on request.