SPMH: When things go wrong

SPMH: When things go wrong
- And a preview of tomorrow -
Quick Survey
 
Do you have a working list of risks for your
junior project?
Do you have strategies for handling these
risks?
Let’s go through Phillips’ Risks
With the other people here, who are from your junior project, say:
Do the customers and developers agree on the junior project
objectives?
Have you done a project like this before?
Have you worked with the tools before?
Will the project solve a new problem or use new technology?
Implies “feature creep”
Increased likelihood of “backtracking”
Is the technical infrastructure in place?
What is the relationship between customers, users, and the team?
Is the implementation date realistic?
Do you have the project management skills needed?
What do the managers do?
 
All managers do these things:
Plan – ahead of time
Lead - during
Control – “after” (and during)
Project managers are “first level” managers:
Typically don’t hire and fire.
Do keep projects on schedule.
Often also are “lead developers.”
 
These are the
“risk managers”!
Control = plan + status +
corrective action
Control – as in “Control the risks”
What problem would Highsmith have
with this? (hint: think Fowler’s
‘feature devotion’)
Steve’s example
NCR Corp, Dundee Scotland
Risk assessment review, 1993
New generation of ATM
Concluded they should develop two different
cabinets, in case the riskier one failed.
Should people be allowed to
“go dark”?
Is there a point at which developers should
push back on manager status requests?
What Data to collect?
Measure Everything – or it will seem like
you’re measuring nothing
LOC, Function Points, GUI Screens
Errors, Cost-Per-Product, total time for specific
features
Do not ask people to collect status without
explaining why the project and organization
need it!?
Common Control Tool –
A Management Information Center
To us, Mickey Mouse
What’s the point?
But, we’d also like Management
keeping everyone else in line!
Will that third party deliver the
software to plug into ours, next week?
Will the integration test lab be
available for our project before the end
of this sprint?
Can we keep the customer from
changing his mind, again?
Over lunch, your
client suddenly
realizes what the
system you’re
building for him
really
 has to have!
The Control Goal is Risk Management
Risk avoidance –
Act ahead to reduce the chance
it occurs
Risk transfer –
Pass the “hot potato”
Risk mitigation –
Have a plan in place, in case it occurs
Have some “reserves” to apply when risks actually
arise.
This includes, especially, “slack” time / people
Have alternatives you can “jump to” if necessary.
Phillips’ “Proactive” Ideas
Prevention – act early
Elimination of error - TQM
Anticipation of failure – And plan around it
Management of
change – Adapt the
organization to
reduce risks
Well-known “bad ideas”
The ostrich approach:
 Ignoring all
risks, or pretending they don’t
exist
The prayer approach:
 Looking to a
higher being to solve all your
problems or to making them
disappear
The denial approach:
 Recognizing that certain
situations may cause problems for your project
but refusing to accept that these situations may
occur
Why do people dislike
risk management?
Risks are threats. (See p 253)
We like being optimistic.
Do you have to be confident to code well?
We are unhappy when making choices.
See Barry Schwartz’s TED talk
“Freedom of choice” is painful!
Change is hard. Ref Edgar Schein’s theory of
organizational change:
Principle 1: 
survival anxiety or guilt must be
greater than learning anxiety
Principle 2: 
Learning anxiety must be reduced
rather than increasing survival anxiety.
MIT’s Edgar Schein
3 Options When Making “Global”
Project Decisions
Continue on your current course
Take corrective action
Cancel the project
Quantify the decision?
 
“How much is that going to cost?”
A good place to work?
How much risk do you want?
Startups – Maybe 3% - 5% success rate?
Working for the government – 100% success rate?
In-between – Working for Apple, IBM, Microsoft,
or Google.
Risk Examples
Personnel shortfalls
Unrealistic schedules and budgets
Developing the wrong software functions
Developing the wrong user interface
Goldplating
Continuing stream of requirements changes
Shortfalls in externally furnished components
Real-time performance shortfalls
Straining computer science capabilities
Common ways Rose CSSE teams
manage risks
Matrix showing risks showing both:
Probability of occurrence, and
Consequence if it does occur
Teams then use this matrix to manage the
risks over time.
Example risk matrix
- showing some “scenarios” -
 
This is “An ongoing whiteboard risk management”!
Preview of Tomorrow –
Work Breakdown Structure (WBS)
See intro article
at
http://en.wikipedia.org/wiki/Work_breakdo
wn_structure
.
 
Goal is to partition the
work into a low-level
set of outcomes, then
do “tasks” required to
achieve those.
For tomorrow
Get together (starting now) with your teammates from
your junior project, and:
Create a “Work Breakdown Structure” (WBS) for your
junior project, like on the last slide.
Start with our “Trello tasks”
These might need enhancement!
Try to “partition” the work by outcomes. Then list key
“tasks” for each outcome.
Get to a low enough level, given what you know now
about the project, that we can organize these into a
plan, tomorrow in class.
Estimate 
how long 
you think each will take.
Slide Note

