Can the Team promise a date?

I think this is an important question.

To promise? Umm.  What does a promise mean?  Can Joe Namath promise a Super Bowl victory?

One song lyric is: “Promises, promises, I’m all through with promises, promises now.”  Many a song about broken promises.  One of my favorites is the Eric Clapton upbeat blues song: “Promises”.   Check it out.

But, we all (at work) are not lovers, and we understand that the future is hard to predict.  So, if a promise is broken, we’re not going to be broken-hearted, we’re not going to hate our former “lover” (the situation in Clapton’s song).

Still, when a Team makes a promise, commitment, forecast, projection…we certainly want it to be meaningful, to be realistic, to happen.  Or to be a pretty close guess, and what does happen is pretty close.  And, if all hell breaks loose (as some of us say), then we understand that all bets are off, and the date will have to change (or the scope).

We all in business are usually fairly realistic.  Or at least realize that we should be.  Spock: It’s only logical.

(Namath said ‘guarantee’… and, oddly, his Jets team did actually win it.)

Why

Why is making a prediction (eg, of some range of scope, date and budget for Product X) important or useful?

Simple: Almost all customers need to make plans themselves for when they will get the new product.  And it is ok for them if things change some (not always exactly happy, but they can accept and live with some degree of change).  The “prediction” enables them to act, usually pretty usefully.  And maybe a risk assessment (or probabilities) on the prediction is also useful.  For example, in financial markets, customers might buy options to mitigate their risk.

***

Example

Let’s say you have a fairly big project, that maybe requires 3 releases that would happen every 3 months.  So, overall, a 9 month product before it is ‘fully’ built.  (IMO, in general a product is never fully built; the customer always wants more.)

So, that 9 month plan is what I think of as a normal situation. Difficult at best, but normal.

To make it easier to describe, let’s imagine we are at January 1, and the releases need to be March 31, June 30 and September 30.

In this situation, can the Team promise on Day 0 (Jan 1) that the releases will happen on exactly those dates?

Well, maybe they can, usefully.  In other words, they can say “We expect to release on those dates, and we can give some rough ideas today what the functionality will include, but it will change some. Perhaps even a lot.”  I think they can usually or often say that, meaningfully and usefully.  And further say, “well, if the amount of change is normal, we think we have added a reasonable contingency for that, and the product is likely to be pretty close to what we expect.  But, if the amount of change (in many dimensions) turns out to be smaller or greater than normal, then at some point the product will be quite different, possibly so different that we would have an “unhappy” release (eg, we might recommend not releasing).

Change will happen

Will change happen?  100% certain.  That is about the only thing that is 100% certain.  (Ben Franklin said only death and taxes were certain, but Buddha said “Everything changes, nothing remains the same.”)

For certain, some bad change will happen.  Examples: We will be disrupted.  People will be ‘taken’ from us, in some form or another.  Important features will be discovered later.

