Define victory first...

"A smart rule of thumb to drastically increase the probability of project success"

“To begin with the end in mind means to 
start with a clear understanding of your 
destination. It means to know where 
you’re going so that you better 
understand where you are now so that 
the steps you take are always in the right
direction.”

Stephen Covey, The Seven Habits of Highly Effective People

In the book  Risk Savvy: How to Make Good Decisions, Gerd Gigerenzer describes the two sets of mental tools required for making decisions. When risks are known, good decisions require logic and statistical thinking. But when we are dealing with unknowable risks, good decisions also require intuition and smart rules of thumb.

As with many things in life, in most business situations unknowable risks abound. In the uncertain world of software projects, in addition to logic and statistical thinking, good rules of thumb are essential for good decisions.

As Gigerenze explains,

A rule of thumb, or heuristic, enables us to make a decision fast, without much searching for information, but nevertheless with high accuracy.

Amazon has a great example of a rule of thumb to help increase the likelihood of project success: if a project team can eat more than two pizzas, it's too large. The thinking behind this rule is that dividing a big problem into smaller chunks makes it easier to grasp, analyze, and solve. Smaller problems can be tackled by smaller teams with less process and overhead, and require smaller solutions that are easier to understand, test, and implement.

It goes without saying that one rule of thumb will not solve all problems. The most successful business analysts I know have developed a “toolbox” of rules that they apply along with their critical thinking to identify what tool to use for what problem. Still, there are rules of thumb that are universally applicable. Here’s one of my favorites, which consistently helped me deliver successful projects in my career as a lead BA:

Only start writing requirements when you have a clear definition of victory.

As obvious this rule must sound for many people, starting a project with a clear “definition of victory” (an expression that comes from Mark Fuller’s Business as War) is, in practice, still a rarity. In fact, I’m convinced that ignoring this rule, along with some version of Amazon’s “two pizzas” rule, is the top reason for studies reporting a success rate of only 6.4% in projects with labor costs of $10 million or more.

A few years ago, I had to interview a couple of executives of a Fortune 100 company to figure out how to fix an expensive executive dashboard that was nice looking but didn’t provide valuable data. As soon as the meeting started, the executives began to recite a rambling list of features and capabilities, and what they thought needed to change in the chart filters and colors. As much as I tried to change their focus, they struggled to state what business questions they wanted the dashboard to answer. No wonder why the original project didn’t yield the desired results! As soon as I extracted from them a crisp statement of the exact problem they were trying to solve (for example, quickly determine the relative over- and under-spend of business units), the discussions about chart types and colors became moot. With clarity about what victory looked like (“show a clear story of which units are the worst offenders at both ends of the spending scale”) it was easy to put specialists in data visualization and user experience in charge of designing a nice chart that offered the executives what they needed. The new dashboard was a huge success, with user adoption going from less than 15% to almost 90% of the intended audience.

Still, no matter how many articles are published about the importance of having clear objectives, and using tools like premortem and the 5 whys to get clarity about what you are trying to achieve, I keep seeing BAs and project stakeholders ignoring this rule of thumb over and over. It’s just simpler for the human brain to “jump into solution mode”, and focus on whether the first release should include a weekly or monthly calendar, or the executive dashboard would look better with a bubble or a spider chart in it. Nobody wants to delay execution by pausing to get to the real problem first, and that’s were things start to go terribly wrong.

What happens in projects that don’t follow the “define victory first” rule of thumb is similar to having a prep cook in a restaurant who is asked to dice tomatoes, without explaining why (the chef was planning on offering a sea bass recipe as a special dish that day). Because the cook wasn’t given a definition of victory, if news arrive that the sea bass delivery was canceled, he'll not be able to make an informed choice to stop dicing the tomatoes (or at least confirm with the chef that's still a value-adding task to perform).

Regardless of the focus of a software project (from building relatively small custom software to a product sold to millions of customers), and the approach used (traditional, agile, hybrid), establishing a common purpose for the team before work starts is a crucial step. Without it, like the prep cook, team members will end up distracted by aspects of the solution that aren’t aligned with the end goal, and won’t be able to quickly change and adapt when the situation requires course-correction.

As a business analyst, how often have you used your influence to convince your stakeholders of the importance of developing a clear definition of victory for their project before specifying its requirements? While this rule alone cannot guarantee success, it minimizes project risks by answering the hardest and most critical question first: “exactly what problem will this solve?”. Armed with clear knowledge of what roaring success will look like, your team will have a much firmer groundwork to accomplish the end goal.