The document discusses the reasons for project failures within the Canadian government and emphasizes the need for agile methodologies in project management to enhance efficiency and effectiveness. It criticizes the current rigid governance processes that often lead to theoretical documentation without real-world validation, contributing to high project risks and losses. The document advocates for a shift towards experimentation and a more dynamic approach to project management to improve outcomes and better meet citizen needs.

1. Why do Projects Fail?

2. Because…
Because…
Why do you think projects fail?
Question Time

3. Let’s Look Under the Hood!

4. Why Does the Government Exist?
The intent of the Government is to:
 Protect Canadian Citizens
 Make a better life for Canadian Citizens
Departments attempt to do this through the successful,
agile adaptive and measurable delivery of
Program services

5. The GC Value Chain
Inputs Activities Outputs Outcomes Citizen Value
Procurement
Financial
Management Human Resources Information
Technology
Infrastructure Components / Secondary Value Chains
Government of Canada Primary Value Chain
Program Specific or SSC General Applications
+
SSC Infrastructure Services
Real Property
Services Policy Instruments Legal Services

6. What We
Don't Know
We Don't
Know
What We
Know
What We Know
We Don't Know
Project Risk Chart
Current State Risk?
6
These are outlined in the
current Project Risk
Matrix
This is current state
planning metrics:
• Financial
• Work Break Down
Estimates
• Requirements
• Architecture
• Capability
• Capacity
This is managed by the
vendor via change control
after contract award /
implementation
Identifying ALL the risk!

7. Where do we Start?
7
empirical
[em-pir-i-kuh l]
Adjective
1. derived from or guided by experience or experiment.
2. provable or verifiable by experience or experiment.
Create empirical data versus written theories..

8. Current State Processes & Governance
8
Do our current state governance and processes help us or constrain us from
achieving our desired outcomes?

9. Current Project Gate Framework
9
Total
Effort /
Value Detailed Design
Specification
Detailed Requirements
Specification
Detailed Project Plan
High-Level Plan, Requirements,
Architecture & Business Case
Time
Requirements
Frozen
RFP
Released
Contract
Award
Implementation
/assumption validation
truly begins
If planning assumptions
are correct – value
delivered in the back end.
“Bet the Farm” approach.
Substantive
Business Case
Milestone Event
Effort Resource Cost
Consumed
Returned Value
Returned Value
Curve
Nothing delivered except
assumptive planning
documents “indicative vs.
substantive”
40% of budget &
schedule consumed
Result if (when)
planning
assumptions are
wrong
Project Failure
Curve

10. Current GC Project Gate Framework
“Bet the Farm Approach”
10
Idea Generation Initiation Planning Execution Deployment Closeout
Define the business problem, the
benefits, and align to SSC portfolio & GC
direction
Checklist
Define the project objective, describe /
analyze options, & recommend best option
Checklist
 Business Requirements
Document / Project Proposal
 Business Case
 Project Charter (preliminary)
 Security Requirements
 Task & Financial Authorization
(TFA)
(Planning)
PCRA 4:
 TB Submission
 TB Project Brief
 Independent Review
 Project Charter (Simplified
Preliminary)
 PCRA (Preliminary)
 Task & Financial Authorization
(TFA)
(Planning)
Define the project scope, schedule &
costs & describe project execution,
monitor & control
Checklist
 Project Charter (Final)
 Project Mgmt. Plan
 PCRA (Updated)
 Security Assessment Plan
 Concept of Operations
 Task & Financial Authorization
(TFA)
(Delivery)
PCRA 4:
 TB Submission
 TB Project Brief
 Independent Review
 Project Charter (Final)
 PCRA (Updated)
 Project Mgmt. Plan
 Security Assess. Plan
 TFA (Final)
 Transition Plan
 Concept of Operation (Updated)
 Authority to Operate (ATO)
PCRA 4:
 Independent Review
 Security Plan of Action &
Milestones (PAOM) Authority to
Operation (ATO)
Deliver the project objectives (build) and
define transition to operations.
Checklist
Deploy the service and transition to
operations.
Checklist
 Transition Plan (Updated)
 Deployment Lessons Learned
 Iterative Deployments
 Closeout Report
 Lessons Learned Report
 Customer Satisfaction Survey
 Security Plan of Action and
Milestones
 Closeout Report
 Lessons Learned Report
 Security Plan of Action &
Milestones
End Project, Apply Lessons Learned &
realize economic benefits
Checklist
Operations
Benefits
Realization
• Although we have all of this governance in place to mitigate risk – current state governance and
processes are actually is the highest risk approach
• There is no real world validation of assumptions until far too late in the process

