After years of interviewing management consultants, product managers, business analysts, solution architects, and other solution definition and delivery roles, these are the seven things I look for.

1. Initiative

Each individual owns his/her personal professional journey, and is accountable for setting professional development goals, and making plans to achieve them.

In an interview, I ask candidates about what they’ve done on their own to learn more about and get better at their craft.

• What have they read lately?
• Are they active in professional networking or development organizations? What do they do beyond what’s required?
• Do they expect their employer to “develop them,” or to enable a plan they already own?
• If hired, how would they ramp up quickly in a new environment?

The answers tell me whether I’m hiring someone who drives their own growth, or someone waiting to be driven.

2. Poise

I ask behavioral questions about hypothetical, difficult situations — not to see if candidates get the “right” answer, but to watch how they think. This kind of questioning pushes people off the happy path and out of the realm of rehearsed talking points, forcing real critical thinking under a bit of pressure.

How a candidate responds in that moment is usually a good preview of how they’ll respond to pressure on the job. And since resume screening has already filtered for experience and keywords, behavioral questions are where candidates who look identical on paper start to separate.

3. A grounded definition of success

Many consultants and solution delivery professionals have been conditioned, over time, to equate success to hitting a milestone by a deadline. While that may be one potentially useful data point, there is so much more to being successful. I often ask questions like:

• Can someone in this role be successful even if the overall project isn’t? How?
• How do you define success for the team, and for yourself in this role?
• You often don’t directly produce a usable or marketable product. So where does your value to the organization actually come from?

Candidates who have thought about this give me confidence they’ll make good judgment calls when the plan and reality diverge – which they always do.

4. Fit – in both directions

Diversity of ideas and approaches makes teams stronger. But sometimes it becomes clear in an interview that a candidate’s personality and ambitions simply don’t align with the team or the organization. Better to discover that now than six months in.

Fit cuts both ways, though. As the hiring leader, it’s on me to be transparent when candidates ask about the team and the organizational context, so they can judge whether they’ll be comfortable and able to thrive. I tell candidates directly: this interview is bi-directional. We’re evaluating fit for us; you should be evaluating fit for you.

5. Agility

The solution delivery role is increasingly defined by versatility. Whether the environment runs a classical serial approach or an agile delivery method, I want practitioners who are comfortable applying the fundamentals — planning, definition, delivery — in any of them.

A candidate without deep agile experience can still succeed if they can speak to the fundamentals and the philosophical differences between delivery methods, and to how solution definition and delivery fit into each. I’m hiring for the principles, not the nuances of ceremony.

6. Passion

I want to see genuine professional passion for the work. I appreciate candidates who talk about the value of what they do and the satisfaction of doing it well — who get animated describing the work they’ve done and the difference it made.

I’m wary when a candidate’s recent experience is only tangentially related to the role, because it suggests this job may be a stop-gap until something preferred comes along. To be clear: enthusiasm doesn’t trump capability. But all else equal, give me the person who loves the work.

7. An effective resume

Solution delivery professionals are — or should be — communication experts first. We facilitate mutual understanding, in writing and in person. So I treat every candidate’s resume as a work product and hold it to the same standards I’d apply to a project deliverable.

The resume is a sample of the written communication and documentation quality I can expect. And because the candidate wants the job, I assume it represents their very best work. I look for a resume tailored to the role, with emphasis on the qualities, attributes, and outcomes that matter for the position as posted. A generic resume for a communication-centric role tells me something, too.

I believe that most solution delivery professionals are, or should be, first and foremost, communication experts. We must be able to facilitate mutual understanding through both spoken and written means, With that, I treat each candidate’s resume as a work product and hold it to many of the standards I would use to evaluate a project deliverable.

Whether you’re a manager working out how to identify strong candidates, or a candidate trying to understand what hiring managers are screening for, these seven signals should serve you well.

If this were your list, what would you add or change?

Back then, “data-driven decision making” was still a novel phrase. Business analysts were fighting for a seat at the table. “Agile” was mostly a new buzzword. The iPhone had just been announced. And I had a simple belief: that the people doing the actual analytical work inside organizations deserved better thinking tools, honest advice, and a peer who’d been in the room.

I also knew that to sharpen my own understanding, it would help to put my ideas out for consumption and feedback – comparing my experiences and insights with those of other practitioners.

