The Role of the BA in Creating a Common Vision

Submitted by cathycmb on Tue, 2008-09-02 10:59.

by Catherine Brunsting

Lack of predictability in getting a new product or service to market is one of the biggest threats a business can face. This problem is pervasive and many businesses are simply unaware there is a better, more predictable approach to deliver projects.

In her article Ms. Catherine Brunsting addresses how we can bring about predictability into what is delivered and when it is delivered, and how a strong Business Analyst can insure that this happens.

Attachment	Size
The_Role_of_the_BA_in_Creating_a_Common_Vision.pdf	199.95 KB

» login or register to post comments | printer friendly version | 1589 reads

Keeping the IT guys away?

Submitted by rtmerrill on Tue, 2008-09-02 17:41. *

I'm all for using facilitated workshops to get an aligned vision and overall requirements quickly.

But I sense distrust--"we have to keep those IT guys away--they'll just mess things up." Without the IT guys, how is it possible to estimate the cost of implementing various features, and how is it possible to establish initial scope based on value? This also discounts the possibility that the IT guys might actually have some good ideas about slightly different ways to get the business goal accomplished.

I went to check out www.geneca.com to read more about the complete Getting Predictable(tm) methodology, but the site appeared to be unavailable.

» login or register to post comments

IT Involvement in GP Process

Submitted by cathycmb on Wed, 2008-09-03 19:53. *

Thanks for your comments my article.

Regarding the issue of IT involved. The GP approach doesn't keep IT away from the whole process - only the initial sessions where we are obtaining a common vision from the business stakeholders about what the problem is that is being solved. The intent behind keeping IT out of the initial facilitated sessions is to let the business stakeholders become aligned on the problem that is being solved, before trying to find solutions to the problem.

Once a common vision of the problem is established, then the IT Architect is very involved in providing clear metrics around delivering the requested functionality and what options are available to deliver the requested functionality. There are often several options with widely varying degrees of difficulty. By partnering with the business stakeholders and discussing delivery in terms of business functionality, we are able to reach mutual understanding between IT and the business on what and when functionality is delivered. This process has worked very successfully for us on a number of projects.

This process only takes about 3-4 weeks to establish the width of the project (i.e., scope) and the business functionality to be delivered and when it is to be delivered. The metrics that we use then allow us to adjust the plan as functionality is delivered. And, change management is done in terms of adding, modifying or removing business functionality in terms of the defined scenarios.

For more information, please try to access our site again - I am not sure why you are having difficulty. If you continue to have issues please let me know.

Cathy Brunsting
Lead Business Analyst, Geneca
Chicagoland IIBA Chapter President

» login or register to post comments

Predictability of what?

Submitted by rtmerrill on Tue, 2008-09-02 17:51. *

In my experience, predictability of cost is the highest priority (no one wants to go back up The Hill) to ask for more money, schedule is second, and exact scope of requirements is third. And predictability itself has to be weighed against other factors. If predictability raises the total cost of the project by 10%, is it worth it? How about 50%? What if predictability necessitates a requirements freeze that locks out a great idea--one that could have doubled the business value of the application--just because we didn't think of it soon enough?