Note: discovering important features later isn’t that bad IF we have sufficient contingency.  Why? For example, that discovery might lead to a notable and unhappy delay (compared to expectation.

But, if we have a weak mechanism for doing the customer trade-off between delay and the value of that newly discovered feature, then making the best adjustment can feel “hard” and maybe be time-consuming.  Etc, etc.  What is uncertain is how much ‘bad’ change will happen.  But, we will certainly have some bad change.

If we are professional, we will also have good change.  What is that?  Well, we will learn.  We will become smarter.  We will remove impediments and become more productive.  And, if we are generally professional, this good change is certain too. What is uncertain is how much good change we will have.

And the real uncertainty: will the bad change be more than or less than the good change?  And by how much?

***

Can we make a useful prediction of the release dates for every product?

This is a very hard question, since no one can even imagine ‘every’ product.  But it certainly sounds like the answer must be ‘no’, if you mean always and every time.

OTOH, we CAN make a useful prediction in lots of fairly normal cases.  At least, if we have some experience.

One can imagine situations of many unknowns, extreme change, etc, etc.  We can issue a prediction, but, at least for those ‘hard’ products, it will turn out to have been a poor prediction, perhaps even useless or worse.

So, yes, ‘useless’ predictions are possible, I think.  Still, the prediction DOES still give us an opportunity to learn for the future.  And, if handled right, may increase the motivation of the Team and the transparency for the effort, and help us learn faster as a Team.  Still, some nice benefits.

But, does the ‘fact’ (well, we posit it as a fact) that some predictions will be useless make all predictions useless?  I think not.

How accurate does a prediction need to be, to be useful?  Well, I find most business people do not need that much accuracy.  They well understand risk and uncertainty.  But they want some better information. Often they will say ‘can you get me better information than the competition has?’…. a very low standard usually, but when we say it that way, you see how they will use the information.  They just want to improve their odds.  The odds of success, and also the odds of not losing too much on a gamble.

***

Now, back to the Team’s point of view.

An estimate is not a guarantee (Joe Namath notwithstanding).  An estimate is an educated guess about the future.  And, as any adult should know, to predict is difficult, particularly of the future.  (That’s a variation on a quote originally in Latin. Cf Yogi Berra.)

Can managers misuse a prediction?  Most certainly.  And some people called managers have brutally punished the Team when their prediction was not accurate (enough).  This is not right.

Typically, managers should not even see the Day 0 prediction.  But, after some small number of sprints (given something like a 9-month situation), most Teams should be able to give a reasonable prediction.  It is never a guarantee because something weird could always happen. But it is usually a useful business prediction, that can enable useful business decisions.  Decisions by managers or decisions by customers.

If you are in the Team, when should the Team ‘issue’ these predictions?  Well, that is a very hard question, that requires lots of judgment.  It depends.

It depends on whom they are talking to. How much that person (that group) understands that things might change.  How much we have learned.  How much uncertainty this product has compared to others.  How close it is to the release date.

There are many factors.

But, as a coach, can we in fairness suggest that Apple never tell the customers anything?  Should we suggest that Apple actively deny any rumors about a future iPad?  And say, ‘we have no idea when the next iPad might be ready?’  (Today Apple is expected to announce a new iPad.)  Apple should never tell its suppliers when to expect to start building the new iPad.  Never tell its managers when the basic development of the iPad might be done? (So that the managers could talk to the supply chain.)  Clearly, in business, some predictions must be made.  It is just required by business, by customers.  If the company and ‘rumor’ does not make a prediction, then the people themselves will, and often a very wrong prediction (too early or too late).

And, of course, some understanding of the degree of uncertainty needs to be communicated, if the person can listen to it.  Sometimes we use a percentage. Sometimes we use a range.  Sometimes we use only non-denial of ‘rumors’.  Or just words (‘we think it will be announced in the Fall of 2014’).  But we urge you to help those you are working with (eg, help your customers) by giving them some sense of the degree of uncertainty.

The uncertainty can vary quite a bit, from one product to another, from one situation to another.

***

In summary:

1. Be careful making predictions.

2. Sometimes bad things can result from making predictions.  (Ex: Some teams have, to my horror, been forced into a Death March to make some ‘predicted’ date. Unbelievable that humans would do that, but it has happened and continues to happen, we think.)

3. Again, do not make predictions lightly.

4. You usually must make a prediction at some point.  People will require it; it is the nature of life.

5. Try to assure that the person or people understand the uncertainty in every prediction.

6. Try to establish that a new and better prediction will be made later (when you are smarter).

7. Accept that life has risk. ie, Make a prediction.

8. Learn to make useful and relatively accurate predictions.  The best way to learn that is to … practice.  By making real predictions, and seeing how life turns out.

9. Never pretend that a prediction is a guarantee.

 

« « Public Impediments – Charleston Oct 2014 || 9 Key Statements about Estimating » »