Build single sources of truth (and destroy the other sources)
Without standards there can be no kaizen [continuous improvement].
—Taichi Ohno, via The Lean Thinker blog
When you conduct an improvement, think about what written information is available. How can you help ensure people know where to go for the right information, and that they have one authoritative place to get answers?
By default, organizations have an oral culture: people get answers from one another. If you don’t know, you ask your coworkers: “how do you order supplies?” or “what’s our official FedEx address?” When you’re trying to make an improvement, you now have a large number of communications channels to manage. All these people now need to tell one another the new way of doing things.
It’s much easier to introduce a single source of truth: an authoritative written system. If Bob tells you one thing, and the system tells you another, the system (not Bob) is correct.
Talking about this as an abstract concept is perhaps not helpful. Here are two specific examples of how I built authoritative sources to support a project management process improvement.
Once upon a time, I was a PMO director and needed to re-create the project management methodology. Over several years, the methodology had been developed and re-developed and improved and hacked and tweaked. Each project manager had their own techniques, unknown to the other PMs. You couldn’t guarantee that all projects had similar activities. If someone learned a more effective way to perform stakeholder analysis, for example, they might bring it up in a team meeting–but that knowledge wasn’t systematically captured or used for improvements.
An important part of re-creating the methodology was building authoritative sources. Below are two examples of building authoritative sources: building an authoritative project list, and building an authoritative source for the methodology.
Example #1: the authoritative project list
No one could give me an official project list.
If I asked three different people to give me a list of projects, each list had a different set of projects on it.
There was a PPM (project, program, and portfolio management) tool, but everyone had their own saved reports they’d built themselves. Some reports would show smaller work efforts; other reports would include projects that had already completed (according to the PM).
If you can’t produce a valid project current-state project list, you have no hope of improving your project management methodology. You don’t even know what projects you’re running!
Or, how many times have you gotten caught up in conversations about whether something was a project, or whether the project has started? You need a system to track those decisions. You need an authoritative list of whatever you’re calling a project. If someone disagrees with whether something should be a project, the conversation is logically equivalent to whether something should show up on the project list.
Building the project dashboard
In the tool, I built a project dashboard. The dashboard was the official list of all projects. It included three columns:
- Left column: “Past Projects”
- Report: all projects completed in the last 12 months
- Middle column: “Present Projects”
- Report: all “in-flight” projects
- Report: all “on hold” projects. (Work could only be on this list if the “on hold until” date was filled out; i.e. projects that were indefinitely “on hold” would instead be kicked back to “future projects”)
- Right column: “Future projects”
- Report: “on deck” projects
- Report: project requests
All these reports needed a consistent definition for what records should be considered “projects.” The PPM tool had a built-in “project type” field, so I created a type called “Project,” ensured no records started out using this type, and then I manually set this field for each record I thought was a project. I also re-purposed the built-in “status” field to ensure projects always mapped to exactly one of the past, present, and future projects reports.
Making the project list accurate
Once the above dashboard existed, I sat down with each project manager and ensured their projects were added to the dashboard at whatever state they felt was accurate.
I then made sure that at least the IT leadership all had access to the tool. I met with each person individually, and set up their account so this dashboard was the default view on login.
This report became the beachhead for project management information: you couldn’t rely on much information (yet), but I guranteed that this one report was accurate.
I referred people to the dashboard all the time and made all my decisions based on it. I asked people to pull it up in meetings whenever we talked about our projects. I reinforced that this dashboard, not me or any other person, was authoritative.
Destroying all the other project lists
After rolling out the new dashboard I pulled up a list of the other project reports in the system. I met with the owner of each report and asked them what they used it for. If they didn’t have a compelling need for it, I asked them to delete it.
This was a scorched earth policy. There was no going back. If you wanted a list of projects, you had to use the new authoritative list.
I can’t overstate the importance of destroying the old reports. By habit, people might pull up the old reports and start to make bad decisions based on the bad data. Then people might stop trusting the entire system and the new project dashboard would be useless.
Example #2: the authoritative source for project methodology
Project methodology artifacts existed in many places: in file shares, in office print-outs pinned to cubicles, in Google documents, and in MS Word documents. All these artifacts said different things. If you’d been around long enough, you could sort of guess at which parts were still relevant.
We conducted three half-day meetings to improve the methodology:
- Half-day meeting to define the current methodology
- Half-day meeting to review and delete old artifacts
- Half-day meeting to discuss process improvements
Committing to one source for the methodology
At the beginning of the first meeting, we talked briefly about the best storage location for everyone (which happened to be Google docs).
I created an empty Google docs folder for the methodology. I was the only person with write access to this folder. We agreed that (1) this folder would represent the authoritative methodology and (2) we would, as a team, find all the non-authoritative artifacts, review them, and then delete them.
I then created and shared with edit access a Google spreadsheet in this folder called “methodology improvement ideas” where we would store any ideas for improving project management.
Documenting the methodology as a team
My mantra for this first meeting was, “what is our methodology today?” If anyone had an idea for improving the methodology–great: they could put it themselves in the “methodology improvement ideas” document and forget about it. People have an extremely hard time seeing the value of documenting the current state, and anyone facilitating a meeting like this needs to keep people focused on what’s currently happening.
We then stepped through the methodology either with smart boards or on paper. I spent a good deal of time afterwards trying to write all this down in a Google doc, which I then added to the authoritative Google docs folder.
Reviewing and deleting the old artifacts
In the second meeting, we brainstormed all the places that might describe the current methodology, and we made a long list of file paths and locations.
We reviewed as a team what I had put together summarizing the current-state methodology. People corrected it. This also served as a reminder of what we’d captured.
Then we went through each old artifact. We reviewed them to see if we missed anything. Once we reviewed the artifact, we deleted it right then. This continued until all the old artifacts were deleted.
At this point, if anyone wanted to know the methodology, they had to go to the new folder. Everyone was also very familiar with the methodology because we had now spent around 8 hours documenting and reviewing it.
Discussing process improvement ideas
The “process improvement ideas” list grew quite long through all these meetings as people had ideas for improvement. In the final meeting, we triaged this list and rank-ordered it. We assigned people to investigate the top improvement ideas and bring recommendations back to the team meeting.
It was now clear how to improve the methodology: any accepted recommendations would be reflected in the authoritative document. The methodology folder we’d created was the single source of truth.
(Aside: If I were doing it again, I don’t know if I would keep this list around after reviewing it. There are lots of good reasons for why a list of improvement ideas isn’t good–the best treatment of this topic that I’ve seen is in Toyota Kata. However, the list was our “parking lot” for the previous two meetings and it was a great way to keep people focused on defining the current state.)
The value of these authoritative sources
When you conduct an improvement you are changing people’s mental models and their ways of approaching the world.
If you give them a clear source to consult for any questions, you provide them a guidepost for your improvement. They can check the source and know what’s the current way of doing things.
In my opinion, this is one of the few ways that process improvements can reduce ambiguity and increase the feeling of stability. By giving people a clear single source you give them something to rely on.
One thought on “Build single sources of truth (and destroy the other sources)”
Comments are closed.