Comments on Better Projects: Waste in requirements

Here is how I do it...

(part 1 of 6)

2009-04-07T00:31:00.000+10:00
Here is how I do it...

(part 1 of 6)

http://www.cleverworkarounds.com/2009/02/12/the-one-best-practice-to-rule-them-all-part-1/

This method is rooted in sensemaking but is very effective for me and really gets the participants engaged.

I agree with Kevin that the numbers need more cont...

2009-04-02T08:39:00.000+11:00

I agree with Kevin that the numbers need more context.

But talking about solutions, here's what has worked for me, always.

Demonstrate to your customers that what they are saying (requirements) is heard and implemented by frequently releasing (or at least showcasing the application).

The customers need to feel confident about two things:

1. My requirements get implemented

2. I can make reasonable changes to the requirements.

If your customers feel that these 3 months (requirements & analysis phase) is the only time they will get to voice their requirements, they will come up with as many as they can think of. Many of which could be of no practical use to the majority of users.

Once your customers are confident about these 2 things, you can get into real de-scoping sessions. The backlog will get prioritized much better and you'll have the most useful features bubbling up to the top.

We have in our aerospace and defense practice when...

2009-04-01T00:17:00.000+11:00

We have in our aerospace and defense practice when the Capabiltiies definition phase is skipped (resulting in the Concept of Operations - ConOps), the requirements baseline has not justification for eahc requirement - other than "looks like we might need that."
Starting with Capabilities Based Planning, each requirement has a business or operational reason, and each capability has a requirements that enables it produce the planned business value.
Thsi approach is not directly applicable to "emerging" systems like an internal IT product.
But an incremental approach can be used there as well. Rolling Waves of capabilties and their requirements can be used to bound the "emergence."

First of all If I had to share what I feel in my g...

2009-03-31T21:20:00.000+11:00

First of all If I had to share what I feel in my guts I'd come with pretty similar results.

Well talking about dealing with the problem I don't have a good answer. I guess the most obvious way is coaching customers. However that's always tricky and rarely successful so it's hard to consider it as an answer.

In big organizations decision-makers when it comes to feature range are recruited from marketing and/or business units. Very often they don't really know what their users want since they're filtered from real user requirements by tons of analysis, surveys and guesses.

Decision about features often are made on "I think I'd like it so let's have it in the solution" way of thinking which also contribute in mentioned statistics.

Requirements are better managed in Aerospace Softw...

2009-03-31T13:57:00.000+11:00

Requirements are better managed in Aerospace Software Industry. Poor requirement management generally plagues the non-critical (life-wise) software life cycle. If the discipline of a DO-178B like standard is imposed on all projects, this problem would vanish. That would also mean expensive software. The trade-off is, of course, between 'expensive to buy' versus 'expensive to maintain'. You might want to visit my blog on Aerospace Software to check out some more posts on Requirement Management.

I'd really, really like to know a little bit more ...

2009-03-31T08:36:00.000+11:00