The contract said the product required an "Audit log." That was it. The web app for a major hospital chain with 35,000 users wanted an audit log, and we were under contractual obligation to deliver one. Whatever "audit log" meant.

When I say audit log, what jumps to mind? Is it:

• A log of CRUD (create, read, update, destroy) activities for key parts of the system?

• Is it a log of every change event system-wide?

• What does this log data capture? Who? What? When? Okay, what about deltas? What about related or effectual changes?

• How often is this data written?

• Who has access to it?

• How is it accessed?

• Is it just a database, or is there a UI?

• If there's a UI, what kind of visuals are there?

• Is it searchable? Filterable?

• What is the point of the audit log? Is it for security? Audits? Paranoia? Legal compliance?

• When someone is viewing the audit log, what are their goals? Why are they there? What are they looking for?

• Is there any reporting? Are there rule sets that trigger flags or alarms? Where are those managed? Who manages them, and how?

I'm sure if I asked all of you, I could triple the length of these questions. These are just the core, fundamental questions one would ask regarding a feature like this. Well, these are the questions one SHOULD have asked regarding a feature like this before promising to deliver it.

The budget was gone, time was up, and everyone was frustrated

When the day finally came to tackle these and so many more questions about the audit log, the budget was gone, time was up, and everyone was frustrated with the project. You see, this was only one of the hundreds of features that had been called out in bulleted lists in the contract without any real definitions, requirements, or criteria. Because nothing was clearly defined, every single task was a meeting requiring several hours of conversation between clients, project managers, scrum masters, designers, and developers. Everyone had their own interpretation of what each feature meant, and nothing was written down. Even when there were mockups to demonstrate how a particular feature might function, due to a lack of requirements regarding integration with other parts of the system, even fully-built "done" features were constantly tossed, re-written, broken, updated, and on and on.

