Lean Kanban Nordic Conference Presentation 13 March 2013 Stockholm

1. Project
management
driven
by
the
Top
Ten
Cri6cal
Improvements
quan%fied
Presenter:
Tom
Gilb
ENGINEERING/MANAGEMENT
Competitive Engineering is a revolutionary project a This stuff works. Competitive
Engineering contains powerful
management method, proven by organizations worldwide tools that are both practical and
Competitive Engineering documents Tom Gilb’s unique, ground-breaking simple – a rare combination.
Over the last decade, I have
approach to communicating management objectives and systems engineering applied Tom Gilb’s tools in a
requirements, clearly and unambiguously. variety of settings including
product development, service
Competitive Engineering is a revelation for anyone involved in management
13th
March
2013,
Stockholm
delivery, manufacturing, site
and risk control. Already used by thousands of managers and systems construction, IT, eBusiness,
engineers around the world, this is a handbook for initiating, controlling and quality, marketing, and
delivering complex projects on time and within budget. Competitive management, on projects of
various sizes. Competitive
Engineering copes explicitly with the rapidly changing environment that is a
Engineering is based on
reality for most of us today. decades of practical experience,
15:30
to
16:15
(stop
5
min
before
this)
Elegant, comprehensive and accessible, the Competitive Engineering feedback, and improvement,
methodology provides a practical set of tools and techniques that enable
and it shows.
b
readers to effectively design, manage and deliver results in any complex ERIK SIMMONS,
INTEL CORPORATION, REQUIREMENTS
organization – in engineering, industry, systems engineering, software, IT, the
ENGINEERING PRACTICE LEAD,
40
min.max
service sector and beyond. CORPORATE QUALITY NETWORK
BENEFITS OF COMPETITIVE ENGINEERING a Systems engineers should
find Competitive Engineering
• Used and proven by many the US Department of Defense
CitiGroup, IBM, Nokia and
organizations including HP, Intel, widely useful, with or without
the additional framework
• Detailed, practical and innovative coverage of key subjects
provided by Planguage. Even
“Stop
starBng
-­‐
Start
finishing”
without adopting Planguage as
including requirements specification, design evaluation, specification a whole there are numerous
quality control and evolutionary project management important principles and
• A complete,evaluating, managing and‘end-to-end’high quality solutions
techniques that can benefit any
proven and meaningful process for system project.
b
Conference,
Dataföreningen
specifying, delivering
• Rich in detail andon every page in scope, with thought-
DR. MARK W. MAIER, DISTINGUISHED
comprehensive ENGINEER AT THE AEROSPACE
provoking ideas CORPORATION AND CHAIR OF THE INCOSE
SYSTEMS ARCHITECTURE WORKING GROUP
Kompetens
COMPETITIVE ENGINEERING ENCOMPASSES
• Requirements specification
• Design engineering (including design specification and evaluation)
• Evolutionary project management
•
Project metrics Tom Gilb is an independent consultant
• Risk management and author of numerous books, articles
•
and papers. He is recognised as one of the
Priority management leading ‘thinkers’ within the IT community
• Specification quality control and has worked with managers and
•
engineers around the world in developing
Change control and applying his renowned methods.
Author photo: Bart van Overbeeke
Photography http://www.bvof.nl
Visit http://books.elsevier.com/companions
to access the complete Planguage glossary
http://books.elsevier.com
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
1

2. Talk
Summary
• When
projects
are
funded,
management
will
usually
list
a
handful
of
jus6fica6ons
or
expecta6ons.
– But
usually
too
vaguely.
–
Like
• 'Substan6ally
increase
produc6vity',
•
'Much
beIer
Flexibility’
•
'More
robust
system'.
Gilbs
‘prac6ce’
• Methods
=
(Evo,
Planguage,
Compe66ve
Engineering)
–
is
to
capture
and
agree
these
project
‘cri6cal
factors’,
– then
quan%fy
them
• so
they
are
crystal
clear,
• and
can
be
used
to
track
progress.
• All
projects
should
have
such
management
clarity
–
–
but
prac6cally
none
do.
– Management
likes
the
idea
of
this,
•
but
have
never
been
taught
it
at
'business
school'.
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
2

3. Case:
MulBnaBonal
Bank
2011
Cri6cal
Project
Objec6ves
‘not
clear’
• The CTO concluded that
none of their 100s of projects
had clear enough objectives,
or primary improvement requirements,
at their base.
12
March
2013
©
Gilb.com
3

4. Richard
Smith
“
I
aTended
a
3-­‐day
course
with
you
and
Kai
whilst
at
CiBgroup
in
2006”
12
March
2013
©
Gilb.com
4

5. Previous
PM
Methods:
No
‘Value
delivery
tracking’.
No
change
reacBon
ability
Richard
Smith
• “However,
(our
old
project
management
methodology)
main
failings
were
that
•
it
almost
totally
missed
the
ability
to
track
delivery
of
actual
value
improvements
to
a
project's
stakeholders,
•
and
the
ability
to
react
to
changes
– in
requirements
and
– priority
– for
the
project's
dura6on”
12
March
2013
©
Gilb.com
5

6. We
only
had
the
illusion
of
control.
But
liTle
help
to
testers
and
analysts
Richard
Smith
• “The
(old)
toolset
generated
lots
of
charts
and
stats
•
that
provided
the
illusion
of
risk
control.
• But
actually
provided
very
liTle
help
to
the
analysts,
developers
and
testers
actually
doing
the
work
at
the
coal
face.”
12
March
2013
©
Gilb.com
6

7. The
proof
is
in
the
pudding;
Richard
Smith
• “The
proof
is
in
the
pudding;
• I have used Evo
• (albeit in disguise sometimes)
• on two large, high-risk projects in front-office investment
banking businesses,
• and several smaller tasks. “
12
March
2013
©
Gilb.com
7

8. Experience: if top level requirements
are separated from design, the
‘requirements’ are stable!
Richard
Smith
• “On the largest critical project,
• the original business functions & performance
objective requirements document,
• which included no design,
• essentially remained unchanged
• over the 14 months the project took to deliver,….”
“
I
aTended
a
3-­‐day
course
with
you
and
Kai
whilst
at
CiBgroup
in
2006”,
Richard
Smith
12
March
2013
©
Gilb.com
8

