So you think youre doomedMatthew Heusser / Matt.Heusser@xndev.com / www.xndev.comPresented at The IQAA Conference / Indianapolis, IN - Oct 13th, 2006

So you think youre doomedSuccess Without Tears

The Road Ahead

The Denver Airport

Project Schedules

Chart1

0.990.950.90.850.8

0.95099004990.77378093750.590490.44370531250.32768

0.9043820750.59873693920.34867844010.19687440430.1073741824

0.81790693760.35848592240.12157665460.03875953110.011529215

0.66897175860.12851215660.01478088290.00150230120.0001329228

0.44752321380.01651537440.00021847450.00000225690.0000000177

0.36603234130.00592052920.00002656140.00000008750.0000000002

0.13397967490.00003505270.000000000700

99%

95%

90%

85%

80%

Number of Tasks

% Success

Project Failure Rate

Sheet1

Tasks% Success

99%95%90%85%80%

199%95%90%85%80%

595.10%77.38%59.05%44.37%32.77%

1090.44%59.87%34.87%19.69%10.74%

2081.791%35.849%12.158%3.876%1.153%

4066.9%12.9%1.48%0.15%0.01%

8044.8%1.7%0.0218%0.0002%0.000002%

10036.6%0.6%0.0027%0.0000%0.000000%

20013.4%0.004%0.000000%0.000000%0.000000%

Sheet2

Sheet3

Test Estimation

Requirements

If we sold groceries

No more tears

Recommended Reading

I have to apologize for this abstract. I wrote it 6 months ago, based on a paper I wrote a year ago, based on research I did two years ago.

Right now, I see a lot of projects that arent doomed In fact, they are achievable. Maybe you work a little overtime, a couple of weekends, maybe the software is a little late or a bit incomplete, but it is possible to have some measure of success. So 90% of the audience simply cant connect with the topic.

Worse, the talk is kind of a downer. Its negative. Sure, I could give it here Ive got it on CD if anybody wants it but Its not really what I am interested in talking about today.

What am I interested in talking about?These are my children. They are the reason that I do this stuff.

The irony of the achievable project is that it is possible if I am willing to give up nights and weekends to work.

So, I can succeed at work, if I am willing to give up the reason that I am doing all this my treasure.

Instead of talking about doomed projects, Id like to talk about something else how we can take achievable projects and change them, so we arent forced to trade off our treasure for success.

(Tell story of Katie crying at the top of the stairs)

So heres the talk how to succeed and go home at a reasonable timeA Case Study: The DIA Project SchedulingTest estimationOn Requirements

Conclusions (No More Tears)

The DIA airport failure wasnt a failure of software engineering it was a lack of risk management.

Risk Management Strategy #1: Have a backup plan.(This strategy addresses mission/operational risk)Explain Critical Chain Project Management

Risk Management Strategy #2: Buffer the project, not the tasks. Have a difference between the goal date and the commit date.

(This strategy addresses schedule risk)

Other fields learning from my friendly income advisor

2) You might know how long it will take to do a testing cycle but how many cycles do you need?

What is the standard for release?What is the standard for code complete?How accurate are the development estimates?

------ If you do similar projects with similar teams, over and over again, test estimation gets pretty easy. Otherwise, all you can do is best effort, better or worse (instead of right or wrong) and communicate in terms of risk.

Of course, that assumes that the date is up to you. If it isnt, well, tell mgt the risks of going live on that date, and let them decide. They will have to pay the price if the project is rejected by the marketplace or end-customer; they must balance the pain of shipping early with the pain of shipping late.

Risk management strategy #3 addresses the expectations gap, and it is this:

Make sure that you can do what is expected. In testing, if you are the quality police or the quality saviors, consider changing that to quality advisor

Three false ideas that really bug me about requirements:

1) Requirements are what is required. We need to be developed first, then we do estimation.

This is just silly. No one ever spent a month designing a gothic castle on the san Francisco bay with 100 acres of land with a budget of $100,000, then saw an architect. It just doesnt happen. And software is so intangible that we have no idea how much things would cost without having a technical person in the room. Requirements need to be developed by a team, iteratively, with some idea of the price of each feature, so the customer can set priorities.

This brings me to my second complaint

2) Requirements are documents that are written and must be handed off.

(People dont know how to write)(Have you ever tried to argue with a document?)

Which leads to

3) Requirements arent gathered they evolve.

We we act like we dont know this, we have two possibilities:A) The project freezes the requirements on a two year project. In that case, at best, the team delvers not what the customer needs, but what the customer thought they needed two years ago.B) The customer is allowed to change the requirements mid-stream without changing the date. Which is means overtime and burnout at best.

The solution is to break the project into a series of mini-projects each a phase have the customer work with the project team deliver working software periodically, and allow the customer to adjust after each phase.

Its a lot easier to tell where you are and how to adjust on a one-month project than a one-year project. Also, when the customer changes his mind, he has a conscious knowledge of what he is doing; he sees the features that he chooses not to fund fall to the floor. Eventually, the customer may say things like You see feature #11 from the first meeting? Its been four phases and weve never done that. Its too expensive, and now that we have features 16, 21, and 23, we dont even need it. Lets stop talking about it can we take it off the list?

At the point, youve won.

Risk Management Strategy #4 Evolve Requirements through phasesIf the customer said 60 dollars? 60 dollars? I dont know about that

The grocer would say Well, sir, you can take some things out of the bag, pay the full price or shop somewhere else.

In Software Development, we say, Well, if we work really hard, maybe we can give it to you for forty.

Now, imagine that the customer goes through the line, is ready to checkout, and asks for two candy bars. The grocer replies what? Of course you can have it and its going to cost you.

Not No Requirements freeze. Thats no good.Not Yes Ill eat the cost myself and just work some overtime.

Yes, and Itll cost you. If you want to pay less, youll have to take something out of the bag or shop elsewhere.

Again, in development, we say No, or, more often Yes

What does it lead the customer to think of us? That we are padding our estimates, or that they have to Motivate us (in the Darth Vader Sense)

What will this encourage the customer to do on the next project? Negotiate schedule. We think the project will take ten months, they negotiate us down to six, it ends up taking nine and a half and we are late.

SHAME ON US. This isnt a problem with the customer; its our problem. We fail to set clear boundaries.

To protect yourself from personal abuse, set clear boundaries and be aware of them.

Thats hard it can be painful the first time. Then again, think about the alternatives.Alternatives protect against operational riskCritical Chair protects against schedule riskTesters as advisors protects against expectation gapsEvolutionary requirements protect against requirements riskSetting clear boundaries protect us from ourselves

--- Of course, giving this talk is a lot easier than going out and doing it. Many of you know my goal in one of these talks to have a little fun and teach something practical. This time, Im going for something more the hope that on a future project, at least one person will not have to choose between having a happy project and a happy life.

If Ive done that, well, I hope you can agree, that is real success.Anything by Weinberg++