Process resposibilties: PM does initial requirements gathering with client?

9 Apr 2009 - 3:02am
5 years ago
10 replies
1173 reads
R. Groot
2006

Dear all,

I'll keep it short:

in your company, which role gathers the requirements from the client?

a) project manager makes inventory in the initial meetings and passes them
to the interaction designer
b) project manager and interaction designer both do the initial meetings
together. The interaction designer collects the requirements
c) other, namely......

I'm very interested to hear from you!

Kind regards,
Rein

Comments

9 Apr 2009 - 8:15am
Jack L. Moffett
2005

On Apr 9, 2009, at 4:02 AM, R. Groot wrote:

> in your company, which role gathers the requirements from the client?

I work on a wide range of projects, from my company's own products to
military contracts. Requirement gathering varies from project to
project.

> a) project manager makes inventory in the initial meetings and
> passes them
> to the interaction designer

This is the case for some of our products, as the product manager is a
domain expert.

> b) project manager and interaction designer both do the initial
> meetings
> together. The interaction designer collects the requirements

This is also sometimes the case. In the situation mentioned above, for
example, working with the product manager is very much like working
with a target user.

> c) other, namely......

Sometimes I collect requirements based on observations in the field.
Sometimes others collect requirements based on observations and I must
interpret them. Sometimes requirements come in from the client
directly to me, and the project manager isn't directly involved.
Sometimes I get a requirement from an issue tracking system and don't
know who it came from.

Best,
Jack

Jack L. Moffett
Senior Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

To design is much more than simply
to assemble, to order, or even to edit;
it is to add value and meaning,
to illuminate, to simplify, to clarify,
to modify, to dignify, to dramatize,
to persuade, and perhaps even to amuse.

- Paul Rand

9 Apr 2009 - 9:22am
Phillip Hunter
2006

Currently, we have a dedicated business analyst who has design experience gathering the majority of requirements for larger projects and knows what the designers need and care about. The design teams follows up and finalizes those. For smaller changes, the design team act as BAs.

Phillip

9 Apr 2009 - 10:22am
Beja
2009

Ditto with Jack and Phillip. It's either the Product Manager (note: not the *Project* Manager) and/or the Business Analysts.

Beja

9 Apr 2009 - 9:15am
Dru
2009

Like Jack, the complexity of the project dictates how the requirements
are collected. Basically we do "other" and here is what we do:
1 UI person and designer get with biz owner to get high level
requirements for purpose of design elements. At this point we may or
may not include a Business Analyst.
2. Initial wireframes/mockups are done and once okay'd by owner,
Business Analyst is incorporated and requirements for functionality
collected.
3. Project Manager is not incorporated until there is a completed set
of mock ups, HTML prototype and complete Biz Requirements doc version
1.0.

We are currently in discussed within our Interactive Design Dept
(where my position as Usability Coorindator is) of having a project
manager role added into the very early stages but this PM would not
be the one that would be responsible for actually driving the final
SDLC to production.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41112

9 Apr 2009 - 2:43pm
suewah
2008

In my career I've seen many variations of the requirements gathering
process. I've lead this phase mainly due to lack of resources. In
some cases I've had business analysts or the project manager lead
the requirements phase and utilizes an IA or tech lead to validate
the information gathered.

Depending on the scope of the project it would be difficult for
designer to handle requirements alone. If the complexity of the site
or application is relatively small probably. However, on large
corporate portals, enterprise applications or Ecommerce type
applications where there are numerous usability, content, design and
technological variables, requirements gathering would be better
suited to BA's with the right domain knowledge and experience
supported by resources such as CDs, IAs and TLs.

My two cents,
Charles Sue-Wah-Sing
www.nexklix.com

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41112

13 Apr 2009 - 1:21am
dszuc
2005

How do folks manage requirement(s) priority and value? i.e. how do you
know if what you are gathering is truly worth building out?

It seems this is where many products fail. We build or design stuff
that people don't need and we are evaluating the "usefulness" way
too late in the project.

The sweet spot seems to be helping a Product Manager identify if
something should be built and a more effective use of resources as
you iterate forward.

Thoughts?

rgds,
Dan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41112

13 Apr 2009 - 1:51am
Angel Marquez
2008

