Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Shifting Left - Identifying Risk Earlier through Requirement

No description
by

Dan Powell

on 15 October 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Shifting Left - Identifying Risk Earlier through Requirement

Identifying Risk Earlier through Requirements Testing
Shifting Left
Presented by: Dr Dan Powell
Access Testing
daniel.powell@accesstesting.com

40% of projects meet schedule, budget and quality goals. The best organisations are 10 times more successful than worst organisation [IBM, 2008]

Large, technically complex Australian projects have a poor performance record with a failure rate of over 75%”. [for the Business Council of Australia, 2012]

Of value

Over time

78% of respondents reported that “business is usually or always out of synch with project requirements”

Over budget

The State of Our Industry

McKinsey and Co, 2012.
From 5400 large IT projects across various domains

Critical Success Factor

Critical Success Factor
Requirements
Problem 1:
How We Communicate
Requirements
Resolution to Problem 1:
Quantify & Address Uncertainty
Identify and quantify

Uncertainty

Communicate Uncertainty

Plan and Manage for Uncertainty

Resolve Uncertainty
Align All Stakeholders
Quantifying
known-unknowns
enables:
Planning and management of risk to value
Focused, conversations and a shared understanding
Management of scope and change
Models Help!!!
Problem 2:
What We Communicate
Over-specified
Over-constrained
Design specified without doing design
Resolution to Problem 2:
Quality Scales & Measures
Define scales against which to assess qualities
Determine how to measure against those scales
Test the suitability of designs using scales and measures
Let designers design
There is a difference between enterprise systems and technology led solutions
The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen."

The programmer comes home with 12 loaves of bread.

http://www.mckinsey.com/insights/business_technology/delivering_large-scale_it_projects_on_time_on_budget_and_on_value
Identifying Uncertainty - Techniques
Review / Desk Checking (status quo for many)
Ad-Hoc
Variable but mostly ineffective
Time consuming
Managed Inspection (currently accepted best practice)
Checklist-Based and Scenario-Based
Outcomes usually exceed those of ad-hoc review - but variable
Managed Model-Based Analysis and Walk-through (e.g. RQA)
Systematic and Repeatable
Most effective and efficient (by a long way)
Enables communication and resolution

Model-Based Requirements and RQA
5 X as likely to identify omissions than document walk-through
The average project delivers
56% of expected value
The average project's requirements define only
54% of expected behaviour clearly
So, on the average project
You get what you ask for!!!
For every 100 requirements RQA identifies an average of between 15 to 20 issues posing major risk above those identified through managed inspection
... and it is much more efficient at identifying issues posing major risk than currently accepted best practice
Full transcript