Stand Back and Deliver: Interview with Kent McDonald

Kent has been doing business analysis activities in some shape for 15 years and held the BA title for the first time 12 years ago. He is currently trying on the title “Business Advisor” at his own company – Knowledge Bridge Partners - a Business Analysis consulting, mentoring, and training company. His goal is to raise the level of business analysis and change its focus from documenting requirements to understanding problems and identifying solutions.

Kent introduced me to the book he co-authored Stand Back and Deliver, this summer. I immediately purchased a copy and have since used the models to improve my approach to projects at Bridging the Gap as well as in my consulting engagements. It’s one of those books I’ll go back to again and again and I may at some point pre-order a stock of them in my closet to give to all my consulting clients. I had the opportunity to speak with Kent just before the holidays and clarify a few of the concepts in the book.

On becoming a BA

Laura: First things first, how did you become a business analyst?

Kent: With a degree in industrial engineering, I first worked at GM for 3 years in an engineering program management role. My wife and I decided to move back to Iowa and, not finding much of the auto industry in Iowa, I made the switch to IT. That’s when I learned about the business analyst title from a recruiter. I discovered that some of my engineering work, such as costing out engineering changes and defining requirements, was very closely aligned to business analysis. At that point, BA was positioned as a role to lead me back to project management in a new industry. In just the last year, I confirmed that my heart is really in business analysis.

Laura: Well, we’re excited to have you Kent. I always like to hear stories of project managers finding senior level careers in business analysis. People like you help showcase the possibilities in the business analysis profession.

Conceptualizing Stand Back and Deliver

How did the idea for the book come about?

Kent:  The four of us met through our involvement in the agile community. We started to talk about a collection of models to help organizations implement strategy and how certain projects were best handled by certain approaches. My basic philosophy is that there is no “one size fits all” approach to delivering projects. Eventually, we realized we might have the basis of a book. As we talked about crafting the book around these models, we decided that it would fall short if all we did was explain the models. We chose to pull in real stories from our project work and explain the subtleties of each model with examples.

Laura: What was the writing process like?

It was a distributed writing process.  I live outside of Des Moines, Iowa.  Pollyanna, an executive consultant, and Niel, a VP of Strategy (and formerly a CIO) both live in Salt Lake City; and Todd, a Sr Development Manager, lives in Houston. We met once to organize how we were going to describe the tools and loosely organize the book, then we went off and drafted chapters, after which we got back together and tested the drafts against the acceptance tests.

The initial drafts were completed in a couple of months and then we spent about 8 months iterating and refining our ideas.  Being the least experienced of the group (this coming from someone with 15 years experience in business) I gained a lot from hearing, talking through, and debating the relevance of the stories in the book.

We continue to be very good friends and often ping each other when we have a situation we need to talk through. I continue to find new subtleties of the models and learn more about our approach through my consulting work.

Laura: Who is the book written for?

Through our involvement in the agile community, we realized that agile would not get fully adopted in organizations unless there was a certain style of leadership in place – we refer to it as collaborative leadership — but agile at that point seemed to de-emphasize leadership.  The book is primarily written for organizational leaders – Portfolio Managers, VPs, etc.

One of my goals is to bring these tools to Business Analysts and, in the process, expose them to more strategic levels of thinking.

The Purpose Alignment Model

Laura: One of the most valuable pieces to me was the Purpose Alignment Model. I actually drafted this for Bridging the Gap. Can you tell me a bit more about it?

Kent: This model is especially helpful for BAs. Essentially this model looks at the various activities of your organization and guides you to use purpose to identify the activities (and the projects that support them) that truly create differentiation in the market for your organization (ie would we advertise this on a billboard?).  These are the projects where you should apply extra inventiveness and creativity to doing the activity in the best way possible. The rest of the projects support activities where you should achieve parity, should not be doing at all, or are handled by partners. What we typically find is that most projects should be driving to achieve parity. Just a handful of activities are really differentiators in the marketplace.

But in our projects we get stuck. It’s easy to slip into the trap of assuming every system needs to be best in class. This leads to scope creep and analysis paralysis.

Laura: Yes, speaking from personal experience with the model, even though I’m technically the “stakeholder” for every process, it was hard to say that certain processes should be focused on parity and nothing more.

Kent: Yes, it is definitely a challenge. And, parity processes are still mission critical, so it’s not a reason to stop investing in those areas. But it is a reason to reduce complexity and uncertainty by simplifying projects and approaches.

Complexity vs. Uncertainty

Laura: You write in the book about leaders being naturally drawn to complexity or uncertainty. Are there certain patterns you see in business analysts?

Kent: The talk about leaders being drawn to complexity and or uncertainty is part of the discussion about the Context Leadership Model.  The key idea behind this model is to let the characteristics of a project help you determine your leadership approach.  So as a business analyst, if you find yourself leading projects, this model will help you determine your preferences and understand which type of project you are better suited to lead.

For example, if you find yourself being interested in keeping track of all the details surrounding interfaces with other systems, in depth data, or making changes to existing “legacy” systems, that’s a good indication that you may prefer working through complexity and would be well positioned to work on Cow (high complexity) type projects.

Laura: Yes, that part resonated with me. As I look back through my BA career I can definitely see where I focused on the hammering through the complexity of the project.

Kent: If on the other hand, you are comfortable with ambiguity, and can propose solutions with little information, you may be suited for colt projects (these are projects with high uncertainty and are best suited for agile approaches).

Laura: This is a great touchstone for BAs as leaders. I could see how your preferences could mislead you if you are not aware of them.