So I wrote. For about eleven years, I wrote. And it turned out to be a great opportunity to learn, make meaningful contacts, and drive opportunity.

And then, somewhere around 2018, I got quiet.

What happened

There was no single reason for stopping. There was no crisis. It was a mix of things, none of them dramatic.

Life got busier. My work at Jabian Consulting deepened. The projects got larger, the client demands more complex, family life with four kids got busier. Writing took time I didn’t have, and it kept sliding to the bottom of the list.

I also lost clarity on what I was writing for. When I started Practical Analyst, my audience was clear to me: business analysts and product professionals trying to do their jobs better. But my own work had evolved. I was spending more time on transformation strategy, leadership, organizational change. I wasn’t sure how that fit with what I’d built here. So instead of figuring it out, I just… stopped.

And honestly? Once I stopped, the habit broke. The longer I waited, the harder it became to start again. I think most writers know this feeling. The blank page gets heavier the longer it sits.

Eight years is a long time to be quiet.

What changed

A few things converged this year that made me want to start again.

One is that I’m closer to the end of my corporate career than the beginning — probably eight or nine years out from retirement — and I find myself thinking differently about what I want the next chapter to look like. Not passive. Not just gone. Something where the thinking I’ve done over 25+ years in this business continues to be useful to people, just on different terms.

The second is AI. I’ve watched enough technology waves crest and break to be genuinely skeptical of hype. But this one is different in ways I find worth writing about honestly — not as a cheerleader, and not as a fearmonger, but as a practitioner who’s been using these tools daily and has opinions about what’s real and what isn’t.

The third is simpler: I’ve been talking to people — peers, former colleagues, clients — and the conversations keep going somewhere interesting. There’s something worth putting down.

What’s coming

I’m relaunching the Practical Analyst site with a sharper focus and a real commitment to showing up consistently.

The audience has always been business professionals trying to think more clearly and work more effectively. That hasn’t changed. But the lens has expanded from where it started. I’ll be writing for mid-career analysts, consultants, product managers, and executives who are navigating a business environment that’s changing faster than most conventional wisdom can keep up with – with occasional foundational topics for junior practitioners.

The content will center on four areas:

• Business transformation and strategy — what change actually looks like from inside organizations, why most transformations stall, and what separates the ones that don’t.
• AI and the future of work — honest, practitioner-level takes on what’s actually changing, what the hype machine is getting wrong, and what you should be paying attention to if you work in a professional services or knowledge-work environment.
• The craft of analysis and problem-solving — the thing this blog was always really about. How to think through hard problems, structure ambiguous situations, and communicate clearly when the stakes are high.
• Career and leadership — what I’ve learned about building a meaningful career over a long run, navigating the transition from practitioner to leader, and designing the back half of a career on your own terms.

Two posts a month is my initial goal, and we’ll see where things go from there.

A note to people who’ve been here before

If you subscribed years ago and forgot this place existed — welcome back. If you’re finding it for the first time — the archives go back to 2007, and some of that older work still holds up.

Either way, I’m glad you’re here.

Practical Analyst begun as a place to provide helpful insights to the people doing the work. Let’s get back to it!

– Jonathan Babcock

If you want to make sure you don’t miss future posts, subscribe to the newsletter. Two posts a month, straight to your inbox.

Management refers to the ongoing coordination, traceability, and adaptation of requirements throughout the solution lifecycle. It’s how we maintain continuity and alignment, even as goals, constraints, and decisions evolve.

“You can’t control the wind, but you can adjust the sails.” – Unknown

Requirements aren’t static assets. They’re living commitments. Managing them well ensures that the intent captured early remains intact after contact with delivery, change, and real-world complexity.

Think of requirements management like gardening: You don’t just plant once and walk away. You prune, water, and adapt to the environment to make sure what you’re growing is healthy and still worth harvesting.

Best practices for effective requirements management:

• Establish traceability. Link requirements to goals, design decisions, and tests.
• Monitor change proactively. Ensure updates ripple with awareness and intent.
• Continuously prioritize. As context changes, so may the priority and focus.
• Communicate impact. Surface the effects of changes before they become issues.
• Right-size the rigor. Govern just enough to protect value, without bogging down momentum.

Requirements evolve. Management is how we evolve with them, without losing our way.

Wrapping Up the EASVM Series