The audit log would be one of the worst offenders. This project (that we inherited from another company and team) would take more than double the original budget, and 9 months longer to ship than originally "planned" (obviously, planning wasn't part of the setup process for this project). Even when it shipped, it lacked significant functionality the client had hoped for. Everyone was sad, tired, and spent.

This is a story about setting yourself up for success (or failure)

This is a story about setting yourself up for success (or failure). The good news is it's not really that hard to do when you do it at the right time. The bad news is it's really hard to do if you don't and can cause innumerable problems, heartaches, cost and time overruns, angry clients, and more. The recipe for success is actually pretty straightforward:

Define success

Set clear, articulated goals

Don't underestimate level/time of effort

Under-promise, over-deliver

Do you want your projects to be great? Make every client happy? Deliver everything on time, and under budget? Fantastic. Those four points are the key, the rest is execution. I don't mean to devalue execution, because frankly, it's everything. But as the saying goes, failing to plan is planning to fail, and all the great execution in the world can't save you from poor planning. Great outcomes are achieved when goals are clearly articulated.

What is the definition of success? This is the first (and often middle, and last) question I ask when we are proposing/planning/kicking off a new project. When we, as a team, are able to clearly define what success means to each of us, we can set up a project that will drive us towards that definition. No matter what state you're in, beginning, middle, or end, you can always look back at the definition of success and see if you're on or off track. When you're done, you can categorically point to the definition and say with confidence that you expertly delivered on your promise. Everyone wins. If you don't have a “success” definition, then it's constantly up for debate and redefinition. Clearly pivoting at crucial times is important. You may find that your original definition lacked wisdom or detail, or maybe you learned something new since then. It's okay to, as a group, redefine success when significant changes occur. What you do not want to happen is that everyone has a slightly different opinion as to what success looks like. When that happens, no amount of expert execution will make everyone happy, and the project will ultimately fail.

Clear, articulated goals pave the path to success

Clear, articulated goals pave the path to success. Now that you've defined your destination (success) you need a map to get there. That map is a list of clear, concise, detailed goals to break down "success" into measurable pieces. These are most often found in the form of BRDs (business requirements documents) and acceptance criteria in stories. For designers, our job is usually to uncover and place these landmarks and signposts to guide the teams that follow behind on the trails we blaze. Virtually every design tool (contextual inquiry, interviews, journey mapping, user study, usability study, heuristic analysis et al) are meant to mine the minds of stakeholders, users and more so we can collectively create specific goals that, all together, combine to form the product or service we're building. You skip any of these steps, and it's like taking shortcuts in the untamed wilderness. It's like telling someone to bring you a rock. They bring you a rock. You say no, that's not the rock I'm looking for, bring me another rock. Ad infinitum. Have you ever been on a project that was lead that way? I have. It's torture. Don't do it to yourself or others.

Slow is smooth, and smooth is fast

“But Brandon!” You exclaim. “All this takes time, effort, and money. We have to kick this off NOW! Aintnobodygottimeforthat!” Bless you, my sweet, summer child. The military has a nice little axiom for just this argument: Slow is smooth, and smooth is fast. This is truer in software than just about anything. Moving fast and breaking things may be fun at first, but it's costly, and we've already discussed what happens to projects that try to function that way. An old boss of mine used to say, “we need to slow down to speed up.” Sounds like The Sphinx from Mystery Men, but it's true. Stop. Think. Articulate. Define. Refine. Plan. Do these things, and your execution will be faster. But it won't just be faster, it'll be better, with fewer iterations necessary, fewer bugs wrote, fewer changes necessary. Spend as much time as you can sharpening your axe so you have to swing it less and with less effort.

Sometimes along the way, you discover the target has moved, or a million other things may have changed, and all that perfect planning is completely invalidated. Did you waste your time? No. First off, one of the reasons you're likely able to recognize that the plan/target/efforts are no longer valid is because it was so clear to begin with. You are able to recognize when something isn't right because you were following a map and you now see it was upside down. Fantastic! What a great time to slow down to speed up! Pause, reassess, adjust plans/definitions/budgets/timelines/requirements et al until things are back in alignment, then execute again with abandon! Slow is smooth, and smooth is fast! Don't cling to a mistake just because you spent a lot of time and money making it.

Measure before, during, and after

How can you know if you're off course, or if you're holding the map upside down? You know because you are constantly measuring what matters. You measure before, during, and after. You monitor. You keep your finger on the pulse of each element of the project, looking for signs of atrophy, necrosis, and rot. You're also looking for bloat, smell, and itchiness. These are all metaphors we use to understand the negative aspects of projects. I can't tell you how many times someone has said "this smells funny." And usually, they're right. If you're paying attention, monitoring, thinking, measuring, reflecting back on the plan, against the criteria, rechecking the definition of success, you'll spot things that are leading you astray, or are causing your project (and people) pain and suffering.

If it’s so easy…

So if it's so easy, why do seemingly good projects go bad? How did the audit log issue (and that project in general) get so far gone? Well, in my team's defense, we came in mid-project when everything was already on fire, and we just tried to land the project as quickly as possible before we ran out of fuel and/or burst into flames. We saw first-hand what it was like to try to execute on a project that skipped literally every single one of these critical planning steps (and some we didn't even address here). We did our best to move forward.

Looking back though, even then, we thought since it was already on fire, we just needed to finish everything as quickly as possible, rather than, you know, putting out the fire with good planning and definition. We felt that moving fast and fixing things was a better approach. We were unequivocally wrong. I can state with no hesitation that, if we were to go back in time and take on that project again, here's how we should have done it:

1. Pause all development

2. Define the actual scope (success) of the engagement and append it to the contract

3. Write out every epic, feature, story, and task with relative acceptance criteria

4. Require interactive prototypes, not annotated PDFs

5. Updated required budgets and timelines against new scope (success)

Once we'd adequately addressed these items, we could then allow development to proceed. I guarantee we would have delivered faster, more reliably, and for less money.

Now, as you go back to your projects, or begin the next one, don’t plan to fail by failing to plan!

Define success

Set clear, articulated goals

Don't underestimate level/time of effort

Under-promise, over-deliver