I gave this talk at PMOZ last week.

1. Can’t read the font?
Get it here: AlphaMack AOE
Requirements
and Scope
Project Performance information
Better and Faster
with Requirements Traceability.
Craig Brown - PMOZ 2011

2. Better project controls!
Your business analysts should already be tracking this data

3. 1. What’s requirements traceability?
2. Controlling scope
3. See an Example and think about how I can use this
LEARNING GOALS

4. As a project manager I want to find
better ways to control project scope,
and thus avoid schedule and budget
problems.

5. I know there are many aspects to
project success…
•Budget compliance
•Scope compliance
•Schedule compliance
•Quality compliance
•Value generated
•People learning from the process
•Simply getting it finished

6. And I know expectation
Management is a key to #winning
Perceived
Experience
Success =
Expectation

7. You don’t need to convince me.
I know scope issues are at the heart of
managing my projects

8. You said that Requirements
Traceability can provide a way to
improve project performance.
T ell me more.

9. Disclaimer

10. Lets run through
Requirements Traceability
101

11. What is…
Short answer: the relationships
between requirements and between
a requirement and the project that
is addressing them.

12. Vertical tracing
Horizontal tracing

13. Horizontal traceability
Component
Sub feature
Component Sub component
Feature Rule
Component Sub component
Sub feature
Rule
Component
Rule
Helps ensure completeness and identify
dependencies.

14. Mission
Strategy Strategy Strategy
Programme Programme
Project Goals
Goals Goals
Project Goals Project Goals Project Goals
Business Business
Project Goals
Requirements Requirements
Features Features
You can, and should, use More
NFRs
traceability to ensure Features
NFRs Process changes
alignment to the big picture
Process changes

15. Vertical traceability
Defined
Designed
Built
Integrated
Helps spot where requirements are
Accepted
bounced, de-scoped or otherwise
Deployed
mangled.
Used by analysts and testers.

17. Defined Design Built SIT UAT Deployed
R1 SD2.1 T C102 UT C12
R1.1 SD2.2 T C102
R2 De-scoped
R3 SD2.4 T C103-108 UT C15
R3.1 SD2.4.1 T C103, 109 UT C15, 16
R3.2 SD2.4.2 T C 110-112 UT C 17

18. T hat’s traceability

19. Now tell me how I can
use this beyond test
plans and coverage
checks?

20. Tracks several useful attributes, such
as; Requirement description, Owner,
Value/motivation, Priority,
Tracks Tracks relationships between a
Requirement, Solution Component (i.e.
requirements WBS element), T est case
through project End to end through stage gates
lifecycle and/or development stages
Binary state at each stage; Done/Not
done
Requirements Traceability

21. Not
Done
Done

22. 80%
80%
80%
80%
80%
80%

23. Requirements
IIBA/BABOK IEEE
1. When reading the BABOK Guide it is 1. A condition or capability needed by a
vital that ‘requirements’ be user to solve a problem or achieve an
understood in the broadest possible objective
sense. 2. A condition or capability that must
2. Requirements include but are not be met or possessed by a system or
limited to past, present and future system component to satisfy a
conditions or capabilities in an contract, standard, specification,
enterprise and descriptions of or other formally imposed document
organisational structures, roles, 3. A documented representation of a
processes, policies, rules and condition or capability as in (1) or
information systems. (2)

24. Scope: T he sum of the products, services, an results to be
provided as a project.
Scope Project scope: T he work that must be performed to deliver
a product, service or result with the specified features
and functions
Product scope: T he features and functions that
characterise the product, service or result.
Scope creep: Adding features and functionality (project
scope) without addressing the effects of time, costs and
resources, or without customer approval
PMI definitions

25. Requirements = Scope
Product Scope Drives Project Scope
Product/Service
Work to be Done
Capabilities
Requirements Budget and Schedule

26. Of course, you need to run work
through your lifecycle in small
batches to get best results.

