Skip to main content

Author: Terry Longo

Agile Oxymorons

Written by Terry Longo on . Posted in Articles.

In my previous entry, I argued that the business case needs to be central to the BA’s view of the world, with requirements management being the most demanding in terms of level of effort.

In June I attended and presented at all three BA World Symposium events (Seattle, Denver, and Minneapolis), and I took away a couple of anecdotes that I’d like to share:

  1. Polling my presentation audiences revealed that maybe 10-15% attendees had downloaded the BABOK v2 Draft.
  2. I listened to a discussion about “Agile Analysis based on Web 2.0” – suggesting to me that BAs sometimes work too directly in the solution space rather than the problem/need space….

What does it mean?  Shouldn’t the BABOK have a more prominent role in the lives of those who are calling themselves BAs?  Don’t we, as a community, need to be more diligent about the importance of distinguishing problem space language from solution space language?  Have you downloaded and read BABOK v2?  Are you practicing “agile business analysis”, and if so, to what extent do your agile BA practices depend on specific technologies?

Inquiring minds want to know!  Please take a minute to share your thoughts/comments.  Thank you!

The Business Case: Is It the Next Agile?

Written by Terry Longo on . Posted in Articles.

In earlier blog entries I discussed the notion that not requirements but the business case should be the center of the BA’s existence, and that the business case must somehow account for the costs and risks of the components comprising the intended solution.

The notion of agility is one of the primary tenets for dealing with change. But how can there be so much discussion about Agile Development, Agile PM, and Agile BA without also discussing “Agile Business Case Management”? After all, software development, PM and requirements activities are driven by and exist within the context of the business case. Before continuing, I want to acknowledge absolutely that, from a level-of-effort point of view, the specific activities around requirements management are the most demanding aspect of BA. But as requirements exist within a context of constant change from within (project dynamics) and from the outside (business dynamics), when focusing on the requirements themselves, how do we know when the business case needs to be revised and reconsidered due to those changes?

Anecdotally, in bringing up this question with my audiences at the Seattle and Denver BA Symposiums, there was general acknowledgement that requirements management is currently the main focus of Bas, and that the business case frequently falls by the wayside, once solution development commences.

Is this the case for you? What are your best practices regarding business case management to ensure that it continues to be revisited in light of development, operational, and/or business changes? When your business cases are created, do you specify boundaries (cost, risk benefit, etc.) beyond which their relative value is lost?

What are your favorite BA-related books? Why?

Written by Terry Longo on . Posted in Articles. 1 Comment on What are your favorite BA-related books? Why?

OK, so we’ve all heard of the Business Analysis Book of Knowledge, and some of us have read part or all of it. But there’s got to be more to reading about business analysis than the BA Bible. And I want to find out what I should be adding to my BA library. 

What are your favorite business analysis books (besides the BABOK, that is)?  Are there books you would tell others to avoid?  Why?  Have any made a real difference in the way you work?  In the way your organization works?

I, and I’m sure others, look forward to your recommendations.

Does the BA Role Belong in IT or the Business?

Written by Terry Longo on . Posted in Articles.

The question of whether the BA role should be defined with IT or within the business is one of those ongoing questions of organizational structure. As we progress in professionalizing the role of the BA, we will need to hammer out a useful response that accounts for the pros and cons of each.

Are you a BA in IT or in a business unit or function? What do you see as the pros and cons of each? Where do you think a BA should be in the overall organizational structure, and why?

It seems to me that more and more people are landing on the side of the BA role being defined and “hosted” within the business. If that overall paradigm is inevitable, what can we, as a community of practice, do to ensure that we preserve the advantages of the BA-in-IT paradigm?

Behind this question are various complexities related to change management, relationship management, solution scope, risk management, and other elements that can make or break a business case.

I hope you can take a minute to comment on your situation, what you’ve learned based where you are in your organization, and what you believe to be a sound direction for the BA profession.

The Eye of the Storm: The Business Case

Written by Terry Longo on . Posted in Articles. 1 Comment on The Eye of the Storm: The Business Case

You may have noticed that one theme in this blog is change management, which I think must be central to a BA’s approach to managing requirements. Actually, I take that back…. To some degree, it seems that there is an overemphasis on the requirements themselves, at the expense of managing the business case for satisfying those requirements.

I will try to state my concern philosophically first, by asking the question “Where does the BA stand? What ought to be the BA’s primary point of view?” Here are the stands I see taken by BAs, to varying degrees: 

  • The requirements themselves – extremely challenging to set one’s bearings on the requirements themselves, because they will change! 
  • The requirements process – obviously a more stable view, giving one the prism through which to view and manage the constantly changing requirements 
  • The business case itself – this is the most advantageous point of view from which the BA should start his or her day

Saying it another way, if my mission is to manage the requirements, I could lose sight of the business case itself, which will change as requirements and solution elements (scope, schedule, cost) change. But if my mission is to keep the business case alive and fresh, by continually reflecting within the business case, in business case terms (benefits, costs, risks), the changes to requirements and solution elements, I have not only (a) taken a stand that puts me closest to my stakeholders from a business benefit point of view but also (b) made change management my core activity, because the business case cannot be kept fresh without it.

Do you agree? How central is continuous business case management to the way you work? If it is not central, what are the obstacles/challenges you face in making it so?