Categories: Requirements Management
Situation: You want to give your approach to requirements a little more thought.
Is requirements definition your biggest challenge when defining success on your project? Or is that that one concern among many?
JAMA software and Raven flow are conducting a survey related to requirements gathering that you may be interested in. At the very least, its a quick way to give some thought to what matters to you relative to requirements gathering.
Here are some early results from John Simpson of JAMA ...
Respondents are: 37% are Analysts, 24% Project Managers, 12% Product Development/Engineering, 6% Product Managers, 5% Exec Mngt
54% of respondents work for companies with $100 million annual revenue or more (25% are $1 billion +) so a good range of large and small companies
The biggest requirements challenges were:
70% gaining a clear understanding of what our customers want
64% ensuring what’s being built is what was planned
63% documenting all the requirements
The goals of their projects:
75% are for enhancing existing products
59% bringing new products to market
25% reducing costs of producing existing products
29% of them considered their companies “Risk Takers” when it comes to innovation, the largest camp was “Market Readers” at 36%, 16% were the “Low Cost Provider”
73% rely on customers and partners for new product ideas – so external collaboration is critical
In terms of complexity, 39% of respondents on average had 500+ requirements for typical project, 22% have 1,000 or more requirements
In terms of the burden of change management, over a third of respondents spend 25% or more of their time dealing with changes to requirements
How they measure success:
87% customer satisfaction
52% quality/safety ratings
34% cost savings
32% revenue
25% speed to market (interesting in terms of positioning)
And the one they personally cared the most about was “customer satisfaction” at 61% – I thought it was interesting that “revenue” wasn’t higher (it was only 6%)
In terms of delivering projects on time and on budget:
For over half of respondents, the project success rate is 40% or less; so they’re feeling the requirements pain
The top reasons were:
74% scope creep
64% missed or poorly defined requirements
61% unrealistic schedules or expectations
51% team communication/collaboration an issue
44% Misunderstanding of what customers want
39% Issues w/ change management
29% Lack of executive support
What they personally find most frustrating:
Missed or poorly defined requirements was #1, unrealistic schedules #2, misunderstanding of the customer #3
The majority define “collaboration” as these 3 things: everyone is in sync on the latest version of the requirements(80%), all items in centralized place (72%), everyone has access (66%)
No surprise, 80% currently use Word or Excel to define and communicate requirements; 31% currently use requirements definition software, 35% use a requirement management software, 40% using email
On the list of tools they’d like to use in 2008 – 59% chose requirements modeling & visualization, 62% requirements collaboration & management
In terms of processes:
37% are using a mix (so having tools built to handle various processes is probably a good thing)
26% traditional Waterfall
16% using RUP or some variation of it
And despite all the attention around Agile these days, only 5% answered using some flavor of Agile process currently – was a bit surprise Agile wasn’t higher
54% of respondents work for companies with $100 million annual revenue or more (25% are $1 billion +) so a good range of large and small companies
The biggest requirements challenges were:
70% gaining a clear understanding of what our customers want
64% ensuring what’s being built is what was planned
63% documenting all the requirements
The goals of their projects:
75% are for enhancing existing products
59% bringing new products to market
25% reducing costs of producing existing products
29% of them considered their companies “Risk Takers” when it comes to innovation, the largest camp was “Market Readers” at 36%, 16% were the “Low Cost Provider”
73% rely on customers and partners for new product ideas – so external collaboration is critical
In terms of complexity, 39% of respondents on average had 500+ requirements for typical project, 22% have 1,000 or more requirements
In terms of the burden of change management, over a third of respondents spend 25% or more of their time dealing with changes to requirements
How they measure success:
87% customer satisfaction
52% quality/safety ratings
34% cost savings
32% revenue
25% speed to market (interesting in terms of positioning)
And the one they personally cared the most about was “customer satisfaction” at 61% – I thought it was interesting that “revenue” wasn’t higher (it was only 6%)
In terms of delivering projects on time and on budget:
For over half of respondents, the project success rate is 40% or less; so they’re feeling the requirements pain
The top reasons were:
74% scope creep
64% missed or poorly defined requirements
61% unrealistic schedules or expectations
51% team communication/collaboration an issue
44% Misunderstanding of what customers want
39% Issues w/ change management
29% Lack of executive support
What they personally find most frustrating:
Missed or poorly defined requirements was #1, unrealistic schedules #2, misunderstanding of the customer #3
The majority define “collaboration” as these 3 things: everyone is in sync on the latest version of the requirements(80%), all items in centralized place (72%), everyone has access (66%)
No surprise, 80% currently use Word or Excel to define and communicate requirements; 31% currently use requirements definition software, 35% use a requirement management software, 40% using email
On the list of tools they’d like to use in 2008 – 59% chose requirements modeling & visualization, 62% requirements collaboration & management
In terms of processes:
37% are using a mix (so having tools built to handle various processes is probably a good thing)
26% traditional Waterfall
16% using RUP or some variation of it
And despite all the attention around Agile these days, only 5% answered using some flavor of Agile process currently – was a bit surprise Agile wasn’t higher
Posted on: April 16, 2008 10:34 PM |
Permalink
