Who does own the upstream process?

17 Nov 2004 - 5:25am
9 years ago
9 replies
1049 reads
Narey, Kevin
2004

Dave:
>[business analysis] believes that it owns the upstream process of strategy
and requirements,
>when in fact Design is much better capable of coming up with longer-term,
>more stable, and higher returning solutions than BA can, b/c BA is too
>narrow in focus in that it only looks at related and observed problems
>instead of defining problems outside of the relational and observed.

>But that's a whole other discussion.

Let's rock.
In my organisation Business Analysis does own the process upstream, although
colleagues and more importantly customers, are listening to the uberDesign
slant. It's painfully slow, however.

I recently studied the in-house Job Description of a BA and an IxDer as two
that sit side by side in an organisation; everyone here has a very well
defined and formally agreed JD. Initially, I'll be honest, I was unable to
distinguish a great deal of difference between the two other than the visual
design communication elements and ability to visualise/code a prototype.

I have found that there is little supporting evidence to convince Management
(wild rage and wobbling lips doesn't work) that Design subsumes BA other
than trying to prove that BA's are not producing the goods and that they can
only perform their roles sufficiently in concert with an IxDer. Perhaps
there is a case for 'Business Analyst who can do a bit of design' after
all...........?

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

Comments

17 Nov 2004 - 7:31am
Dave Malouf
2005

I'm on my way to a shared role w/ BA's in owning requirements. I would like
to add that in our organization Product Marketing is the first owner of the
upstream process. But again we are looking at who can own those elements of
the product/service that don't fall under any given market segment and that
covers all of them.

But back to the BA. It is clear that BAs do add value in our organization.
Fighting that would be like trying to attack Moscow in Dec. But the story we
are having success selling is that design will be better when designers have
more context to use to help build their designs with. The other story we are
selling really well is that requirements definition is a collaborative,
x-functional process, and so we are now have joint design sessions that are
turning out to be very successful in speeding up the delivery of the
requirements.

In the end requirements will remained OWNed by the BA, but the designer is
not a vice-BA if you will through the requirements definition process.

What's missing is the further upstream process of developing concepts
themselves. Since we have a HUGE customer touch-point issue in our
organization, doing ethnography is really difficult. Most of our customers
are of the type who never ever stop working except when they take a vacation
every 5 years, so it is pretty hard to get their attention at all and right
now the sales and marketing folks OWN that relationship and are not seeing
any value in sharing it with design. Until that happens it will be REALLY
impossible for the design team to co-own more of the upstream process.

What has been successful is that the prod marketing folks are inviting us to
almost all of their interviews these days. These interviews are NOT useful
for us, but they put us in proximity to the customer AND people are getting
a better picture as to why "putting us in front of a customer" doesn't mean
just doing interviews. It will help us later down the path.

I realize this discussion is very much an "innie" talk. I can't imagine any
of this being relational to a consultancy with any moxy at all.

I'd be interested to hear how others have been climbing upstream in the
in-house sphere.

-- dave

17 Nov 2004 - 9:54am
Jennifer Brownson
2004

--- "Narey, Kevin" <Kevin.Narey at Gedas.co.uk> wrote:

>
> Let's rock.

Yep, here we go.

> In my organisation Business Analysis does own the
> process upstream, although
> colleagues and more importantly customers, are
> listening to the uberDesign
> slant. It's painfully slow, however.

In mine, the BA, technical architect, and myself are
partners in defining the upstream process. I mediate,
and we trade off leading the discussions. It works
because we've been working together for a couple of
years and know what each of us needs to do our
respective jobs.

Other places I've worked, I lead the upstream process.
I'd prefer to do it collaboratively, but you need a
special group of people to do that.

> I recently studied the in-house Job Description of a
> BA and an IxDer as two
> that sit side by side in an organisation; everyone
> here has a very well
> defined and formally agreed JD.

I lead the BA team here. I have the title of senior
information architect (I know, I know, working on
that).

Initially, I'll be
> honest, I was unable to
> distinguish a great deal of difference between the
> two other than the visual
> design communication elements and ability to
> visualise/code a prototype.

For us, the BAs write use cases and document current
state of the business. Myself and the technical
architect work with the users and the business to
define future direction and the user interaction. The
BAs document those decisions, and I do the standard
user interaction design deliverables. We work across
multiple projects, the BAs each have one.

> I have found that there is little supporting
> evidence to convince Management
> (wild rage and wobbling lips doesn't work) that
> Design subsumes BA other
> than trying to prove that BA's are not producing the
> goods and that they can
> only perform their roles sufficiently in concert
> with an IxDer.

Exactly. In the companies I've worked in, I've had
technical architects who have worked with an IxDer
before, and they've been the ones who pushed for us,
because we get them the most complete and CORRECT
design. It comes down to them writing code that's not
going to waste. Efficiency. BAs don't get the whole
picture.

Perhaps
> there is a case for 'Business Analyst who can do a
> bit of design' after
> all...........?
>
> Kevin

On a smaller project, maybe. I've taken on that role.
On a bigger project, you need both.

And a side note, I hate doing BA work. Every time
someone asks me "well, you can write the use cases,
right?" I say "sure, I can, but I'm going to get
intestinal cramps." A really good BA is worth their
weight in gold.

Jen

__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com

18 Nov 2004 - 2:42am
George Olsen
2004

On 11/17/04 2:25 AM, "Narey, Kevin" <Kevin.Narey at Gedas.co.uk> wrote:

> I have found that there is little supporting evidence to convince Management
> (wild rage and wobbling lips doesn't work) that Design subsumes BA other
> than trying to prove that BA's are not producing the goods and that they can
> only perform their roles sufficiently in concert with an IxDer.

In a lot of organizations the line between BA and ID can be blurry. In
traditional IT development, BAs were introduced as the interface between
programmers and "users" -- "users" normally being managers, business
sponsors, etc. So as mentioned, BAs end up doing things -- such as use cases
-- that are perceived by lay people as being equivalent to what IDs do.

But rather than trying to dethrone BAs, we're better showing how we can
complement their skills.

For example, when I was working for a financial services company, I worked
with a BA who knew all sorts of minutia about the business processes of the
company, the intricacies of different legal restrictions in various markets,
etc. Things that had taken her a couple years to learn.

OTOH, while she could do flows and use cases, she didn't have the depth of
knowledge about how to design good user experiences that I'd learned over
the years. So while ownership of certain deliverables had to be negotiated,
overall we able to combine our strengths for a better result.

For my part it involved a lot of initial patience, waiting for the right
opportunity to say, "BTW..." and introduce a concept or technique that might
be familiar to us but new to them.

George

18 Nov 2004 - 3:36am
Listera
2004

George Olsen:

> But rather than trying to dethrone BAs, we're better showing how we can
> complement their skills.

I live and work in the middle of Wall Street, which has the highest
concentration of BAs anywhere on the planet. I've had a lot of financial
clients and, in fact, next week I'll start a new project for one of the top
names in the financial world. With a century and a half of business
presence, it's quite conservative, as you might expect. I'll be redesigning
some apps and creating a brand new one, from concept to interactive
prototype.

The reason I'm citing all this is to underline the fact that even in this
most traditional place, I asked for domain expertise help and was assigned a
dedicated BA in a discussion that took roughly 90 seconds. I had absolutely
no prior involvement with this company and presented myself as "I'm a
Designer: I Solve Problems". Nobody ever raised the notion of design being
subordinated to or complementing BAs or anybody else for that matter.
Roughly 70% of the discussion was about solving their various business
problems via design, by me, as a designer. I doubt that this (conservative)
company would let BAs design UIs after this experience.

Once upon a time, programmers, webmasters and graphics designers used to
routinely design sites/apps/interfaces. Today, we generally frown upon that
and recognize that it takes more to design usable and useful apps.

So time marches on.

I see no reason for designers to complement BAs skills; BA should continue
to be valuable members of the design team that's firmly driving the design
process.

Ziya
Nullius in Verba

18 Nov 2004 - 7:17am
Lada Gorlenko
2004

L> BA should continue to be valuable members of the design team
L> that's firmly driving the design process.

As well as designers should continue to be valuable members of the BA
team (who is a member of which team depends on a project nature; there
are 'design'-led projects that aim at building artefacts and there are
'process change'-led projects that aim at ... well, changing processes).

Having worked with different BAs on different projects, I feel that
the confusion 'who does what' is often caused by visible similarity of
the methods, tools and vocabulary. I do 'task analysis', you do
'process analysis'; I write 'use cases', you write 'use cases'; I
solve problems, you solve problems. Dig deeper, and you will spot the
difference. Things we look at are similar, thing we see are different:
- IxD Designers (including UID) design *artefacts* and *interactions*
with them;
- Experience Designers design *user experiences* that start at
interaction with design artefacts and go beyond the artefact layer;
- Business Analysis design *business experiences* (may or may not
include design artefacts).

An example from a recent (piece-of-cake-type) project. I worked
alongside a BA on evaluation of self-service supermarket checkouts.
We spent many hours on the shop floor together, observing customers.
Same settings, same observation, different roles.

Things the BA saw: time at the checkout; shopping load size;
throughput; time on different tasks (unload, scan, payment, bagging);
type of payment; number of additional card swipes; workload of the
checkouts supervisor, etc.

Things I saw: type of shoppes; locating and approach the checkout;
type of shopping cart; different unloading/scanning/bagging techniques
and their ergonomics; body language and facial expressions; time on
tasks; interaction with the touch screen and conveyor belt;
interactions with other shoppers; type of assistance (customer asks
for help vs. help is system-requested vs. help is offered proactively),
etc.

He knew his Greek, I new my Latin. When we finished, he knew how to
make the business process more efficient. I knew how to redesign the
interface, improve customer experience, and market the checkouts to
the public. My findings helped shaping his recommendations, his helped
mine. Before we started, he had claimed being fluent in Latin
as well. He never mentions it again (not in my presence). To be fair,
I don't claim authoring The Iliad either.

Lada

18 Nov 2004 - 7:28am
Dave Malouf
2005

BAs vs. Designers

In my experience the BA is a business advocate and not a user advocate. The
use of use cases is for definition purposes in a very UML fashion, but they
do not do advocacy in their methods.

The BA does relational problem definition. That is they are told what a
problem is and translate that into a problem statement which usually has the
solution melded into it.

The BA does not use an iterative divergent design process to first
deconstruct related problems into latent problem sets and then to iterate on
solutions.

The BA does not go out and create a contextual understanding of the user.

What I have found, is that once I understand these pieces, I can better find
the areas where I can compliment the BA and make it clear where I can bring
value.

I would say that 10% of the true value of a designer comes from the 90% that
everyone thinks designers really do. ;)

-- dave

18 Nov 2004 - 1:08pm
Listera
2004

Lada Gorlenko:

> He knew his Greek, I new my Latin. When we finished, he knew how to
> make the business process more efficient.

And that's all he could do.

If we were discussing business process reengineering (or some such) we could
grant him equal/superior/leader status, take out the trash and call it a
day.

Alas, we're discussing the business of DESIGN, whose end-product is an
interactive application. The vast majority of BAs can't, don't and won't
claim to (be able to) do that: they are not in the design business.

So if anyone wants to let non-designers (BAs, developers or anybody else)
drive the design business, be my guest, but don't ask for Tylenol and/or
Valium in the morning.:-)

Ziya
Nullius in Verba
(It's all Latin to me)

18 Nov 2004 - 2:25pm
Frank Ramirez
2004

Ziya said:
> Alas, we're discussing the business of DESIGN, whose
> end-product is an interactive application. The vast majority
> of BAs can't, don't and won't claim to (be able to) do that:
> they are not in the design business.

Some would argue that the end product is actually a lot more than an
interactive application - it's a new business, workflow, operation, etc.
Why would you put a designer in charge of your operations? </devil's
advocate>

BTW, the subject has been about BA, but I think we can include Product
Managers since they seem to be synonymous in this context.

In my experience designing large apps, I've found the best
responsibility model to look like this:

Responsibility:
1. Project mgmt, business rules: BA, PM
2. Front-end design/behavior: IxD, IA, Designer, whatever-you-call-us
3. Technical implementation: Tech Lead, Software Architect,
whatever-you-call-them

4. Everything above: Whoever signs the checks

Note: I've also learned that it's very effective to orient 1-3 as
"consultants" to 4 - even if they're in-house. This means that 1-3
collaborate very closely and present issues and options to 4 as a team.

Good topic! Another interesting question IMO is about how we collaborate
with BA/PMs. Specifically, I'm referring to the overlap between
wireframes (annotated design specs) and PRDs.

Frank

18 Nov 2004 - 4:27pm
Listera
2004

Frank Ramirez:

> Why would you put a designer in charge of your operations?

Just the design process would suffice, thank you.:-)

Ziya
Nullius in Verba

Syndicate content Get the feed