>>How do folks manage requirement(s) priority and value? i.e. how do you
know if what you are gathering is truly worth building out?
Charter, proposal, client work order, sales initiative, design document
(video game world)

>>It seems this is where many products fail. We build or design stuff
that people don't need and we are evaluating the "usefulness" way
too late in the project.

The above documentation overviews should identify a need, trend, revenue
stream, opportunity, etc...

>>The sweet spot seems to be helping a Product Manager identify if something
should be built and a more effective use of resources as you iterate
forward.

I think once a PM is in the mix the project should be well underway. Most of
the good docs I've read or been involved in have a well stated vision,
mission and driving force of why you would research an existing market or
research an opportunity.

The specifications, that define the desired solution, should come before the
requirements phase that details the technical aspects referring back to the
spec.

The Art Of Project Management is a good read:
http://oreilly.com/catalog/9780596007867/

Having the deliverable successors plugin to their predecessors in a cohesive
and seamless manner is the Rosetta Stone, making it fit like a glove during
the entire life cycle.

My thoughts...

On Sun, Apr 12, 2009 at 4:21 PM, Daniel Szuc <dszuc at apogeehk.com> wrote:

> How do folks manage requirement(s) priority and value? i.e. how do you
> know if what you are gathering is truly worth building out?
>
> It seems this is where many products fail. We build or design stuff
> that people don't need and we are evaluating the "usefulness" way
> too late in the project.
>
> The sweet spot seems to be helping a Product Manager identify if
> something should be built and a more effective use of resources as
> you iterate forward.
>
> Thoughts?
>
> rgds,
> Dan
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=41112
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

13 Apr 2009 - 2:49am
dszuc
2005

Thanks Angel and suggest part of the answer lies in:

* Asking the right questions up front to determine value and driving
requirements based on research, need, gut feel, market gaps, fill in
your own ...
* Having faith that the folks determining a market need have done
their homework i.e. what are they basing their decisions on?
Sometimes I wonder.
* Ensuring that people who are potential users of the products &
services being developed are invited to preview what the business is
thinking about (and this goes beyond 1-2 Focus Groups)
* Mapping Product & Service decisions to a larger Product Strategy