Kent: Yes. If you are assigned as a BA on a new product and your tendency is to deal with complexity, you could lead the project into the complex details without resolving some of the uncertainties. If you are aware of your preferences, you can consciously modify your approach and respond accordingly.

Since senior business analysts will be comfortable dealing with either ambiguous requirements or complex interfaces and can “ride the bull” as it were (bulls are projects that have high complexity and high uncertainty), you can use this model to inform your professional development planning.

Exploring “the last responsible moment”

Laura: One concept you write about in the book and that I struggle to apply in practice is this idea of “the last responsible moment.” I expect it’s counter-intuitive for many BAs. My tendency is to want to make the decisions as early as possible, reduce the uncertainty, and keep the project moving. What are your thoughts on this?

Kent: We have taken to describing the last responsible moment as the point at which your options start to disappear. The competency involves having enough confidence in your abilities to identify the point where you can gather as much information as possible, while still having as many options open as possible.  The difficulty is resisting the pressure to decide now, when you really don’t need to.

As an example, I was working as a BA on a project with an outside vendor and we were uncertain of their ability to deliver on time.  Some team members wanted to bring the development work in-house.  After considering our options, we learned that we could give the vendor 4 weeks and if they did not deliver we’d still be able to step in and meet the project deadline. So, we deferred the decision. The vendor delivered on their commitments and we saved a considerable amount of time and money.

Laura: For a BA looking to build this competency, would you suggest they start approaching all decisions from the perspective of “how could I defer this decision?” instead of “how could I make this decision?”

Kent: That works. I also try to ask myself “do I have to decide today?” This idea is critical for business analysts, because it helps them to gain a good  understanding of the problem and possible solutions without falling into analysis paralysis.

Starting conversations about value

Laura: Another insight I gained from the book was this idea of replacing a numbers-driven decision-making process with a conversation about value. I doubt I’m alone when I share that I’ve been frustrated by watching decisions be informed by pure numbers, when those numbers didn’t seem to tell the real story or proved to be inaccurate. Can you share a bit more about your approach?

Kent: Yes, I think we are still working on fully understanding this.  The idea that the value delivered by a project is best thought of as a conversation, not a number, is key.  I think we have all fallen into the trap that since cost is apparently so easily measured then benefits must be easily measured as well.

I’ve had a couple of epiphanies on this subject since working on the book. First, building a model for understanding the value delivered by a project is critical because the picture of value will change as the project proceeds.  Estimates of cost and benefit at the beginning of a project are based on several assumptions which will prove true or false as the project proceeds.  Building a model allows you to revisit your understanding of the value to be delivered as your information becomes clearer.

Laura: Yes, I see a powerful role for business analysts here. Kitty Hass talks about the “living business case” in which a BA is overseeing the ROI of the project throughout delivery and helping course correct.

Kent: There is a definite need for course correction. And sometimes it makes sense to cancel a project once you’ve started it. This is often seen as a failure, but in reality it is a success. If you are making the best possible decisions at the last responsible moment and revisiting decisions based on new information, you are not failing, but succeeding.

Building on this, just recently, the true place of projects aligned with strategic plans has become clear to me.  Projects more often than not are intended to introduce some sort of change.  Hopefully a project moves the organization closer to some organizational objective, either by improving a process or system or introducing a new project or service.  At the end of the project, the desired objectives may not be met because the results of the project have to be in place for certain amount of time for results to be seen. Or, the results of one project indirectly impact the desired objective.

Measuring business objectives at a project level is a red herring – you’ll rarely see the results you want.  Rather, you want to measure progress toward the business objective, and understand how projects are aiding to progress of reaching those objectives.  Portfolio decisions become centered on what project(s) will position us to meet those objectives.  Project level decisions focus on whether or not are we moving in the right direction for meeting these objectives.  The need to answer these questions point to the need for someone on the project who understands the business, the desired objectives, and how the project can point to those objectives.  This is the type of value add that BA’s should be striving to provide.

Laura: Yes, I can see how this firmly positions the BA role “outside the project” and working on behalf of the organization.

3 main take-aways

I think many BAs who find themselves in these higher level roles feel like they are charting new territory. Your book really gives them some techniques they can apply right away to help make the most of these opportunities. Is there anything specific you would hope a BA would take away from your book?

Kent: Start by adding these tools to their tool kit.  Especially helpful for BA’s are the Purpose Alignment model, the collaborative process (great for all kinds of elicitation activities), and the idea of the value model.  The context leadership model is also helpful for understanding one size does not fit all.

Second, let the context guide your approach: one size does not fit all, do not design all features the same.

Finally, take a more structured approach to decision making – while you may not be making decisions, help guide your project sponsor through their decisions by clearing stating what the decision is; understand what your options are; know when your options expire (are no longer options) do not decide until then, and use the intervening time to gather as much information as possible.  Change it from “I won’t decide yet” to “I’ll decide when.”

Laura: Thanks Kent. It’s been great speaking you today. I highly recommend that BAs check out your book and your forthcoming blog.

Kent: Thank you Laura for the opportunity to talk about the ideas in my book, and for all of the great resources you provide to BA’s on Bridging The Gap.

By Laura Brandenburg. Laura Brandenburg is passionate about business analysis. She's found her niche helping aspiring business analysts find transferable skills and position themselves in the BA job market. To stay up-to-date on the latest from Bridging the Gap be sure to sign-up for our free email course and weekly eNewsletter. View more blog posts by Laura Brandenburg

Related posts:

1. Deliver results: Ten reasons to read (or re-read) Good to Great
2. What BAs can learn from stand up comedy
3. Is clutter holding your career back?