Begin with what you HAVE to do

I came across a short review of the book Rework by Jason Fried and David Heinemeier Hansson on Leading Blog this evening. In it, I found a few quotes that I really like, and wanted to share along with a few thoughts of my own while they were fresh in mind.

When you start anything new, there are forces pulling you in a variety of directions. There’s stuff you could do, the stuff you want to do, and the stuff you have to do. The stuff you have to do is where you should begin. Start at the epicenter.

For example, if you’re opening a hot dog stand, you could worry about the condiment, the cart, the name, the decoration. But the first thing you should worry about is the hot dog. The hot dogs are the epicenter. Everything else is secondary.

As someone working in the business analysis space, I instinctively interpreted the comment in the context of project scope definition and requirements gathering.

Now, I probably wouldn’t have chosen the hot dog stand example, but it works. And it’s very true. I’ve found that it’s much easier to start at the highest level – only considering the things we absolutely have to have (and without which, the project couldn’t possibly be a success), and working our way down from there than it is to start out in the weeds and try to pare off the “coulds”, “wants” and possible-implementations-expressed-as-requirements.

Getting infatuated with details too early leads to disagreement, meetings, and delays. You get lost in things that don’t really matter. You waste time on decisions that are going to change anyway. So ignore the details—for a while. Nail the basics first and worry about the specifics later.

Amen. I’ve also heard the concept referred to as “breadth before depth” (See Adolph and Bramble who, referring to patterns for use cases, advise that, “the more detailed your early endeavors, the more you will have to change them as you learn about the system.”)

The simple fact is, you can’t know all the details upfront. You can and should, however, be able to work with your stakeholders to identify the broader range of necessary capabilities and constraints, or “placeholders for conversations” (to borrow a term from Mike Cohn) to be held later, and during which details can be drawn out.

About the Author

Jonathan Babcock is a management and IT consultant with expertise in business analysis, process optimization and solution delivery methodology. Practical Analyst is his outlet for sharing what he's learned, and for interacting with solution delivery professionals across the globe.

Author Archive Page

1 Comment

    Post a Comment

    Your email address will not be published. Required fields are marked *