Flash Gordon spaceship from http://www.theregister.co.uk/Print/2011/11/24/spaceship_design/.

Embed
Share

Preview of handling risks, project objectives alignment, technical infrastructure, and project management skills for junior projects. Insights on manager roles, control, and risk management strategies.

  • Risks
  • Junior Projects
  • Project Management
  • Strategies

Uploaded on Feb 22, 2025 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. SPMH: When things go wrong - And a preview of tomorrow - 1

  2. Quick Survey Do you have a working list of risks for your junior project? Do you have strategies for handling these risks? 2

  3. Lets go through Phillips Risks With the other people here, who are from your junior project, say: Do the customers and developers agree on the junior project objectives? Have you done a project like this before? Have you worked with the tools before? Will the project solve a new problem or use new technology? Implies feature creep Increased likelihood of backtracking Is the technical infrastructure in place? What is the relationship between customers, users, and the team? Is the implementation date realistic? Do you have the project management skills needed? 3

  4. What do the managers do? All managers do these things: Plan ahead of time Lead - during Control after (and during) Project managers are first level managers: Typically don t hire and fire. Do keep projects on schedule. Often also are lead developers. These are the risk managers ! 4

  5. Control = plan + status + corrective action Control as in Control the risks What problem would Highsmith have with this? (hint: think Fowler s feature devotion ) 5

  6. Steves example NCR Corp, Dundee Scotland Risk assessment review, 1993 New generation of ATM Concluded they should develop two different cabinets, in case the riskier one failed. 6

  7. Should people be allowed to go dark ? 7

  8. Is there a point at which developers should push back on manager status requests? 8

  9. What Data to collect? Measure Everything or it will seem like you re measuring nothing LOC, Function Points, GUI Screens Errors, Cost-Per-Product, total time for specific features Do not ask people to collect status without explaining why the project and organization need it!? 9

  10. Common Control Tool A Management Information Center To us, Mickey Mouse What s the point? But, we d also like Management keeping everyone else in line! Will that third party deliver the software to plug into ours, next week? Will the integration test lab be available for our project before the end of this sprint? Can we keep the customer from changing his mind, again? Over lunch, your client suddenly realizes what the system you re building for him really has to have! 10

  11. The Control Goal is Risk Management Risk avoidance Act ahead to reduce the chance it occurs Risk transfer Pass the hot potato Risk mitigation Have a plan in place, in case it occurs Have some reserves to apply when risks actually arise. This includes, especially, slack time / people Have alternatives you can jump to if necessary. 11

  12. Phillips Proactive Ideas Prevention act early Elimination of error - TQM Anticipation of failure And plan around it Management of change Adapt the organization to reduce risks 12

  13. Well-known bad ideas The ostrich approach: Ignoring all risks, or pretending they don t exist The prayer approach: Looking to a higher being to solve all your problems or to making them disappear The denial approach: Recognizing that certain situations may cause problems for your project but refusing to accept that these situations may occur 13

  14. Why do people dislike risk management? Risks are threats. (See p 253) We like being optimistic. Do you have to be confident to code well? We are unhappy when making choices. See Barry Schwartz s TED talk Freedom of choice is painful! Change is hard. Ref Edgar Schein s theory of organizational change: Principle 1: survival anxiety or guilt must be greater than learning anxiety Principle 2: Learning anxiety must be reduced rather than increasing survival anxiety. MIT s Edgar Schein 14

  15. 3 Options When Making Global Project Decisions Continue on your current course Take corrective action Cancel the project Quantify the decision? How much is that going to cost? 15

  16. A good place to work? How much risk do you want? Startups Maybe 3% - 5% success rate? Working for the government 100% success rate? In-between Working for Apple, IBM, Microsoft, or Google. 16

  17. Risk Examples Personnel shortfalls Unrealistic schedules and budgets Developing the wrong software functions Developing the wrong user interface Goldplating Continuing stream of requirements changes Shortfalls in externally furnished components Real-time performance shortfalls Straining computer science capabilities 17

  18. Common ways Rose CSSE teams manage risks Matrix showing risks showing both: Probability of occurrence, and Consequence if it does occur Teams then use this matrix to manage the risks over time. 18

  19. Example risk matrix - showing some scenarios - This is An ongoing whiteboard risk management ! 19

  20. Preview of Tomorrow Work Breakdown Structure (WBS) See intro article athttp://en.wikipedia.org/wiki/Work_breakdo wn_structure. Goal is to partition the work into a low-level set of outcomes, then do tasks required to achieve those. 20

  21. For tomorrow Get together (starting now) with your teammates from your junior project, and: Create a Work Breakdown Structure (WBS) for your junior project, like on the last slide. Start with our Trello tasks These might need enhancement! Try to partition the work by outcomes. Then list key tasks for each outcome. Get to a low enough level, given what you know now about the project, that we can organize these into a plan, tomorrow in class. Estimate how long you think each will take. 21

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#