11. Current GC Project Gating Framework
“Bet the Farm Approach”
11
• Creates theoretical documents that consume 50% of budget / schedule vs. creating empirical
evidence or creating real value for partner departments
• Armies of internal and contractor expense to create documentation
• In many cases the documents are not validated till after contract award or implementation /
operation phase of project – and are proven false
• Many documents are designed to communicate to multiple committees in order to
facilitate senior-level decision making
• The more layers of committees and silos the information travels – the less accurate the data – which
prevents good choices
• It takes a lot of time to do all this work – that creates no value to the partner – the time delays
translate into risk due to rate of technology change.
• Current state pushes value validation to the end after significant investment / contract award
• Vendors uncover assumptions via change control 2 – 5 x budget
Current state approach is the highest risk

12. Current GC Project Gating Framework
“Bet the Farm Approach”
1
2
We often assume that a contract at the end of procurement provides substantive
costs..
In actuality, it only provides the vendors costs based on what we could see as our
requriements as stated in the RFP..
It is only after implementation in a complex technology project that we validate our
requirement and in so doing – our true substantive costs emerge..
Unfortunately, we often have little to no bargaining power after contract award.

13. Current State Processes & Governance
1
3
Do we want to follow current state governance and processes or attain our
desired outcomes?
Attain Desired Outcomes
Follow Traditional
Governance
Our desired outcomes and our
current state processes and
governance are mutually
exclusive

14. Why Agile?
“I believe we need to replace a culture of risk aversion
with a culture of experimentation in government”.
Honorable Scott Brison Secretary of Treasury Board
CIO Summit, June 2017
No more 200-page RFPs. Instead, bake-offs and competitions. No more blind
marriages with big IT providers, instead constant dating. …more show and less tell,
more focus on working prototypes [so] that we really see what a company or
provider can do, more competition and more agile providers.
The Honourable Scott Brison,
President of the Treasury Board, May 2017
14

15. Align w/ Next Gen TBS IT Project Gating Model
1
5
https://www.gov.uk/service-manual/service-standard
Partnership on digital government service: A Canada-UK MOU on digital government
services will be established to improve digital government services and make sure that
they are simple, responsive, and easy to use.
– Justin Trudeau Personal Website..
https://pm.gc.ca/eng/news/2017/09/18/prime-minister-canada-announces-closer-collaboration-
united-kingdom

16. 1
6

17. OVER 2 GLENN
17

18. At your table discuss:
What factors have helped to
make projects successful in
your experience?

19. We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
INDIVIDUALS and interactions
over processes and tools
WORKING solutions*
over comprehensive documentation
Customer COLLABORATION
over contract negotiation
Responding to CHANGE
over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

20. Our highest priority is to
satisfy the customer
through early and continuous
delivery of valuable software.
Welcome changing
requirements, even late in
development. Agile
processes harness change
for the customer's
competitive advantage.
Deliver working software
frequently, from a couple of
weeks to a couple of months,
with a preference to the
shorter timescale.
Business people and
developers must work
together daily throughout
the project.
Build projects around
motivated individuals. Give
them the environment and
support they need, and trust
them to get the job done.
The most efficient and
effective method of
conveying information to and
within a development team
is face-to-face
conversation.
Working software is the
primary measure of
progress.
Agile processes promote
sustainable development.
The sponsors, developers,
and users should be able to
maintain a constant pace
indefinitely.
Continuous attention to
technical excellence and
good design enhances
agility.
Simplicity – the art of
maximizing the amount of
work not done--is essential.
The best architectures,
requirements, and designs
emerge from self-organizing
teams.
At regular intervals, the team
reflects on how to become
more effective, then tunes
and adjusts its behaviour
accordingly.

22. SELF ORGANIZE YOURSELVES
BASED ON:
•How long have you been at your
current employer?
•How much Agile experience do you
have?

23. At your table discuss:
•What did you notice?
•What did you learn about the
group?
•How is this different from your day
to day work?

26. EXERCISE: PENNY PROCESSING
• Form teams of 9-10 : 4 workers, 4 managers, 1 CEO
• Each team will be loaned a batch of 20 coins
• The project is to process all the coins in the batch
according to the instructions on the next slide
– A “processed” coin has been flipped over 4 times and added to
the stack.
• Use only your left hand; no props; every penny must stay
on table except when “in process”

27. ROUND 1
Make sure all pennies are on heads; pass all the pennies to worker 1.
Turn over each penny in the batch exactly once.
When all pennies in the batch have been processed, pass the entire batch to the next
team member for processing.
Managers – measure how long each worker spends flipping pennies
Timekeeper – measure how long it takes for all the pennies to be processed.
ROUND 2
Make sure all pennies are on heads; pass all the pennies to person 1.
Turn over each penny once and immediately pass the penny to the next team member
for processing.
Managers – measure how long each worker spends flipping pennies
Timekeeper – measure how long it takes for the first two pennies to be processed, and
for all the pennies to be processed.
ROUND 3
Make sure all pennies are on heads.
All pennies must be turned over 4 times and then placed in a done pile. Team decides
how to organize themselves.
Timekeeper – measure how long it takes for all the pennies to be processed

