Practical Analyst

Survey: Help a BA (Mentor) Out!

2010-08-11T17:04:44-07:00

Alex Papworth, author of the Business Analyst Mentor blog, asked if I’d spread the work about the brief survey he’s conducting to help him gain insight on the following key questions (I paraphrase):

What are the problems that business analysts face every day? What is it that really bugs you? (i.e. what are your objectives?)

If the solution to this involves professional development, how is that best delivered to suit your circumstances? This covers things such as convenience, available time, training style, instructor access etc. (i.e. what are your constraints?)

Alex is a good fellow and has been working dilligently to develop training that is valuable to business analysts, so I’m more than happy to oblige him. If you have a few minutes to spare, please go pay him a visit and take the brief survey.

View the original post or comment on Survey: Help a BA (Mentor) Out!

Be an Unselfish Business Analyst!

2010-08-09T18:25:05-07:00

Business analysts ought to be unselfish communicators.

What do I mean? To explain, I’ll cite a presentation by Dr. Michael A. Covington entitled, “How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily“.

I try not to be too superlative with my recommendations, but if you have not had a chance to page through Dr. Covington’s presentation, you really, really ought to. You’ll enjoy it, and you’ll almost certainly benefit from it. I know I did both.

In the presentation, Covington presents the concept of “The Unselfish Perspective”. I quote:

Good writing is partly a matter of character.

Instead of doing what’s easy for you, do what’s easy for your reader.

I’m not giving this presentation (or writing this paper) because I’m important.

I’m not going to demand that you put up with my quirks (bad spelling, bad organization, sloppiness).

I’m going to package the information so that it enters your heads as easily as possible.

Those, my friends, are words to live by! It isn’t enough to document things accurately and completely, although it is critical that we do. To increase the chances of delivering a successful solution, we ought to make it as easy as we can for our business stakeholders and delivery team members to understand and reach agreement on what success for the effort looks like.

In other words, you may be a great facilitator, an excellent “elicitor” of requirements; your analytical skills may be second to none, but if you can’t package and present information in an easily usable form, then you’re not really carrying the business analysis effort to completion.

So, borrowing/adapting the words of Dr. Covington, I give you the creed of the unselfish business analyst:

I will be an unselfish business analyst.
Instead of doing what’s easy for me, I will do what is easy for the reviewers and users of my deliverables.
I am not specifying requirements because I am important, but because those who will use them to deliver solutions that satisfy the requirements are important.
I will not demand that users of my requirements put up with my quirks (bad spelling, bad organization, sloppiness).
I will model and package the requirements so that they might be easily understood by those who will be using them.

The easier you make it to participate meaningfully in the requirements dialog and validation, the more willing stakeholders will be to fully invest themselves in it and the more they will want to work with you on future projects.

If you’ve never done it, or haven’t recently, I’d encourage you to ask a business stakeholder or a developer to help you out by listing a few ways you could make requirements easier for them to understand and use. I bet you’ll get at least a few ideas you wish you’d thought of sooner!

Go on, be an unselfish business analyst!

View the original post or comment on Be an Unselfish Business Analyst!

Quoteworthy: Chinese Proverb – Involve me and I’ll understand

2010-07-16T18:10:58-07:00

Tell me and I’ll forget; show me and I may remember; involve me and I’ll understand.

- Chinese Proverb

View the original post or comment on Quoteworthy: Chinese Proverb – Involve me and I’ll understand

Business Analysts: What Do We Want to Create?

2010-07-15T19:06:10-07:00

Peter Senge, in The Fifth Discipline: The Art & Practice of the Learning Organization, said that “[a]t its simplest, a shared vision is the answer to the question, ‘What do we want to create?’” I’ve mentioned several times that I think a business analyst’s primary responsibility is that of facilitating shared understanding (or shared vision) among project stakeholders. We help our organizations arrive at an agreement as to “what we want to create” within the parameters of the elicited needs and constraints.

Some of my most important “eureka” moments as a business analyst have come when I realized that producing cookie-cutter documents conforming to all the stylistic rules of “good requirements” didn’t necessarily constitute effective communication. And debating the relative merits of whether it’s best to specify requirements with use cases or user stories or declarative statements is not nearly as important as the question, “how can I express these requirements in a way that engages and makes sense to this audience for this project?”

James Shore, describing a situation where his team had specified requirements accurately, thoroughly and to the best ability of the team, said (emphasis mine):

What went wrong is that the customers didn’t engage in the up-front requirements process. They looked engaged–they were physically present and participating–but they didn’t know what they were getting and couldn’t imagine it from the materials we were giving them. I think what went wrong is that imagining software from a verbal or written description is a difficult skill, one that most customers don’t have.

I think Shore makes a significant point, here. It’s easy to get wrapped up in the textbook process and deliverables and doing them the proverbial “right way” and then overlook the notion that our real value lies in, first, identifying the requirements, and then in modeling them in a way (whatever way that may be) that makes it as easy as possible for the audience to understand what success for the project looks like, and hopefully achieve that ever-elusive goal of “shared vision.”

Let me say this again in just a slightly different way, because I think this is so important, and because I think a lot of analysts miss the point: Your value as an analyst is not in asking a bunch of questions and cranking out documents, but in facilitating understanding; in optimizing the requirements models you create to maximize their communicative value. Our value is in creating a shared vision of what constitutes success in the minds of every project participant.

I do have some ideas as to ways to maximize the communicative value of requirements, but we’ll leave that as a topic for another day. But in closing I will ask - what are you doing to make it easy (or at least easier) for your audience of stakeholders to understand requirements? Or, for your project team to reach a “shared vision” of what you’ll create?