Have seen times where we are invited to Design, Review or Test
something that does not appear to add value or fill any type of
market need. When some basic questions up front would have changed
the Product Strategy completely. But ... when trying to apply those
type of questions, it can often be pushed aside in favor of
delivering (as that's seen as the reward) or playing with a new
technology or platform. Not necessarily the value of what you are
building but implementing it on time and budget.

This is also another interesting recent perspective on what we make
and sell -
http://darmano.typepad.com/logic_emotion/2009/04/why-marketing-in-a-post-consumer-era-wont-look-like-marketing.html

rgds,
Dan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41112

13 Apr 2009 - 3:46am
Angel Marquez
2008

>>Thanks Angel and suggest part of the answer lies in:No worries.

>>* Asking the right questions up front to determine value and
driving requirements based on research, need, gut feel, market gaps, fill
in your own ...

Agreed. I would add having the right people in the correct roles. It sounds
so simple.

>>* Having faith that the folks determining a market need have done their
homework i.e. what are they basing their decisions on? Sometimes I wonder.

I always wonder.

Positive:
Competitor analysis, Community feedback, metrics.

Negative:
Research budget allocation is based on meeting the revenue goals which in
turn dictates the user base. Funneling that research based on that target
audience to achieve those goals doesn't necessarily infer the user's best
interest are met; but, rather their behaviors and habits are used as models
to create user experiences.

>>* Ensuring that people who are potential users of the products & services
being developed are invited to preview what the business is thinking about
(and this goes beyond 1-2 Focus Groups)

Positive
The more involvement by the potential users the better after all they are
the target audience.

Negative
What about the budget? I've been pondering on this one. Everyone wants there
piece of the pie and are willing to say it's for whatever that research
deems the worthy need. The user. Slow dripping the budget and information
bottleneck to achieve a guaranteed piece of the pie is common. My latest
pitch after hearing a potential clients woes was that I wanted to figure out
their needs and make the touchdown in the least amount plays. This is only
one side of the design, what about those users they have to be factored in
too right?

>>* Mapping Product & Service decisions to a larger Product Strategy

All interdependent and should be handled with that in mind. On a smaller
scale having a design team deploy one logo across all medians (collateral,
consumer packaging, mobile, broadcast, apparel, billboard, etc..)
effectively is simple; but, getting a team to all agree on something so
simple is a difficult task. If you multiply that by a million
while effectively managing the strategy you are on the right team.
Likeliness? Someone has to draw lines, someone has to not get their way.

>>Have seen times where we are invited to Design, Review or Test something
that does not appear to add value or fill any type of market need. When some
basic questions up front would have changed the Product Strategy completely.

You and me both. It is the nature of the beast. Good example for me is a
couple phone interviews I had just recently and I said to the interviewees
'I don't think this is a good fit'. I couldn't imagine having that
conversation everyday for however long. On the other hand I don't think
every decision is an opportunity to explore the entire spectrum
of possibilities. I just had a convo where I was all if I went to starbucks
in the morning on the way to work to get my coffee and the cashier offered
me every possible blend, brew and way to distill the water while the line
grew longer and my attention grew shorter it wouldn't be right. We as
professionals are faced with those decision intersections daily while faced
with similar constraints, people waiting, need to be somewhere else, time
money etc... Identifying and administering when and how these moments go
down is essential. I had some reject that loved to debate want to tell my
favorite radiohead album wasn't my favorite. I really just wanted him to go
away before tainting anything else I held dear.

>> But ... when trying to apply those type of questions, it can often be
pushed aside in favor of delivering (as that's seen as the reward) or
playing with a new technology or platform. Not necessarily the value of what
you are building but implementing it on time and budget.

If you have the luxury of playing with a new technology; but, are crippled
by the deadline (the deadline is what measures the budget, right?) I would
find the common tech ground and run the dev parallel. Often you have to
abandon ship because the plan changes and the new technology hasn't been
defined or the platform etc. Politics push things. Hopefully you
can successfully leverage the naysayers aside and do what is right for the
project and goals. I could tell you stories my friend.

>>This is also another interesting recent perspective on what we make and
sell -

Neat visuals. I think part of being a designer is being effective with that
dixie cup consumer need and crafting your process to fit with that paired
with your work environment.

If you have good intentions and someone sinks your idea with malicious
intent you're still the winner.

External pressures drive people to weirdness.

Take care DS.

On Sun, Apr 12, 2009 at 5:49 PM, Daniel Szuc <dszuc at apogeehk.com> wrote:

> Thanks Angel and suggest part of the answer lies in:
>
> * Asking the right questions up front to determine value and driving
> requirements based on research, need, gut feel, market gaps, fill in
> your own ...
> * Having faith that the folks determining a market need have done
> their homework i.e. what are they basing their decisions on?
> Sometimes I wonder.
> * Ensuring that people who are potential users of the products &
> services being developed are invited to preview what the business is
> thinking about (and this goes beyond 1-2 Focus Groups)
> * Mapping Product & Service decisions to a larger Product Strategy
>
> Have seen times where we are invited to Design, Review or Test
> something that does not appear to add value or fill any type of
> market need. When some basic questions up front would have changed
> the Product Strategy completely. But ... when trying to apply those
> type of questions, it can often be pushed aside in favor of
> delivering (as that's seen as the reward) or playing with a new
> technology or platform. Not necessarily the value of what you are
> building but implementing it on time and budget.
>
> This is also another interesting recent perspective on what we make
> and sell -
>
> http://darmano.typepad.com/logic_emotion/2009/04/why-marketing-in-a-post-consumer-era-wont-look-like-marketing.html
>
> rgds,
> Dan
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=41112
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

13 Apr 2009 - 11:31am
David Poteet
2009

I think the answer depends to some degree on whether you are
supporting internal customers, or working as an outside UX vendor. We
pair a project manager with a user experience architect during the
requirements analysis process, and we often bring in someone from the
creative and development team as well.

Shaping an overall experience vision is key (not just making a list
of requirements), and this centers on the customer's experience of
the product/website/service. We find the more people we involve in
shaping this vision the better. Even though it can add cost at the
beginning, it almost always saves us cost over the full project.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41112

Syndicate content Get the feed