Smarter ideas worth writing about.

Navigation Skills for Business Analysts: Part I - Plotting Your Position

What do Tropical Climes and IT Projects Have in Common?

My first sailboat charter in the British Virgin Islands was my favorite vacation ever and an opportunity to enhance the sailing skills I had developed here in Central Ohio. While most of these translate to a large boat in the Caribbean in that sailing is just a series of tacks and jibes, the main difference I found between the two experiences was the application of my navigation skills. On our local inland lake, navigation consists of pointing at something on or near the water and saying to the crew, "Let's sail over there." In the BVIs, however, coastal navigation skills are critical to getting your vessel safely to the next harbor (and some would argue, more importantly, your crew to happy hour on time). 

While fondly remembering that vacation during Ohio's cold winter months, I realized that some of the same principles of navigation have an equivalent skill in the realm of business analysis. Just like on my inland lake, some projects are pretty much "point and go" while others require the BA equivalent of a compass, a sextant, and some sturdy sea legs. For those times when your project is like the waters of the BVIs (minus the sun and frivolity), let's take a closer look at some navigation skills that can help you successfully pilot yourself and your project teammates through challenging waters. In this first of a series of articles, we will explore the concept of plotting your current position relative to your team or project's overall objective.  
 

Identifying the 'You are Here' Spot

Before GPS technology became a mainstay on both land and water, identifying one's position on a marine chart required advanced navigation skills. The coastal version of this process involves taking two or more "sightings" on fixed terrestrial objects like a tower or mountain peak and then using triangulation to plot one's position on a chart. And you thought estimating the effort of a complex application development project is difficult? Try – in the literal sense – adding fickle winds, tidal currents, and the occasional squall to the equation.  

As a BA leading others from the origin to the destination of a complex project or release, it can be very helpful to regularly determine and communicate your position relative to surrounding milestones and the overall business objective. With a mind for the big picture as well as the details, the BA is uniquely qualified to accurately pinpoint the team's position. One proven technique to accomplish this is referred to as "taking a checkpoint," and it consists of describing the most recent milestone, the next milestone, and the next steps to be taken to get there.  

When you take a checkpoint, you are essentially describing the map of the project and then identifying the 'you are here' spot on the map. You can adapt this technique for use within a waterfall project or during an iteration or sprint. It differs from the way a Project Manager might check in on project status in that it occurs informally in the moment and is simply used to provide context as the work continues to progress. I use this technique so frequently that it has become a natural part of my personal style in leading business analysis and related activities. One instance when it was especially valuable in practice was during a software design project that introduced a new online bill payment feature. To determine the true minimum viable product for the new feature, the design team intended to incorporate user testing in each iteration of the evolving design and a variation on hypothesis-driven development. During the first iteration or two, I incorporated checkpoints all along the way to keep the team moving confidently and efficiently towards our mutual objective. Here is an example of what one of those checkpoints sounded like: "Okay, team. We just finished prototyping the new feature and identifying our riskiest assumptions about the MVP. Our next steps on the way to baselining the design are to define the user testing scenarios, conduct the testing, and iterate our requirements based on the results. Is everyone ready to spend the next forty-five minutes defining our test scenarios? Let's get started!" 
 

Conclusion

Business Analysts strive to deliver value all along the way to the distant shore where a project's ultimate value is manifested. Providing your teammates with the clarity of your plotted position delivers value while also keeping the distant (but fast approaching) shore in sight. Used effectively and at the right times, the checkpoint technique can be used to reduce uncertainty among your teammates and move the group in an orderly but spirited fashion towards your destination. In the next article in this series, we will explore the concept of plotting the proper course towards that shore and provide suggestions for what to do when one's course is called into question by a key stakeholder. 


Share:

About The Author

Business Analyst
Christy is a Principal Consultant and Business Analyst for Cardinal's Columbus office. Her experience includes developing business analysis organizations and communities of practice. Her passions include continuous improvement... and cruising & racing sailboats in Central Ohio, the Great Lakes, and the Caribbean.