28. At your table discuss:
• What did you notice?
• Did anyone do quality control?
• Did everyone do the same amount of work?
• What do you notice about the times? Per
person? First work delivered?

30. MULTI-TASKING EXERCISE
1
2
3
4
5
6
7
8
9
10
A
B
C
D
E
F
G
H
I
J
42
43
44
45
46
47
48
49
50
51
Don’t Start Yet!

31. At your table discuss:
•What did you notice?
•How do you organize work in real
life? What consequences do you
see?

32. Juggling Multiple Things
Traditional approach: do it all at once, it’s all important!
1 2 43 65 7 8 9
Project 3
Project 1
Project 2
Time Lost to Multitasking
Project 1 Project 2 Project 3
Average Time to Market
= (9 + 9 + 9) / 3
= 9 months
Average Time to Market
= (2.5 + 5 + 7.5) / 3
= 5 months
Time Lost to Multitasking
Agile approach: prioritize and focus
Shared
Resources
Dedicated
Resources

33. Cost of Context Switching
0
20
40
60
80
100
1 2 3 4 5
Number of Projects
Working Time
Available per
Project
Loss to Context
Switching
http://www.umich.edu/~bcalab/multitasking.html
http://www.cio.com/article/29708/Multitasking_Wastes_Time_and_Money
http://headrush.typepad.com/creating_passionate_users/2005/03/your_brain_on_m.html
http://www.apa.org/releases/multitasking.html
http://www.joelonsoftware.com/articles/fog0000000022.html
http://www.codinghorror.com/blog/archives/000691.html

34. What is Lean?
Eliminate Waste:
1. Defects / Errors
2. Overproduction
3. Waiting
4. Not fully utilizing people
5. Transport
6. Inventory
7. Motion
8. Excessive processing
34
Four Big Lean Principles:
1. Create value, flow,
speed for client
2. End-to-end Process
efficiency more
important than Individual
efficiency
3. Make the process’
performance visible at a
glance
4. Proactive
experimentation and
learning

35. Telfer Executive Programs
Centre for Executive Leadership
45 O’Connor Street, Suite 350
Ottawa, Ontario K1P 1A4
Tel.: 613-564-0818
execed@telfer.uOttawa.ca
telfer.uOttawa.ca
Beyond Software
and
Agile + Lean
.
35

36. Agile/Scrum: Not Just to Develop Software….
• Creating complex surveys
• Developing policies
• Writing books
• Assessing job classifications
• Implementing process improvements
36

37. What kinds of projects do not lend themselves to the full,
formal Agile/Scrum approach?
• Simple projects where there are few, if any, unknowns.
• The requirements are stable
• But you can apply many of the tools, artifacts and roles
to different types of work, as appropriate.
37

38. 38
Requirements
Technology/Solutions
Far from
agreement
Close to
agreement
Close to
certain
Far from
certain

39. 39
Creating Complex Surveys

40. WORKING FACE TO FACE
Development Team: Communicate by email or work face to face?
40

41. Solve problem by Email
• Effort: 2 hours
• Elapsed Time: 2 weeks
 Paper trail
 Slow
 High effort
 Misunderstanding
 Perpetuates low trust
Solve problem Face-to-
Face
• Effort: 5 minutes
• Elapsed time: 5 minutes
 Fast
 Low effort
 Better understanding and
learning
 Builds trust
 Paper trail
41

42. JOB CLASSIFICATION
Managing Work In Progress
42 ©

43. 43

44. AGILE FOR LEAN PROCESS IMPROVEMENT
Using Agile to implement Lean
44 ©

45. Solution Experiment Headline Post-It with User Story
45
Impact = 21 Effort = 5
CREATE A STAFFING PROJECT
PLAN TEMPLATE
As a HIRING MANAGER, I need to know all of the steps in
staffing my vacancy, when they will occur, what my role is, how
much time I have to do my part, and when to expect my hire to
start the job.
Lead: JASON Assigned: Oct. 15, 2014

46. Definition of Done
46
Definition of “Done”
As a HIRING MANAGER, the PROJECT PLAN TEMPLATE let me
know all of the steps in staffing my vacancy, when they were to
occur, what my role was, how much time I had to do my part,
and when to expect my hire to start the job.
Comments:
• Use Barb’s template as starting point
• Test with managers who don’t use the process often