9. Dynamic
(Agile,
Evo)
design
tesBng:
not
unlike
‘Lean
Startup’
Richard
Smith
• “… but the detailed designs
– (of the GUI, business logic, performance characteristics)
• changed many many times,
• guided by lessons learnt
• and feedback gained by
• delivering a succession of early deliveries
• to real users”
“
I
aTended
a
3-­‐day
course
with
you
and
Kai
whilst
at
CiBgroup
in
2006”,
Richard
Smith
12
March
2013
©
Gilb.com
9

10. It
looks
like
the
stakeholders
liked
the
top
level
system
qualiBes,
on
first
try
Richard
Smith
– “ In the end, the new system responsible for 10s of
USD billions of notional risk,
– successfully went live
– over one weekend
– for 800 users worldwide ,
– and was seen as a big success
– by the sponsoring stakeholders.”
“
I
aTended
a
3-­‐day
course
with
you
and
Kai
whilst
at
CiBgroup
in
2006”
,
Richard
Smith
12
March
2013
©
Gilb.com
10

11. I
conclude
• What
we
ohen
call
• Requirement:
‘requirements’
– Stakeholder-­‐valued
– Use
cases
system
state
– User
stories
– Under
defined
– FuncBons
condiBons
– Features
• Are
really
bad
amateur
• Design:
a
‘means’
to
designs,
deliver
a
requirement
– for
unclear
higher-­‐level
requirements
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
11

12. Al
says
• “Perfection of means,
and
– confusion of ends,
– seems to characterize our
age”
• Albert
Einstein
• HTp://albert.bu.edu

13. And
Now
A
True
War
Story
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
13

14. The
Persinscom
IT
System
Case
He
who
does
not
learn
from
history
A
Man
Who
understood
that
Tuesday,
12
March
13
Is
doomed
to
repeat
it
©
Tom@Gilb.com
Top10
Method
14
“a
bird
in
the
hand
is
worth
two
in
the
Bush”
<-­‐tsg

15. The
Evo
Planning
Week
at
DoD
• Monday
– Define
top
Ten
cri6cal
objec6ves,
quan6ta6vely
– Agree
that
thee
are
the
main
points
of
the
effort/project
• Tuesday
– Define
roughly
the
top
ten
most
powerful
strategies,
–
for
enabling
us
to
reach
our
Goals
on
Time
• Wednesday
– Make
an
Impact
Es6ma6on
Table
for
Objec6ves/Strategies
– Sanity
Test:
do
we
seem
to
have
enough
powerful
strategies
to
get
to
our
Goals,
with
a
reasonable
safety
margin?
• Thursday
– Divide
into
rough
delivery
steps
(annual,
quarterly)
– Derive
a
delivery
step
for
‘Next
Week’
• Friday
– Present
these
plans
to
approval
manager
(Brigadier
General
Palicci)
– get
approval
to
deliver
next
week
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
15

16. US
Army
Example:
PERSINSCOM:
Personnel
System
Monday
ßThe
Top
Ten
CriBcal
ObjecBves
Were
decided
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
Slide
16

17. Sample
of
Objec6ves/Strategy
defini6ons
US
Army
Example:
PERSINSCOM:
Personnel
System
• Example
of
one
of
the
Objec4ves:
Customer
Service:
Type:
CriBcal
Top
level
Systems
ObjecBve
Gist:
Improve
customer
percepBon
of
quality
of
service
provided.
Scale:
ViolaBons
of
Customer
Agreement
per
Month.
Meter:
Log
of
ViolaBons.
Past
[Last
Year]
Unknown
Number
çState
of
PERSCOM
Management
Review
Record
[NARDAC]
0
?
ç
NARDAC
Reports
Last
Year
Fail
:
<must
be
beTer
than
Past,
Unknown
number>
çCG
Goal
[This
Year,
PERSINCOM]
0
“Go
for
the
Record” ç
Group
SWAG
.
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
Slide
17

18. US
Army
Example:
PERSINSCOM:
Personnel
System
Tuesday
The
Top
Ten
CriBcal
Strategies
For
reaching
the
ßobjecBves
Were
decided
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
Slide
18

19. Sample
of
Objec6ves/Strategy
defini6ons
US
Army
Example:
PERSINSCOM:
Personnel
System
A
Strategy
(Top
Level
of
Detail)
Example of a real Impact Estimation table from a Pro-Bono Client (US DoD, US Army, PERSINSCOM).
Thanks to the Task Force, LTC Dan Knight and Br. Gen. Jack Pallici for full support in using my methods.
Source: Draft, Personnel Enterprise, IMA End-State 95 Plan, Vision 21, 2 Dec. 1991. “Not procurement sensitive”.
Example of one of the Objectives:
Technology
Investment:
Customer Service:
Gist: Improve customer perception of quality of service provided.
Scale: Violations of Customer Agreement per Month.
Meter: Log of Violations.
Gist:
Exploit
investment
in
high
Past [1991] Unknown Number State of PERSCOM Management Review
Record [NARDAC] 0 ?  NARDAC Reports 1991
Must : <better than Past, Unknown number> CG
return
technology.
Plan [1991, PERSINCOM] 0 “Go for the Record”  Group SWAG
Technology Investment:
Impacts:
producBvity,
customer
Exploit investment in high return technology. Impacts: productivity, customer service and conserves resources.
An example of one of the strategies defined.
service
and
conserves
resources.
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
Slide
19

20. Wednesday:
Day
3
of
5
of
‘Feasibility
Study
• We
made
a
rough
evaluaBon
– of
how
powerful
our
strategies
might
be
– in
relaBon
to
our
objecBves
• Impact
EsBmaBon
Table
– 0%
Neutral,
no
±
impact
– 100%
Gets
us
to
Goal
level
on
Bme
– 50%
Gets
us
half
way
to
Goal
at
deadline
–
-­‐10%
has
10%
negaBve
side
effect
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
20

21. US
DoD.
Persinscom
Impact EstimationTable:
Designs
Requirements
Estimated Impact
of
Design
-> Requirements
29.5
:1
Tuesday, 12 March 13
©
Tom@Gilb.com
Top10
Method
Slide 21

22. US
Army
Example:
PERSINSCOM:
Personnel
System
29.5
:1
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
Slide
22

23. Thursday:
Day
4
of
5
of
‘Feasibility
Study
• We
looked
for
a
way
to
deliver
some
stakeholder
results,
next
week
• 1 1 1 1 1 1 Unity
– 1% increase at
least
– 1 stakeholder
– 1 quality/value
– 1 week delivery
cycle
– 1 function focus
– 1 design used
12
March
2013
©
Gilb.com
23

24. Next
weeks
Evo
Step??
• “You won’t believe we never thought of this, Tom!’
• The step:
– When the Top General Signs in
– Move him to the head of the queue
• Of all people inquiring on the system.
• Can you deliver it next week?
– Its already done: ‘If General, move to head of queue’
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
24