View the original post or comment on Business Analysts: What Do We Want to Create?

Quoteworthy: Cicero – Be Brief

2010-06-14T10:15:29-07:00

When you wish to instruct, be brief; that men’s minds take in quickly what you say, learn its lesson, and retain it faithfully. Every word that is unnecessary only pours over the side of a brimming mind.

- Marcus Tullius Cicero

View the original post or comment on Quoteworthy: Cicero – Be Brief

Quoteworthy: William Strunk – Vigorous Writing is Concise

2010-05-20T18:17:29-07:00

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.

- William Strunk Jr.

View the original post or comment on Quoteworthy: William Strunk – Vigorous Writing is Concise

Business Analysts: Don’t Forget Your ROI!

2010-05-19T18:12:44-07:00

As business analysts, we’re trained to help business stakeholders prioritize projects and requirements within projects to help ensure that the right things are done in the right order to optimize the return on their investment. I think it’s important that we take our own advice when it comes to our analysis efforts and keep ROI (Return on Investment) at front of mind.

Assuming our raison d’être as BA’s is to help stakeholders reach a shared understanding of what is required for a successful product, what are the things we can do to create that understanding at the lowest cost in time and effort?

And I’m not suggesting we skimp or not take proper time to do the analysis, only that we be smart about it. One of the reasons traditional delivery methodologies get a bad rap is that they are so regimented and template/checklist-bound. Or, maybe it’s that analysts (and other project team members) interpret them as requiring the regimentation and checklists – but I digress.

In any case, you do have to do the analysis. You just have to be expert enough to understand what models and methods – among those available to you – give you the best return on your investment for a particular project and its accompanying set of circumstances.

A few examples:

If we are producing a document that no one reads, the return is probably not worth the investment of time and effort.
Further, if we are producing a document that everyone reads and approves, but that doesn’t contribute directly to helping get product out the door, not only is our time and effort wasted, but so is that of everyone who takes the time to review it.
If we are spending extra time on paperwork just to make sure that every section of a document has at least “something” in it, the return is probably not worth the investment of time and effort.

There are just so many types of requirements, so many types of models, so many tools at an analyst’s disposal that one can easily get caught up in doing things to be doing them – as part of a process/template, because they worked well enough another time, or because “that’s what we’ve always done.”

When focusing on “the process” or “the checklist”, one can easily forget that the value we provide is not in producing documents, but in clearing the path that leads to stakeholder alignment through shared understanding.

There are lots of “good things” that we could do, that may be helpful to someone, somewhere, sometime. The trick is to learn to identify and focus on the “best things” – the things that will move this particular effort furthest forward with an acceptable level of risk for the time and effort invested.

I say “at an acceptable level of risk,” because analysis paralysis almost always results from well-intentioned project teams doing “good things” well past the point of diminishing returns in a futile attempt to entirely remove risk of the unknown from the equation.

Before diving right in and “doing,” I find that it’s a good idea to assess the available tools in my BA toolbox – by that, I mean the collection of documents, models, methods, tips and tricks – basically the things that I can contribute that could help sharpen that shared vision of product/project success for my stakeholders.

It isn’t practical to use them all for every project, so I have to decide which tools will get me the farthest toward that shared understanding at the smallest cost. Once I have a pretty good idea on how I think I can add value, I work with my project team members to make sure they understand and are comfortable with those tools/models/etc. Once the team is on board, off we go – readjusting as needed when circumstances change.

So, here are a few questions for your consideration. An answer of “yes” MAY indicate an opportunity for you to modify your activities to improve your allocation of time and effort to improve ROI.

Are you doing tasks/work just to fill out a template, or a generic project plan?
Do you use the very same modeling techniques, with no variance, for every project?
Do you get the sense that your documents aren’t being fully read or used to drive downstream activity?
Do your analysis efforts seem to take longer than you think they should?
Does what you’re working on contribute directly to creating a shared vision among stakeholders of what is required for success on the given project/product?

So, when is the last time you considered the ROI for your analysis efforts? And what are you doing to improve it?

View the original post or comment on Business Analysts: Don’t Forget Your ROI!

Quoteworthy: Hunt & Thomas – Don’t Repeat Yourself

2010-04-27T20:32:20-07:00

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The alternative is to have the same thing expressed in two or more places. If you change one, you have to remember to change the others… It isn’t a question of whether you’ll remember: it’s a question of when you will forget.

- A. Hunt and D. Thomas on the “DRY principle” (don’t repeat yourself) from The Pragmatic Programmer: From Journeyman to Master

I might add that the same applies for documentation! – JB

View the original post or comment on Quoteworthy: Hunt & Thomas – Don’t Repeat Yourself

Quoteworthy: Aristotle – Rest satisfied with the degree of precision which the nature of the subject admits

2010-04-07T20:44:58-07:00

It is the mark of an instructed mind to rest satisfied with the degree of precision which the nature of the subject admits and not to seek exactness when only an approximation of the truth is possible.

- Aristotle

View the original post or comment on Quoteworthy: Aristotle – Rest satisfied with the degree of precision which the nature of the subject admits

Quoteworthy: Mike Krzyzewski – Five fundamental qualities that make a team great

2010-04-05T21:24:36-07:00

There are five fundamental qualities that make every team great: communication, trust, collective responsibility, caring and pride. I like to think of each as a separate finger on the fist. Any one individually is important. But all of them together are unbeatable.

- Mike Krzyzewski (Coach K.)

View the original post or comment on Quoteworthy: Mike Krzyzewski – Five fundamental qualities that make a team great