47. Work Breakdown – Bite Size Tasks
47
Verify
experime
nt results
Name:
Date:
Run
experime
nt for 10
files
Name:
Date:
Adjust
template
Name:
Date:
Discuss
template
with Project
team, Hiring
Manager
and HR
Advisors
suggest
adjustments
Name:
Date:
Design
prototype
template
Name:
Date:
Confirm
specific
issues to be
solved by
template
with Hiring
Managers
and HR
Advisors in
a focus
group
Name:
Date:
Adjust
tempate
Name:
Date:
Communi
cate
tempate
Name:
Date:
Go live
across
entire org
Name:
Date:
60 day
review
Name:
Date:
FirsttoLast
12345678910

48. To Do Doing Waiting
(internal)
Waiting
(external) Done!
Team
Availability
Since Last Meeting
WWW:
WDW:
WDD:
Problems
Solved
YTD
Make the project’s progress visible
Experiments
MajorExperimentsQuick
Wins
127

49. LEAN + AGILE
Which one, when?
49

50. Lean
Scrum
• Streamline core business process first
• Define which problems should be
solved by the COO vs by the CIO
• Solve the COO’s problems
• Develop working technology solutions
to solve the technology-solvable
problems
Lean or Scrum in a Case Management System Project?

51. Case Management Process
The current Review and Approval (new funds)
process has at least:
106 steps
73 handoffs
Typical “Best Case”:
7 drafts of Summary
6 official drafts of the Request*
*plus numerous “unofficial” drafts
51

52. What Problems Should it Solve?
Problems:
• Process designed for complex, high-risk files, but a significant percentage of
low-risk files go through it
• Lack of clarity and early discussion with clients to understand their needs to
create smooth path later
• Quality of incoming submissions was very low
• Unclear which experts review what, overlap
• Reviews are done sequentially, with little or no feedback between reviewers
• Takes too long to write a summary of the file
• Process is invisible so difficult to manage
• No viable process to track what happens after the decision
Enterprise CRM system, eight major problems identified during Lean
streamlining of the case management process:
52

53. 53
Invest early in
clear, root-cause
requirements, or
pay later

54. Fewer, clearer, requirements
= Reduced complexity and scope
= Lower levels of governance
= Faster, easier approval
54

55. Often
20%
Infrequently
30%
Rarely
or Never
50%
Features Used In Custom Software
Features used in custom software from:
Standish 2014 CHAOS report
55
Are we over-delivering software
by 50%?

56. Cost of Not Deeply Understanding Business Needs
First
Scope
Requirements
Development
Maintenance
Cost of Traditional Development vs Understanding Business
Less scope,
Higher
success
rate
Clearer scope and
understanding of
business to reduce
requirements by
80%
Fewer
requirements
= less
development
(28% of cost)
Lighter
solutions =
less
maintenance
(53% of cost)
Cost percentages from:
Standish 2014 CHAOS report
56

57. Technology Applies Differently to Algorithmic vs Heuristic Work
Algorithmic
• Process and end product well-defined
• Follow a set of instructions down a
single pathway to one conclusion.
• Inputs and outputs: mostly known,
well-established
• Mass-processing
Outputs: tax returns, passports, simple
permits, simple claims, border access,
Major positive technology impact
Heuristic
• No algorithm or single set of
instructions exists for it
• Create ideas and strategies, experiment
and create hypotheses until a solution
is found.
• Inputs and outputs: vague, ambiguous
• Customized
Outputs: policy, regulations, business cases,
ministerial or TB submissions, research,
investigations, media products, annual
reports, analysis, plans, briefing notes,
presentations
Typically minor positive technology impact
57

58. Key Root Causes in Heuristic Work
Business
solution:
Process,
Mindsets,
Leadership
Technology
Solution
currentlyexists
inmarketplace
Spikes in incoming volume not managed, causing…. 
Overloaded staff, unbalanced work so low productivity  
“Job” (desired outcomes) of the output or document unclear 
Lack of early engagement with clients 
Review and “success” criteria unclear to drafters & reviewers 
Review feedback given bilaterally, not shared across org  
Same process for simple AND complex files 
Process is invisible, not understood, status of file unclear 
No triggers to move work to the next step 
58

59. From
To
Requirements Binder
59

60. “This is no longer a $ 300k project that has to go through our
approval process. Four days of a Business Analyst and Coder and
the existing system will deliver the refined requirements”
-CIO, Federal Regulatory Agency, 2012
60
Another Example

61. 94 days 5 days
61
• Achieved without any spending on technology.
• Multi-million dollar case tracking project - opportunity to de-
scope – how much tracking required when process takes 5
days vs old state of 94 days?

62. Summary
• Agile/Scrum applies to the development of almost any complex
product in a chaotic environment
• Many of the tools are “borrowable”
• Lean + Agile can combine to clarify and reduce the
requirements, and then deliver them swiftly.
62