EASVM is only a framework, but with effort it can develop into a mindset for delivering clarity, alignment, and confidence at every step of solution definition.

• Elicitation starts the journey with curiosity and conversation.
• Analysis brings meaning and structure to complexity.
• Specification captures shared understanding in forms we can act on.
• Validation ensures we’re aligned before we invest.
• Management keeps it all connected, current, and on course.

Together, these disciplines create the conditions for success, not just in delivery, but in stakeholder engagement, strategic alignment, and meaningful results.

Thanks for following along! I hope this series has sparked ideas, clarified concepts, or simply reminded you of the importance of solution definition.

Let’s keep the conversation going!

Validation is the practice of confirming that documented requirements accurately reflect stakeholder intent, align with business needs, and are feasible for delivery.

“We accomplish what we understand. If we are to accomplish something together, we need to understand it together.” – attributed to Ron Jeffries

Here’s the thing: validation shouldn’t be a heavy lift. If we’ve done elicitation, analysis, and specification collaboratively, stakeholders won’t be seeing the requirements for the first time; they’ll be recognizing what we’ve already discussed, clarified, and agreed to.

At that point, validation becomes a confirmation, not an investigation.

It’s also an opportunity to improve. Constructive feedback in validation doesn’t mean we failed; it means we’re learning, refining, and getting closer to delivering something useful and valuable that will enable our counterparts to design, build, and test the resulting solution.

Best practices for effective validation:

• Engage the right people. Validate with users, implementers, and decision-makers – not just approvers.
• Use real scenarios. Walk through examples or simulate usage to expose gaps and assumptions.
• Keep it conversational. Validation works best when it feels like a working session, not a formal audit.
• Focus on outcomes. Validate not just the content, but its alignment to the defined success criteria.
• Welcome rework… early. A revision in validation is many times cheaper than a redesign after deployment.

Validation is a checkpoint, not a choke point – when we build understanding as we go.

See other posts in the EASVM series:

• Elicitation
• Analysis
• Specification
• Management

Specification is the process of representing business or customer needs in a form that is clear, precise, and actionable for diverse audiences, from developers and testers to business stakeholders.

An appropriate and complete requirements specification does nothing to ensure a successful implementation; however, it makes it possible. – Kulak & Guiney

That’s the heart of it – specifications have no inherent value. Their worth lies in how effectively they enable others to understand, design, build, test, and deliver solutions that meet real needs.

A good specification doesn’t replace conversation; it recaps it. It’s not the start of communication, but the artifact that reflects the shared understanding reached through elicitation, analysis, and eventually, validation. It’s how we codify what we’ve agreed upon in a way that provides for traceability and consistency throughout the solution delivery process.

Best practices for effective specification:

• Tailor to your audience. Developers, testers, and sponsors each need information framed in their way. Write your specifications with their needs in mind.
• Be concise, not cryptic. Brevity with clarity beats exhaustive detail that no one uses.
• Visualize whenever possible. Diagrams, mockups, and flow diagrams communicate more than text alone and bring precision to combat the ambiguity of natural language.
• Connect to outcomes. Trace specs to the goals they support and the success criteria they serve.

The goal isn’t to create deliverables. It’s to create alignment and to enable action.

See other posts in the EASVM series:

• Elicitation
• Analysis
• Validation
• Management

Analysis is the process of examining inputs: needs, data, conversations, constraints, and transforming them into meaningful, actionable insights. It’s how we uncover patterns, evaluate options, and connect the dots across domains.

In solution definition and delivery, this is where understanding becomes structure, and where misalignment is exposed before the cost to fix it grows exponentially.

Best practices for effective analysis:

• Ask “why?” and “so what?” Go beyond the stated need to understand its drivers and implications.
• Use models to think. Flows, maps, and diagrams aren’t just communication tools; they’re thinking tools.
• Balance detail with relevance. Zoom in where it matters, zoom out to see the whole.
• Engage others in sense-making. Analysis is strongest when it’s collaborative, not solitary.
• Trace decisions to outcomes. Link requirements to business goals to maintain focus and value alignment.

“The perfect is the enemy of the good.” – Voltaire (attributed)

But beware—analysis isn’t about perfection, it’s about momentum. Think of analysis as sharpening a blade: It needs to be sharp enough to cut cleanly, but if you keep honing forever, you never get to the cut.