25. Let’s
take
a
look
at
the
generic
standard
(my
guideline
for
you)
for
star4ng
a
project
in
this
way.
• Top
10
CriBcal
Business
Value
ObjecBves
– Used
to
drive
iteraBve
project
value
delivery
cycles
– Evo
Startup
Standard,
Jan
12
2013
– hTp://www.gilb.com/dl562
– Evo
Project
Management
Standard,
Jan
12
2013
– hTp://www.gilb.com/dl563
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
25

26. The
5
day
Project
Startup
Standard
for
‘Evo’
Agile
Project
Management
1 Top 10 Critical Objectives
Quantified
2 Top 10 Strategies identified
3 Impact Estimation of strategy
effect on Objectives
4 Find short term value delivery
steps
5 Get buy in from management to
proceed
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
26

27. Day
1:
Project
Objec6ves:
The
top
few
criBcal
objecBves
quanBfied.
•
Objective: Determine, clarify, agree critical few project objectives – results – end
states
• Process:
– Analyze current documentation and slides, for expressed or implied objectives (often implied
by designs or lower level objectives)
– Develop list of Stakeholders and their needs and values
– Brainstorm ‘top ten’ critical objectives names list. Agree they are top critical few.
– Detail definition in Planguage – meaning quantify and define clearly, unambiguously and in
detail (a page)
– Quality Control Objectives for Clarity: Major defect measurement. Exit if less than 1.0 majors
per page
– Quality Control Objectives for Relevance: Review against higher level objectives than project
for alignment.
– Define Constraints: resources, traditions, policies, corporate IT architecture, hidden
assumptions.
– Define Issues – yet unresolved
– Note we might well choose to several things in parallel.
• Output: A solid set of the top few critical objectives in quantified and measurable
language. Stakeholder data specified.
• Participants: anybody who is concerned with the business results, the higher the
management level the better.
• End of Day Process: meet 30 minutes with any responsible interested managers to
present the outputs, and to get preliminary corrections and go-ahead.
• Note: this process is so critical and can be time consuming, so if necessary it can
spill over to next day. Perhaps in parallel with startup of the strategy identification.
Nothing is more critical or fundamental than doing this well.
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
27