27. You could get this nice visual of what’s done and
what’s yet to be completed.
200
180
160
140
120
100
80
60
40
20
-
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Work done Work remaining

28. Of course it won’t be a flat progression.
200
180
160
140
120
100
80
60
40
20
-
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Work done Work remaining

29. You could also break your report down into various states
Defined Designed
Defined
Defined Designed Built
Defined
Defined Designed Built T ested
Designed Built T ested
Deployed
Designed Built T ested Deployed
Watch the ‘cumulative flow’

31. T here is something else as well.

32. 2%

34. It doesn’t really matter
why requirements change.
We just know they do.

36. 500
450 466
400
350 380
300
250 308
200
200
Jan 249
Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2% 4% 6% 8%

37. 500
450 466
400
350 380
300
250 308
200
200
Jan 249
Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2% 4% 6% 8%
25% 54% 90% 133%

38. 8%
6%
4%
200
2%
180
160
140
120
100
80
60
40
20
-
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Work done Work remaining

39. 25%
20%
Scope changes over time
15%
10%
5%
0%
-5%
-10%
-15% What’s your monthly scope change rate? Is it under control?
-20% Do you know your company’s baseline?
-25%
Do you know your industry average?

40. We can use control charts to manage our
scope variations to limits… and in planning

41. 250
200
150
100
50
-
Work to do Work done Work remaining
How Traceability can help you track project progress
Requirements Defined > Work Done > Work Remaining
Release scheduling based on actual progress.

42. 2000
1500
1000
500
0
16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun 16-Jul 16-Aug 16-Sep 16-Oct 16-Nov 16-Dec 16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun
Work to do Work remaining Work done

43. 2000
1500
1000
500
0
16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun 16-Jul 16-Aug 16-Sep 16-Oct 16-Nov 16-Dec 16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun
Work to do Work remaining Work done

44. 2000
1500
1000
500
0
16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun 16-Jul 16-Aug 16-Sep 16-Oct 16-Nov 16-Dec 16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun
Work to do Work remaining Work done

45. 2000
1500
1000
500
0
16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun 16-Jul 16-Aug 16-Sep 16-Oct 16-Nov 16-Dec 16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun
Work to do Work remaining Work done

46. 2000
1500
1000
500
0
16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun 16-Jul 16-Aug 16-Sep 16-Oct 16-Nov 16-Dec 16-Jan 16-Feb 16-Mar 16-Apr 16-May 16-Jun
Work to do Work remaining Work done

47. We got >>> 2% permonitoring and
After measuring,
month
proactively managing the
stakeholders and requirements

48. Requirements
Growth v Delivery 2000
1500
1000
500
0

49. 250
200
150
100
50
-
Work to do Work done Work remaining

50. 2000
1500
~ 2000 1000
Story Points
500
0
Work to do Work remaining Work done
See the
250 pattern?
200
~ 250 150
Stories 100
50
-
Work to do Work done Work remaining

51. May June July….
Number of requirements
Number Completed this month
Number remaining
Requirements by size
Small
Medium
Large

52. Go collect your data and share with me
Better Projects Blog
www.betterprojects.net
/Measuring Requirements/
http://www.betterprojects.net/p/measuring-requirements.html

53. 1. Lean how requirements drive project scope
2. And how project requirements change can be
anticipated
3. So that project budgets and schedules can properly
managed!
LEARNING GOALS

54. Included as a
standard
Requirements activity in the
BABOK,
Is derived from
Systems
Traceability is
Engineering, a standard
BA activity Is used for
ISO90001:
2000
Is part of the compliance
Requirements
Management
area (REQM) in
CMMI
Requirements Traceability is a standard project activity
Despite industry standards, Requirements Traceability is not always done, or done
well. It’s performance should be encouraged.

55. @brown_note
BetterProjects.net
Craig.Brown@BetterProjects.net
au.linkedin.com/in/craigwbrown