A good analyst doesn’t just capture complexity; they clarify it. The goal isn’t more information. It’s better decisions.

See other posts in the EASVM series:

• Elicitation
• Specification
• Validation
• Management

I learned about EASVM in a requirements training I did early in my career, and it has stuck with me since. Who does each element, how long they take, and what we call the outputs vary depending on delivery methods and other factors. But to create quality requirements or to perform discovery well, we’ll want to address them all. Too often, we focus on one part (usually documentation) and downplay the rest.

EASVM. Each element plays a distinct role:

• Elicitation brings needs to light.
• Analysis gives them shape.
• Specification makes them actionable.
• Validation ensures we’re aligned.
• Management keeps it all on track.

Let’s talk a little about each element, what it includes, and why it is important, beginning with Elicitation.

Elicitation

“The biggest problem with communication is the illusion that it has been accomplished.” – George Bernard Shaw

So many delivery issues trace back to this illusion.

Elicitation is the intentional act of discovering, uncovering, and clarifying information through structured interaction. It’s not just about asking questions – it’s about making meaning visible.

In solution discovery and definition, elicitation is the foundation of shared understanding. It ensures we uncover not just what stakeholders say they need, but what they mean, what they value, and what they may not have thought to express.

Here are a few best practices for effective elicitation:

• Set the stage. Build trust and context before jumping into techniques. A stakeholder who feels heard will be more forthcoming.
• Diversify your methods. Don’t rely solely on interviews. Observation, workshops, prototypes, and surveys each reveal different layers of insight.
• Listen between the lines. Pay attention to what’s not said, and follow up on inconsistencies or assumptions.
• Visualize early. A sketch on a whiteboard often reveals more than an hour of discussion.
• Iterate often. Revisit and refine as understanding deepens – early alignment prevents downstream confusion.

The goal of elicitation isn’t documentation – it’s clarity. Because communication isn’t complete until understanding is mutual.

If communication is the currency of collaboration, elicitation is how we keep it honest.

In the related posts linked below, I break down the remaining elements: Analysis, Specification, Validation and Management. For each, we explore what it looks like in practice, why it matters, and how it contributes to shared understanding and better outcomes.

• Analysis
• Specification
• Validation
• Management

Let’s demystify the real work of discovery – one step at a time!

The topic of our conversation was the “essence” or underlying “why” of business analysis, and how focusing on that “essence” or “why” can benefit the individual analyst, and the organization as a whole.

At the end of the podcast, Dave also mentioned I’ll be speaking at this years Building Business Capability conference in Las Vegas. If you’d like to join me there, use my speaker discount to get 10% off the registration cost. Just enter the code “SPKLVJBAB” when prompted to get the discount.

If you’d like to listen to the interview, here are a few ways you can access it. I’d be interested in your thoughts and feedback!

Mastering Business Analysis website: http://masteringbusinessanalysis.com/episode71

iTunes: https://itunes.apple.com/us/podcast/mba071-essence-business-analysis/id961865564?i=1000368375970&mt=2

Stitcher Radio: http://www.stitcher.com/s?eid=44220947

These models and visuals can and should be used as tools for eliciting requirements and driving to shared understanding; as ways to facilitate working discussions on topics for which we are seeking clarity. Start simple, start messy. Use the process as one of “collaborative creation”. When we draw on the whiteboard together – or model a process flow together – all parties walk away with the dialog and context for how we arrived at the end image. If we don’t see things the same way at first, we draw and discuss and deliberate until we achieve that elusive shared understanding.

The tacit knowledge – or knowledge that comes out in the dialog and sketching, but isn’t captured in the final documentation – is often a critical gap or missing link between business analyst and stakeholder that limits the success of our efforts.

I’ve found that the process of deliberating and rationalizing potential paths together with business and delivery stakeholders until we reach an agreed upon “best way forward” provides the real value in visual modeling.

“The chief virtue that language can have is clearness, and nothing detracts from it so much as the use of unfamiliar words.” – Hippocrates

Apparently, even back in Hippocrates’ day (approximately 450 BC), business professionals had a tendency to confuse their stakeholders with acronyms, jargon, and odd colloquialisms. In business communication, first and foremost in importance is achieving mutual understanding. Some may be able to follow jargon or sophisticated phraseology, but one stands a far better chance of ensuring understanding with clear, simple, common language. Some things never change!