The use of facilitated requirements workshops (as Ms. Brunsting suggests) is an excellent idea for creating alignment (or finding out that it just plain doesn't exist) and getting pretty good requirements, but this is still the state of the project when everyone knows the least.

I'm looking forward to learning more from the Getting Predictable (tm) methodology, but the last time I checked, www.geneca.com was unavailable.

» login or register to post comments

Beware Predictability

Submitted by ScottWAmbler on Thu, 2008-09-18 13:19. *

Last year in the Project Success survey we actually asked people what was important to them. People, in particular business people, were far more interested in spending the money wisely than they were in coming under budget, for example. The point is that it's a false assumption, one foisted upon us by the traditional theory folks, that we need to accurately predict what the cost is going to be (something that we know we're not good at, and our stakeholders know we're not good at, BTW). I would rather focus on what is actually important to the business, so if they value ROI over budgeting I would choose to find ways to predict that I'll provide better ROI than other teams provide.

What business people actually want is to be able to invest their money in IT effectively, not to gamble it and hope for the best. Trying to predict up front what the budget will be actually proves to be a gamble in practice. Google the term "fixed price unethical" and you'll find an article which should get you thinking outside the traditional box.

Your point about questioning the value of investing too much in techniques which try to increase predictability is spot on. Instead of investing in bureaucracy you're much better advised to invest in techniques which increase the quality of what's being delivered (the number one issue for business people), the ROI of what you're delivering (also critical), and the chance that what you're building meets the actual needs of your stakeholders (clearly important).

Also as you imply freezing requirements is a phenomenally questionable practice. It might increase the chance of predictable costs, note the use of the word might, but it clearly increases the chance that you'll waste a lot of money building functionality that people don't actually want.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM Rational

» login or register to post comments

Predictability during requirements definition

Submitted by meganhurley on Wed, 2008-09-17 10:44. *

While I agree that firming scope with the business sponsors is important, where I have seen projects slip on deadlines is getting the SMEs, the people actually doing the work, to agree upon business and system requirements. In other words management might have a clear picture of scope and vision, but the people on the ground lack that scope and vision and get bogged in the as-is. Are there any suggestions on how to speed the process of firming up requirements? We already use models to help clarify and gain consensus.

» login or register to post comments

Working software is much firmer than models and documents

Submitted by ScottWAmbler on Thu, 2008-09-18 12:56. *

People aren't very good about defining what they want, so if you follow a process that relies on them doing so you'll find yourself in trouble (which appears to be happening). Instead, people are good at indicating in a fuzzy manner what they think might want and very good at indicating what they don't want once they see something. So, you need to adopt processes that reflect this reality, and the best way to do so is to work in short iterations where working software is delivered. This puts you in a position where you can reduce the feedback cycle and home in on what people actually want fairly quickly. So, I'd argue that the real issue isn't that you need to firm up the requirements, but instead you need to get good at working collaboratively and iteratively with stakeholders in a flexible manner so that you implement systems that meet their evolving needs.

You'll still want to do some initial requirements envisioning at the beginning of the project to agree on an overall vision and get going in the right direction. But you won't be able to effectively get to a detailed scope, and if you do you'll pretty much ensure that the project team develops a lot of functionality that nobody is actually interested in.

In short, if you try to follow processes which don't reflect human behavior you're going to increase your overall project risk. Unfortunately many of the traditional theories around how software development should work go against common human behavior, which I suspect is one of the reasons why we see a lower success rate on traditional projects as compared with agile projects.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM Rational

» login or register to post comments

Ask not what they want, Ask what they do...

Submitted by dwright on Thu, 2008-09-18 13:21. *

Scott, and Megan too,

I am in full agreement that you can't just ask what people they want, no one can absolutely define that. It is better to ask and document what people do, because that is definitely something they can tell you; and when that unearth's problems they are having now, or opportunities thay can't yet take advantage of, ask what they would do differently to solve the problems and realize the opportunities.

If you do this, you will get specific Business Requirements, rather than vague wishes or desires.

...and this is not a Traditional versus Agile thing, both can be guilty of only asking what the business wants. I agree that Agile will more quickly determine if what was 'wanted' was really what was 'needed' or not, but that is really just cutting up trad waterfall into little pieces, rather than doing something really different than Trad Waterfall. I suggest that any approach will work better and save re-work time if you start by having people tell you things they actually know --- what their business process is --- rather than having them speculate about what a system should do for them.

David Wright
"It is the mark of an educated mind to be able to entertain a thought without accepting it."
- Aristotle

» login or register to post comments

Agreeing on what the business is, not the same as Requirements

Submitted by dwright on Thu, 2008-09-18 13:01. *

Megan,

Me again.

What I have found is that when SME's can't agree on Requirements, it usually means that a group of people that are seemingly doing the same work actually have their own individual ways of doing that work. That means the business and IT have a few options: (1) requiring systems to be flexible in allowing different ways to accomplish the same function, or (2) getting the business to standardize on one way/process for doing the work.

I always recommend (2) get done before getting back to the Requirements definition. The usual outcome is a standard process that also allows for some flexibility, but that flexibility is based on different business scenarios rather than the personal choices of the people doing the work.

I know end-users don't like to hear that their 'requirements' really aren't, and I know the that most don't think about the fact that end-users come and go over time, but the systems will be in use for years or decades longer than the time any one person uses them. Systems do have to be "usable", but that can be accomplished without having to meet the whims of the people who happen to be around when the system is built or purchased.

David Wright
"It is the mark of an educated mind to be able to entertain a thought without accepting it."
- Aristotle

» login or register to post comments

User login

New forum topics

Recent blog posts

Upcoming events

The Role of the BA in Creating a Common Vision

Comment viewing options

Keeping the IT guys away?

IT Involvement in GP Process

Predictability of what?

Beware Predictability

Predictability during requirements definition

Working software is much firmer than models and documents

Ask not what they want, Ask what they do...

Agreeing on what the business is, not the same as Requirements

Recent Articles

Partners

Recent comments

ARCHIVE MENU

Sponsored Announcements & Special Offers