28. Lack
of
clear
top
level
project
objecBves
has
seen
real
projects
fail
for
$100+
million:
personal
experience,
real
case
Quan6fied
Objec6ves
(in
Planguage),
What
they
should
have
done
Bad
Objec6ves,
for
8
years
8
years
earlier!
1.
Central
to
The
Corpora4ons
business
strategy
is
to
be
the
Robustness.Testability:
world’s
premier
integrated
<domain>
service
provider.
2.
Will
provide
a
much
more
efficient
user
experience
Type: Software Quality Requirement.
Version: 20 Oct 2006-10-20
3.
Drama4cally
scale
back
the
%me
frequently
needed
aPer
the
Status: Demo draft,
last
data
is
acquired
to
4me
align,
depth
correct,
splice,
merge,
Stakeholder: {Operator, Tester}.
recompute
and/or
do
whatever
else
is
needed
to
generate
the
desired
products
Ambition: Rapid-duration automatic testing of
<critical complex tests>, with extreme operator setup
4.
Make
the
system
much
easier
to
understand
and
use
than
and initiation.
has
been
the
case
for
previous
system.
Scale: the duration of a defined
5.
A
primary
goal
is
to
provide
a
much
more
produc%ve
system
[Volume] of testing, or a defined [Type],
development
environment
than
was
previously
the
case.
by a defined [Skill Level] of system
operator, under defined [Operating
6.
Will
provide
a
richer
set
of
func4onality
for
suppor%ng
next-­‐ Conditions].
genera4on
logging
tools
and
applica4ons.
7.
Robustness
is
an
essen4al
system
requirement
(see
par4al
Goal [All Customer Use, Volume = 1,000,000 data
rewrite
in
example
at
right)
items, Type = WireXXXX Vs DXX, Skill = First Time
Novice, Operating Conditions = Field, {Sea Or
8.
Major
improvements
in
data
quality
over
current
prac4ce
Desert}. <10 mins.
12
March
2013
©
Gilb.com
28

29. PROJECT VALUE CLARITY:
2010 Bank top 10 Objectives quantified on day 1
P&L-­‐Consistency&T
P&L:
Scale:
total
adjustments
btw
Flash/Predict
and
Opera6onal-­‐Control.Timely.Trade-­‐Bookings
Scale:
number
of
trades
Actual
(T+1)
signed
off
P&L.
per
day.
Past
60
Goal:
15
per
day
that
are
not
booked
on
trade
date.
Past
[April
20xx]
20
?
Speed-­‐To-­‐Deliver:
Scale:
average
Calendar
days
needed
from
New
Idea
Front-­‐Office-­‐Trade-­‐Management-­‐Efficiency
Scale:
Time
from
Ticket
Approved
unBl
Idea
OperaBonal,
for
given
Tasks,
on
given
Markets.
Launch
to
trade
updaBng
real-­‐Bme
risk
view
Past
[2009,
Market
=
EURex,
Task
=Bond
ExecuBon]
2-­‐3
months
?
Past
[20xx,
FuncBon
=
Risk
Mgt,
Region
=
Global]
~
80s
+/-­‐
45s
??
Goal
[Deadline
=End
20xz,
Market
=
EURex,
Task
=Bond
ExecuBon]
5
Goal
[End
20xz,
FuncBon
=
Risk
Mgt,
Region
=
Global]
~
50%
beTer?
days
Managing
Risk
–
Accurate
–
Consolidated
–
Real
Time
Opera6onal-­‐Control:
Scale:
%
of
trades
per
day,
where
the
calculated
Risk.Cross-­‐Product
Scale:
%
of
financial
products
that
risk
metrics
can
economic
difference
between
OUR
CO
and
Marketplace/Clients,
is
less
be
displayed
in
a
single
posiBon
bloTer
in
a
way
appropriate
for
the
than
“1
Yen”(or
equivalent).
trader
(i.e.
–
around
a
benchmark
vs.
across
the
curve).
Past
[April
20xx]
10%
change
this
to
90%
NH
Goal
[Dec.
20xy]
100%
Past
[April
20xx]
0%
95%.
Goal
[Dec.
20xy]
100%
Risk.Low-­‐latency
Scale:
number
of
Bmes
per
day
the
intraday
risk
Opera6onal-­‐Control.Consistent:
Scale:
%
of
defined
[Trades]
failing
full
metrics
is
delayed
by
more
than
0.5
sec.
Past
[April
20xx,
NA]
1%
Past
STP
across
the
transacBon
cycle.
Past
[April
20xx,
Trades=Voice
Trades]
[April
20xx,
EMEA]
??%
Past
[April
20xx,
AP]
100%
Goal
[Dec.
20xy]
0%
95%
Risk.Accuracy
Past
[April
20xx,
Trades=eTrades]
93%
Risk.
user-­‐configurable
Scale:
???
preTy
binary
–
feature
is
there
or
not
Goal
[April
20xz,
Trades=Voice
Trades]
<95
±
2%>
–
how
do
we
represent?
Goal
[April
20xz,
Trades=eTrades]
98.5
±
0.5
%
Past
[April
20xx]
1%
Goal
[Dec.
20xy]
0%
Opera6onal
Cost
Efficiency
Scale:
<Increased
efficiency
(Straight
Opera6onal-­‐Control.Timely.End&OvernightP&L
Scale:
number
of
through
processing
STP
Rates
)>
Bmes,
per
quarter,
the
P&L
informaBon
is
not
delivered
Bmely
to
the
Cost-­‐Per-­‐Trade
Scale:
%
reducBon
in
Cost-­‐Per-­‐Trade
defined
[Bach-­‐Run].
Goal
(EOY
20xy,
cost
type
=
I
1
–
REGION
=
ALL)
Reduce
cost
by
60%
Past
[April
20xx,
Batch-­‐Run=Overnight]
1
Goal
[Dec.
20xy,
Batch-­‐ (BW)
Run=Overnight]
<0.5>
Past
[April
20xx,
Batch-­‐Run=
T+1]
1
Goal
[Dec.
Goal
(EOY
20xy,
cost
type
=
I
2
–
REGION
=
ALL)
Reduce
cost
by
x
%
20xy,
Batch-­‐Run=End-­‐Of-­‐Day,
Delay<1hour]
1
Goal
(EOY
20xy,
cost
type
=
E1
–
REGION
=
ALL)
Reduce
cost
by
x
%
Opera6onal-­‐Control.Timely.IntradayP&L
Scale:
number
of
Bmes
per
Goal
(EOY
20xy,
cost
type
=
E
2
–
REGION
=
ALL)
Reduce
cost
by
100%
day
the
intraday
P&L
process
is
delayed
more
than
0.5
sec.
Goal
(EOY
20xy,
cost
type
=
E
3
–
REGION
=
ALL)
Reduce
cost
by
x
%
12
March
2013
©
Gilb.com
29

30. Real
Bank
Project
:
Project
Progress
Testability
Quan6fica6on
of
the
most-­‐cri6cal
project
objec6ves
on
day
1
Opera6onal-­‐Control.Timely.Trade-­‐Bookings
Scale:
number
of
trades
P&L-­‐Consistency&T
P&L:
Scale:
total
adjustments
btw
Flash/Predict
and
ONE
PAGE
PROJECT
REQUIREMENTS
QUANTIFIED
Actual
(T+1)
signed
off
P&L.
per
day.
Past
60
Goal:
15
per
day
that
are
not
booked
on
trade
date.
Past
[April
20xx]
20
?
Speed-­‐To-­‐Deliver:
Scale:
average
Calendar
days
needed
from
New
Idea
Front-­‐Office-­‐Trade-­‐Management-­‐Efficiency
Scale:
Time
from
Ticket
Opera6onal-­‐Control:
Approved
unBl
Idea
OperaBonal,
for
given
Tasks,
on
given
Markets.
Past
[2009,
Market
=
EURex,
Task
=Bond
ExecuBon]
2-­‐3
months
?
Launch
to
trade
updaBng
real-­‐Bme
risk
view
Past
[20xx,
FuncBon
=
Risk
Mgt,
Region
=
Global]
~
80s
+/-­‐
45s
??
ONE
PAGE
PROJECT
REQUIREMENTS
QUANTIFIED
Goal
[Deadline
=End
20xz,
Market
=
EURex,
Task
=Bond
ExecuBon]
5
Goal
[End
20xz,
FuncBon
=
Risk
Mgt,
Region
=
Global]
~
50%
beTer?
days
Managing
Risk
–
Accurate
–
Consolidated
–
Real
Time
Scale:
%
of
trades
per
day,
where
the
Opera6onal-­‐Control:
Scale:
%
of
trades
per
day,
where
the
calculated
Risk.Cross-­‐Product
Scale:
%
of
financial
products
that
risk
metrics
can
economic
difference
between
OUR
CO
and
Marketplace/Clients,
is
less
be
displayed
in
a
single
posiBon
bloTer
in
a
way
appropriate
for
the
calculated
economic
difference
between
than
“1
Yen”(or
equivalent).
trader
(i.e.
–
around
a
benchmark
vs.
across
the
curve).
Past
[April
20xx]
10%
change
this
to
90%
NH
Goal
[Dec.
20xy]
100%
Past
[April
20xx]
0%
95%.
Goal
[Dec.
20xy]
100%
Risk.Low-­‐latency
Scale:
number
of
Bmes
per
day
the
intraday
risk
OUR
CO
and
Marketplace/Clients,
is
less
Opera6onal-­‐Control.Consistent:
Scale:
%
of
defined
[Trades]
failing
full
metrics
is
delayed
by
more
than
0.5
sec.
Past
[April
20xx,
NA]
1%
Past
STP
across
the
transacBon
cycle.
Past
[April
20xx,
Trades=Voice
Trades]
[April
20xx,
EMEA]
??%
Past
[April
20xx,
AP]
100%
Goal
[Dec.
20xy]
0%
95%
than
“1
Yen”(or
equivalent).
Past
[April
20xx,
Trades=eTrades]
93%
Goal
[April
20xz,
Trades=Voice
Trades]
<95
±
2%>
Risk.Accuracy
Risk.
user-­‐configurable
Scale:
???
preTy
binary
–
feature
is
there
or
not
–
how
do
we
represent?
Goal
[April
20xz,
Trades=eTrades]
98.5
±
0.5
%
Past
[April
20xx]
1%
Goal
[Dec.
20xy]
0%
Opera6onal
Cost
Efficiency
Scale:
<Increased
efficiency
(Straight
Past
[April
20xx]
10%
Opera6onal-­‐Control.Timely.End&OvernightP&L
Scale:
number
of
through
processing
STP
Rates
)>
Bmes,
per
quarter,
the
P&L
informaBon
is
not
delivered
Bmely
to
the
Cost-­‐Per-­‐Trade
Scale:
%
reducBon
in
Cost-­‐Per-­‐Trade
defined
[Bach-­‐Run].
Goal
[Dec.
20xy]
100%
Goal
(EOY
20xy,
cost
type
=
I
1
–
REGION
=
ALL)
Reduce
cost
by
60%
Past
[April
20xx,
Batch-­‐Run=Overnight]
1
Goal
[Dec.
20xy,
Batch-­‐ (BW)
Run=Overnight]
<0.5>
Past
[April
20xx,
Batch-­‐Run=
T+1]
1
Goal
[Dec.
Goal
(EOY
20xy,
cost
type
=
I
2
–
REGION
=
ALL)
Reduce
cost
by
x
%
20xy,
Batch-­‐Run=End-­‐Of-­‐Day,
Delay<1hour]
1
Goal
(EOY
20xy,
cost
type
=
E1
–
REGION
=
ALL)
Reduce
cost
by
x
%
Opera6onal-­‐Control.Timely.IntradayP&L
Scale:
number
of
Bmes
per
Goal
(EOY
20xy,
cost
type
=
E
2
–
REGION
=
ALL)
Reduce
cost
by
100%
day
the
intraday
P&L
process
is
delayed
more
than
0.5
sec.
Goal
(EOY
20xy,
cost
type
=
E
3
–
REGION
=
ALL)
Reduce
cost
by
x
%
12
March
2013
©
Gilb.com
30

31. Example
of
EsBmaBng
the
‘Business
Value’
of
a
Technical
IT
System
Improvement
(20xx)
This
is
an
example
made
to
reason
about
specificaBon
standards
and
is
not
supposed
to
be
a
real
spec.
Just
realisBc.
12
March
2013
©
Gilb.com
31

32. Acer:
Security
Administra6on
Compliance:
Security Administration Compliance:
Ambition: to become compliant and to remain continuously compliant with all current officially binding security administration requirements
both from THE CORP and Regulatory Authorities.
Quantified
Scope: Account Opening and Entitlement Reporting.
Scale: % compliant with THE CORP Information Security Standards (CISS) [THE CORP Information Security Office (CISO)] on a defined
System or Process.
Definition
Note: CISS is an officially binding security administration requirement with which we must become compliant.
========= Benchmarks ===============================
Past [CISS = RSA and IBECS ISAG Compliance Matrix [Regional Security Administration and IBECS Independent Security Administration
Group, October 2003] 25% <- JC, Nov-03
Benchmarks
=
Systems
Analysis
Note: The RSA/IBECS Compliance Matrix originates from Otto Chan and is based on CISS.
========= Targets ===================================
Wish [Deadline = March 2004, Systems = High Criticality Systems] 100%
Wish [Deadline = June 2004, Systems = {Medium & Low} Criticality Systems] 100%
Values,
unknown
costs
Note: Wishes are stakeholder valued levels that we are not yet sure we can deliver in practice, on time, so we are not promising anything yet,
just acknowledging the desire.
Goal [Deadline = March 2004, Systems = High Criticality Systems] 90%±5%
Goal [Deadline = June 2004, Systems = {Medium & Low} Criticality Systems] 90%±5%
RealisBc
Project
Goal [Midline = February 2004] 50%±10% “intermediary goal short of 100%”
Targets
Val/€
Note: Goal levels are what we think we can really promise and focus on. These types of goals push us into thinking about possible
Evolutionary result delivery steps.
Stretch [Deadline = March 2004, Systems = High Criticality Systems] 95%±5% Values,
if
Stretch [Deadline = June 2004, Systems = {Medium & Low} Criticality Systems] 95%±5%
enough
Note: Stretch levels are something that we might be able to achieve if we have sufficient resources, focus and technology available, but we
resources
leh
are not sure of that yet. We are NOT promising it now! So this is a way to hold the ideals up in case those things become available.
12
March
2013
©
Gilb.com
32

33. Day
2:
Project
Strategies
and
Architecture:
the
top
few
criBcal
strategies
for
reaching
the
criBcal
objecBves
•
Objective: to identify the top ‘ten’ most critical strategic decisions or architectures;
the ones that will contribute or enable us most, to reach our primary objective goal
levels on time.
• Process:
– Analysis of current documentation and slides to identify candidate strategies,
implied or expressed.
– Brainstorming of the ‘names’ of the specific strategy list, the top ten and a set of
less powerful ideas (say 11-30)
– Detail each top ten strategy sufficiently to understand impacts (on objectives,
time and costs)
– Specify, for each strategy all critical related information (like stakeholders, risks,
assumptions, constraints, etc.)
– Quality Control for clarity – correct unclear items. Exit based on defect level, or
not.
– Likely that work will need to be done in parallel in order to do ten strategies to a
rich level of specification.
• Output: A formal strategy specification, ready for evaluation, and decomposition and
delivery of partial value results.
• Participants: system architects, project architects, strategy planners. And members
of the project team who will be in on the entire weeks process. The major input here
is technical and organizational strategy (the means to reach the objectives)
• End of Day Process: : meet 30 minutes with any responsible interested managers to
present the outputs, and to get preliminary corrections and go-ahead.
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
33

34. Acer:
VERY
TOP
LEVEL
PROJECT
STRATEGIES
Note: These very top level project strategies specify how we are going to achieve the top level project goals.
Identify Binding Compliance Requirements Strategy:
Gist: Identify all officially binding security administration requirements with which we must become compliant both from THE CORP and Regulatory
Authorities.
System Control Strategy:
How
much
do
these
strategies
cost?
Gist: a formal system or process we can use to decide what characteristics a [system; default = appication] has with regard to our compliance,
performance, availability and cost goals
Note: an inspection process, for instance
Define and implement inspection for security administration-related business requirements specifications
Define and implement inspection for [systems; default = applications] which already exist in CitiTech environments
Note: systems include applications, databases, data service and machines. Project ACER ought to be extensible.
System Implementation Strategy:
Gist: a formal system or process we can use to actually change a [system; default = application] so that it meets our compliance, performance, availability
and cost goals
All systems ought to feed EERS How
much
impact
on
our
4
Goals
Publish best practices for developing security administration requirement specifications
Publish a security administration requirement specification template
do
these
strategies
have?
Application technology managers are service providers in the formal change process, that are required to meet all project goals within defined timescales
Find Services That Meet Our Goals Strategy:
Gist: a formal system or process we can use to evaluate security administration services offered by internal and external services providers so that we
can meet our defined goals
Note: this strategy avoids pre-supposition that one solution is the only option (EG all applications must migrate to RSA and that RSA is the only security
administration services offering)
Use The Lowest Cost Provider Strategy:
Gist: use the services provider that meets all signed-off project goals for the lowest $US cost.
Note: if all project goals can be met by more than one services provider, the provider offering the lowest $US cost for meeting the goals and no more than
the goals ought to be used
12
March
2013
©
Gilb.com
34

35. See
enlarged
view
of
this
slide
in
following
slides.
This
is
a
1-­‐page
overview
Defining
a
Design/SoluBon/Architecture/Strategy
(Planguage,
CE
Design
Template)
1.
enough
detail
to
esBmate,
2.
some
impact
asserBon,
3.
AssumpBons,
Risks,
Issues
Orbit
Applica6on
Base:
(formal
Cross
reference
Tag)
=====================
Priority
and
Risk
Management
=====================
Type:
Primary
Architecture
OpBon
Assump6ons:
<Any
assumpBons
that
have
been
made>.
============
Basic
InformaBon
==========
A1:
FCCP
is
assumed
to
be
a
part
of
Orbit.
FCxx
does
not
currently
exist
and
is
Dec
Version:
Nov.
30
20xx
16:49,
updated
2.Dec
by
telephone
and
in
meeBng.
14:34
20xx
6
months
into
Requirements
Spec.
<-­‐
Picked
up
by
TsG
from
dec
2
Status:
Drah
discussions
AH
MA
JH
EC.
Owner:
Brent
Barclays
Consequence:
FCxx
must
be
a
part
of
the
impact
esBmaBon
and
costs
raBng.
Expert:
Raj
Shell,
London
A2:
Costs,
the
development
costs
will
not
be
different.
All
will
base
on
a
budget
of
Authority:
for
differenBaBng
business
environment
characterisBcs,
Raj
Shell,
Brent
say
$nn
mm
and
3
years.
The
o+
Barclays(for
overview)
costs
may
differ
slightly,
like
$n
mm
for
hardware.
MA
AH
3
dec
Source:
<Source
references
for
the
informaBon
in
this
specificaBon.
Could
include
people>.
A3:Boss
X
will
conBnue
to
own
Orbit.
TSG
DEC
2
Various,
can
be
done
later
BB
A4:
the
schedule,
3
years,
will
constrained
to
a
scope
we
can
in
fact
deliver,
OR
we
Gist:
risk
and
P/L
aggregaBon
service,
which
also
provides
work
flow/adjustment
and
will
be
given
addiBonal
budget.
If
not
“I
would
have
a
problem”
<-­‐
BB
outbound
and
inbound
feed
support.
Currently
used
by
Rates
ExtraBusiness,
Front
Office
and
Middle
Office,
USA
&
UK.
A5:
the
cost
of
expanding
Orbit
will
not
be
prohibiBve.
<-­‐
BB
2
dec
Descrip6on:
<Describe
the
design
idea
in
sufficient
detail
to
support
the
esBmated
impacts
A6:
we
have
made
the
assumpBon
that
we
can
integrate
Oribit
with
PX+
in
a
and
costs
given
below>.
sensible
way,
even
in
the
short
term
<-­‐
BB
D1:
ETL
Layer.
Rules
based
highly
configurable
implementaBon
of
the
ETL
PaTern,
Dependencies:
<State
any
dependencies
for
this
design
idea>.
which
allows
the
data
to
be
onboarded
more
quickly.
Load
and
persist
new
data
D1:
FCxx
replaces
Px+
in
Bme.
?
tsg
2.12
very
quickly.
With
minimal
development
required.
-­‐>
Business-­‐Capability-­‐Time-­‐To-­‐ Risks:
<Name
or
refer
to
tags
of
any
factors,
which
could
threaten
your
esBmated
impacts>.
Market,
Business
Scalability
R1.
FCxx
is
delayed.
MiBgaBon:
conBnue
to
use
Pxx
<-­‐
tsg
2.12
D2:
high
performance
risk
and
P/L
aggregaBon
processing
(Cube
Building).
-­‐>
R2:
the
technical
integra6on
of
Px+
is
not
as
easy
as
thought
&
we
must
redevelop
Timeliness,
P/L
ExplanaBon,
Risk
&
P/L
Understanding,
Decision
Support,
Business
Oribit
Scalability,
Responsiveness.
R3:
the
and
or
scalability
and
cost
of
coherence
will
not
allow
us
to
meet
the
D3:
Orbit
supports
BOTH
Risk
and
P/L
-­‐>
P/L
ExplanaBon,
Risk
&
P/L
Consistency,
delivery.
Risk
&
P/L
Understanding,
Decision
Support.
R4:
scalability
of
Orbit
team
and
infrastructure,
first
year
especially
<-­‐
BB.
People,
D4:
a
flexible
configurable
workflow
tool,
which
can
be
used
to
easily
define
new
environments,
etc.
workflow
processes
-­‐>
Books/Records
Consistency,
Business
Process
EffecBveness,
Business
Capability
Time
to
Market.
R5:
re
Cross
Desk
reporBng
Requirement,
major
impact
on
technical
design.
Solu6on
not
currently
known.
Risk
no
soluBon
allowing
us
to
report
all
P/L
D5:
a
report
definiBon
language,
which
provides
90+%
of
the
business
logic
contained
with
Orbit,
allows
a
quick
turnaround
of
new
and
enhanced
reports
with
Issues:
<Unresolved
concerns
or
problems
in
the
specificaBon
or
the
system>.
minimal
regression
tesBng
and
release
procedure
impact.
-­‐>
P/L
ExplanaBon,
Risk
&
I1:
Do
we
need
to
put
the
fact
that
we
own
Orbit
into
the
objecBves
(Ownership).
P/L
Understanding,
Business
Capability
Time
to
Market,
Business
Scalability.
MA
said,
other
agreed
this
is
a
huge
differenBator.
Dec
2.
D6:
Orbit
GUI.
UBlizes
an
Outlook
Explorer
metaphor
for
ease
of
use,
and
the
Dxx
I2:
what
are
the
Bme
scales
and
scope
now?
Unclear
now
BB
Express
Grid
Control,
to
provide
high
performance
Cube
InterrogaBon
Capability.
-­‐>
I3:
what
will
the
success
factors
be?
We
don’t
know
what
we
are
actually
being
Responsiveness,
People
Interchangeability,
Decision
Support,
Risk
&
P/L
asked
to
do.
BB
2
dec
20xx
Understanding.
I4:
for
the
business
other
than
flow
opBons,
there
is
sBll
a
lack
of
clarity
as
to
what
12
March
2013
D7:
downstream
feeds.
A
configurable
event-­‐driven
data
export
service,
which
is
ilb.com
©
G 35
the
requirements
are
and
how
they
might
differ
from
Extra
and
Flow
OpBons.
BB
used
to
generate
feeds
.
-­‐>
Business
Process
EffecBveness,
Business
Capability
Time
I5:
the
degree
to
which
this
opBon
will
be
seen
to
be
useful
without
Intra
Day.
BB
2

36. Design
Spec
Enlarged
1
of
2
Spec
Headers
Detailed
Descrip6on
and
-­‐>
Impacted
Objec6ves
Orbit
Applica6on
Base:
(formal
Cross
Descrip6on:
<Describe
the
design
idea
in
sufficient
detail
to
support
the
esBmated
reference
Tag)
impacts
and
costs
given
below>.
D1:
ETL
Layer.
Rules
based
highly
configurable
implementaBon
of
the
ETL
PaTern,
Type:
Primary
Architecture
OpBon
which
allows
the
data
to
be
onboarded
more
quickly.
Load
and
persist
new
data
very
quickly.
With
minimal
development
required.
-­‐>
Business-­‐Capability-­‐Time-­‐To-­‐Market,
====
Basic
InformaBon
==========
Business
Scalability
Version:
Nov.
30
20xx
16:49,
updated
2.Dec
by
telephone
and
in
meeBng.
D2:
high
performance
risk
and
P/L
aggregaBon
processing
(Cube
Building).
-­‐>
14:34
Timeliness,
P/L
ExplanaBon,
Risk
&
P/L
Understanding,
Decision
Support,
Business
Status:
Drah
(PUBLIC
EXAMPLE
EDIT)
Scalability,
Responsiveness.
Owner:
Brent
Barclays
D3:
Orbit
supports
BOTH
Risk
and
P/L
-­‐>
P/L
ExplanaBon,
Risk
&
P/L
Consistency,
Expert:
Raj
Shell,
London
The
Detailed
descripBon
is
Risk
&
P/L
Understanding,
Decision
Support.
Authority:
for
differenBaBng
business
D4:
a
flexible
configurable
workflow
tool,
which
can
be
used
to
easily
define
new
environment
characterisBcs,
Raj
Shell,
Brent
Barclays(for
overview)
useful,
workflow
processes
-­‐>
Books/Records
Consistency,
Business
Process
EffecBveness,
Business
Capability
Time
to
Market.
Source:
<Source
references
for
the
informaBon
in
this
specificaBon.
Could
•
to
understand
costs
D5:
a
report
definiBon
language,
which
provides
90+%
of
the
business
logic
include
people>.
Various,
can
be
done
later
BB
•
to
understand
impacts
on
contained
with
Orbit,
allows
a
quick
turnaround
of
new
and
enhanced
reports
with
minimal
regression
tesBng
and
release
procedure
impact.
-­‐>
P/L
ExplanaBon,
Risk
&
Gist:
risk
and
P/L
aggregaBon
service,
which
also
provides
work
flow/
your
objecBves
(see
‘-­‐>’)
P/L
Understanding,
Business
Capability
Time
to
Market,
Business
Scalability.
D6:
Orbit
GUI.
UBlizes
an
Outlook
Explorer
metaphor
for
ease
of
use,
and
the
Dxx
adjustment
and
outbound
and
inbound
feed
support.
Currently
used
•
to
permit
separate
Express
Grid
Control,
to
provide
high
performance
Cube
InterrogaBon
Capability.
-­‐>
Responsiveness,
People
Interchangeability,
Decision
Support,
Risk
&
P/L
by
Rates
Extra
Business,
Front
Office
and
Middle
Office,
USA
&
UK.
Understanding.
implementaBon
and
value
D7:
downstream
feeds.
A
configurable
event-­‐driven
data
export
service,
which
is
delivery,
incrementally
used
to
generate
feeds
.
-­‐>
Business
Process
EffecBveness,
Business
Capability
Time
to
Market.
12
March
2013
•
as
basis
for
test
planning
©
Gilb.com
36

37. Design
Spec
Enlarged
2
of
2
====
Priority
&
Risk
Management
========
Risks:
<Name
or
refer
to
tags
of
any
factors,
which
could
threaten
your
es4mated
impacts>.
Assump6ons:
<Any
assump4ons
that
have
R1.
FCxx
is
delayed.
MiBgaBon:
conBnue
to
use
Pxx<-­‐
tsg
been
made>.
2.12
Risks
specificaBon:
A1:
FCCP
is
assumed
to
be
a
part
of
Orbit.
FCxx
does
not
R2:
the
technical
integra6on
of
Pgroup
as
easy
as
thought
•
shares
x+
is
not
risk
currently
exist
and
is
Dec
20xx
6
months
into
ASSUMPTIONS:
2
knowhow
&
we
must
redevelop
Oribit
Requirements
Spec.
<-­‐
Picked
up
by
TsG
from
dec
R3:
the
and
or
scalability
ermits
redesign
to
not
discussions
AH
MA
JH
EC.
•
broadcasts
criBcal
•
p and
cost
of
coherence
will
allow
us
to
meet
the
delivery.
factors
art
op he
impact
R4:
scalability
of
Orbit
team
and
itnfrastructure,
first
year
Consequence:
FCxx
must
be
a
pfor
f
tresent
miBgate
he
risk
and
fwill
not
bre-­‐ifferent.
especially
<-­‐
BB.
People,
llows
relisBc
esBmates
•
aenvironments,
etc.
esBmaBon
and
costs
raBng.
A2:
Costs,
the
development
costs
uture
e
d
examinaBon
All
will
base
on
a
budget
of
say
$
nn
mm
and
3
years.
of
cost
and
impacts
R5:
re
Cross
Desk
reporBng
Requirement,
major
impact
on
technical
design.
Solu6on
not
currently
known.
Risk
no
The
ops
costs
may
differ
slightly,
like
$risk
aor
•
helps
n
mm
fnalysis
soluBon
allowing
us
to
report
all
P/L
hardware.
MA
AH
3
dec
•
are
an
integral
A3:Boss
X
will
conBnue
to
own
Orbit.
TSG
DEC
2
Issues:
<Unresolved
concerns
or
problems
in
the
specifica4on
or
the
system>.
part
of
the
tdesign
we
I1:
Do
we
need
to
put
the
fIssues:
e
own
Orbit
into
the
A4:
the
schedule,
3
years,
will
constrained
o
a
scope
act
that
w
specificBon
can
in
fact
deliver,
OR
we
will
be
given
addiBonal
objecBves
(Ownership).
MA
swhen
answered
can
•
aid,
other
agreed
this
is
a
huge
budget.
If
not
“I
would
have
a
problem”
<-­‐
BB
differenBator.
Dec
2.
A5:
the
cost
of
expanding
Orbit
will
not
be
prohibiBve.
<-­‐
I2:
what
are
the
Bme
scales
and
scope
na
risk
turn
into
ow?
Unclear
now
BB
BB
2
dec
•
shares
group
I3:
what
will
the
success
factors
be?
We
don’t
know
what
we
A6:
we
have
made
the
assumpBon
that
we
can
integrate
are
actually
being
asked
to
do.
BB
2
dec
20xx
Oribit
with
PX+
in
a
sensible
way,
even
in
the
short
term
knowledge
I4:
for
the
business
other
than
flow
opBons,
there
is
sBll
a
<-­‐
BB
•
makes
sure
we
don’t
lack
of
clarity
as
to
what
the
requirements
are
and
how
they
Dependencies:
<State
any
dDEPENDENCIES:
idea>.
ependencies
for
this
design
forget
to
analyze
later
might
differ
from
Extra
and
Flow
OpBons.
BB
D1:
FCxx
replaces
Px+
in
Bme.
?
tsg
2.12
12
March
2013
©
Gilb.com
degree
to
which
this
opBon
will
be
seen
to
be
37
I5:
the
useful
without
Intra
Day.
BB
2
dec

38. Day
3:
EvaluaBon
of
Strategies
using
Impact
EsBmaBon:
our
best
esBmates
with
experience
and
risk.
How
sure
are
of
the
major
strategy
decisions.
•
Objective: to estimate to primary effects and all side effects of all top critical strategies
on all top critical objectives, and on some resources (time, cost, effort). The estimates
will be backed up by evidence, or their credibility will be rated low.
• Process:
– Using the objectives and strategies developed on first 2 days as inputs
– Populate an Impact Estimation table (aka Value Decision Table) with estimates of the expected result
of deploying defined strategies. Estimate main intended impacts
– And all side effects (on other core objectives)
– And on all resources (time, money. Effort)
– Estimate ± ranges
– Specify evidence and sources for estimates
– Determine Credibility level
– Quality Control the IE table against standards (Rules for IE in CE book), for possible ‘exit’ (meets
standards)
– Lots of parallel work needed and expected to do a good job.
• Output:
– A fairly decent Impact Estimation table, possibly a several level set of them.
• This will tell us if it is safe to proceed (we have good enough strategies)
• And it will help us prioritize high value deliveries soon.
• Participants: architects, planners, anybody with strong views on any of the strategies.
The team for the week.
• Note: it might be necessary and desirable, now or later, to do this impact estimation
process at 2 or 3 related levels (Business, Stakeholder, IT System) in order to see the
Business-IT relationship clearly. This might exceed time limits and be done parallel or
later.
• End of Day Process: meet 30 minutes with any responsible interested managers to
present the outputs, and to get preliminary corrections and go-ahead.
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
38

39. Checking
that
Strategies
give
Impact
towards
our
Value
Objec6ves
Usability

40. Acer
Project:
Impact
EsBmaBon
Table
Strategies
Objectives
Impacts
12
March
2013
©
Gilb.com
40

41. Actual
Example
deciding
between
5
systems
(named
a,
b
,c,
d,
e)
aher
merging
some
banks.
Using
Kai
Gilb’s
Evo
Tool
to
automate
the
relaBonships
and
PresentaBon
12
March
2013
©
Gilb.com
41

42. 12
March
2013
©
Gilb.com
42

43. 12
March
2013
©
Gilb.com
43

44. 12
March
2013
©
Gilb.com
44

45. 12
March
2013
©
Gilb.com
45

46. Day
4:
Evolu6onary
Step
Decomposi6on:
what
are
the
high
value
short
term
value
delivery
steps
we
can
execute?
•
Objec6ve:
to
idenBfy
near
team
candidates
for
real
value
delivery
to
real
stakeholders.
What
can
we
do
for
real
next
week!
• Process:
– IdenBfy
highest
value
(to
costs)
strategies
and
sub-­‐sets
of
strategies
– Decompose
into
doable
subsets
in
weekly
to
monthly
cycles
of
result
delivery
– Plan
the
near
steps
(1
or
more)
in
detail
so
that
we
are
ready
to
execute
the
step
in
pracBce.
• Who
does
it,
main
responsible,
team.
• Expected
measurable
results
and
costs
• Stakeholder
involved
in
receiving
• Test
process
(for
value)
• Output:
1
or
more
potenBal
steps
for
value
delivery
to
some
stakeholders,
a
plan
good
enough
to
approve
and
execute
in
pracBve.
• Par6cipants:
Project
Management,
architects
prepared
to
decompose
architecture
in
pracBce.
The
weeks
team
for
this
start
up
study.
• End
of
Day
Process:
meet
30
minutes
with
any
responsible
interested
managers
to
present
the
outputs,
and
to
get
preliminary
correcBons
and
go-­‐ahead.
Tuesday,
12
March
13
©
Tom@Gilb.com
Top10
Method
46

47. Thursday:
Day
4
of
5
of
‘Feasibility
Study
• We
looked
for
a
way
to
deliver
some
stakeholder
results,
next
week
• 1 1 1 1 1 1 Unity
– 1% increase at
least
– 1 stakeholder
– 1 quality/value
– 1 week delivery
cycle
– 1 function focus
– 1 design used
12
March
2013
©
Gilb.com
47

48. Impact
EsBmaBon:
Value-­‐for-­‐Money
Delivery
Table
29.5
:
1
12
March
2013
©
Gilb.com
Slide
48

49. Next
weeks
Evo
Step?
• “You won’t believe we never thought of this, Tom!’
• The step:
– When the Top General Signs in
– Move him to the head of the queue
• of all people inquiring on the system.
12
March
2013
©
Gilb.com
49

50. 1
1
1
1
1
1
Method
or
The
‘Unity’
Method
for
Value
DecomposiBon
– 1%
increase
at
least
– 1
stakeholder
– 1
quality
or
value
– 1-­‐week
delivery
cycle
– 1
funcBon
focus
– 1
design
used
12
March
2013
©
Gilb.com
50