Being - First Time Right
July 21, 2023 • Sheetal Malgaonkar
Imagine the days without GPS-enabled devices - whenever we had to reach a destination and didn't know the route. With some idea we may have had, or information sought from others, we'd head in a certain direction and ultimately reach a place only to find it wasn't the correct destination. We'd then re-confirm the way and hope to finally reach the right one. It's difficult to imagine how hard this gets when the right information isn't gathered, the right questions aren't asked, and the right process isn't applied - it doesn't just make reaching the result difficult, it has a real impact on time and cost.
Today, GPS-enabled devices need just a few inputs to offer alternate routes, and the chances of reaching our destination on the first attempt increase drastically. Reaching the destination on the first attempt saves us from the frustration of re-routing, re-searching, and re-confirming - and it saves energy, time, and fuel (cost).
Bottom line - one can save time and money by being right the first time.
Every task performed by every role on a project is a destination of its own. Without gathering the right information, asking the right questions, and applying the right methods, best practices, and processes to be "first time right", the result is re-routing or re-work - which doesn't just cause frustration, it affects the two things that matter most on any project: cost and time. How often do we hear "Oh, I thought it was supposed to be like this" or "I thought you meant it the other way" from a teammate or client? Every one of those moments is a small re-route, and it adds up.
There's no GPS-like device (yet) to help us be first time right at every task. But we've found that applying a few consistent methods gets us there more often - whether it's a complex computation for finance-related software, a complex web screen for working with data, a specification for a developer, or understanding a client's question. By tracking how often we get it right the first time and continuously refining our approach, we've steadily reduced the rework that comes from re-gathering requirements, re-creating test cases, re-coding, re-testing, re-deploying, and re-confirming with customers. That's time we get to spend building, instead of redoing.
Some of the methods we use
- Before responding to a client's question or clarification, we first make sure we understand the question itself - what information is really needed, and why - before providing an answer, along with the impact of any alternatives. This avoids revisiting the same point later and helps catch a potential issue before it becomes a bigger one.
- Before coding a complex computation, we confirm the data availability, source, and format, along with the formula and where each of its components comes from - then test it against real data in a spreadsheet first. This sharply reduces the chance of incorrect results reaching production.
- Before building a screen, we walk through the scenario with the client or end user and agree on a quick static HTML mock-up - covering exactly how it should look, the label and button text, watermark text, and validation messages. Only after that's confirmed does development begin. This avoids the familiar late-stage differences of opinion: "I wanted blue buttons, not green," or "I expected 'Please enter your name,' not 'Name cannot be left blank.'"
The list goes on - but the principle stays the same: a few extra minutes spent confirming understanding upfront save far more time than the rework that follows when we get it wrong the first time.