The document discusses factors that contribute to business project failures and how to improve requirements management. It notes that 65% of failures are due to management factors like poor leadership and communication, while 35% are from technical factors like unclear requirements. The top issues are business alignment, requirements management, and going over budget. Improving early buy-in from stakeholders and linking requirements to problems and benefits can increase requirements quality. An iterative approach is advocated over traditional waterfall development.

1. Can we agree what we really want? "
"
Solving the problem of business requirements"
Anthony Lewis
Managing Consultant – End to End Consulting

2. "
The Statistics of Failure*
Management factors account for 65% of project failures"
• Poor leadership in project delivery"
• Poor stakeholder communication / management"
• Insufficient management support"
Technical factors account for 35% of project failures"
• Inappropriate / ill defined software requirements"
• Inappropriate technical design
The top three issues… are:"
• Business Process Alignment"
• Requirements management"
• Overspends"
* Understanding the sources of IS Project Failure, McManus & Wood-Harper, 2007

3. "
ʻBetter Business Requirementsʼ *
Q: What is the most important factor in project success?"
A: "ʻSenior sponsorshipʼ"
"ʻInvolvement of end usersʼ"
"ʻQuality of requirementsʼ"
""
Q: What is the single biggest thing that would improve the
"quality of your organisation's requirements?"
A: "ʻEarlier buy in from the clientʼ"
"ʻA greater understanding by senior users of what they
"were signing up to.ʼ"
"ʻLinking requirements to an existing problem and
"perceived benefitsʼ"
*Project Magazine – May 2011

4. What does it mean?

5. "
“Methodology becomes a fetish, a procedure
used with pathological rigidity for its own
sake, not as a means to an end."
Used in this way, methodology provides relief
against anxiety; it insulates the practitioner
from risks and uncertainties of real
engagement with people and problems.”
The Fetish of Technique: methodology as a social defence, Wastell, 1996

6. Over the Waterfall
Requirements
Design
Implementa2on
Verifica2on
Maintenance

7. "
An iterative approach"
"
Think
Test
Design
Build

8. Translating whatʼs in our heads

9. Commanderʼs Intent
No campaign plan survives first contact with the enemy "
! ! ! ! ! !Carl von Clausewitz"
"
• Hereʼs what I think we face"
• Hereʼs what I think we should do"
• Hereʼs why"
• Hereʼs what we need to keep our eye on"
• Tell me what you think"
"
Karl Wick, 1983*"
* from Sources of Power, Gary Klein, 1999

10. “A problem well-defined is a problem half-solved.”"
" " " " "Charles Kettering
2
1
3
System
X
?
1 Terry registers on behalf of Bob
2 Bob receives confirmation email
3 Bob clicks on confirmation email and is registered
? Terry doesn’t get an email, and is not registered

11. The project funnel
Requirements
What
How
Resources
Who
Scope
Plan
When
Mandate
Why

12. Which becomes…
Physiological
needs
What
Safety
needs
Who
Social
/
emo2onal
needs
Aesthe2c
&
How
cogni2ve
needs
Self-­‐
Actualisa2on
Why
A Theory of Human Motivation, Abraham Maslow, 1943

13. Knowledge + Understanding = Meaning

14. Anthony Lewis
a.lewis@e2consulting.co.uk
razorlabs.co.uk/blog
@anthony__lewis