Get Out Of The Rut Of Solutions That Don’t Work!
Your project management tools and solutions should fix the problem you are trying to fix. Too many solutions are just patches on the system and come from being an expert in applying patches rather than solving the underlying problem. You can get out of this rut, if you recognize it and are willing to make some tough choices.
The phone rang. I could see that it was a toll free number. Probably a political call or some sales offer I figured. I picked up the phone and said “this is Bruce Benson.” There was a slight pause, then a voice: “We are truly sorry, a representative will be right with you.” I was called and automatically put on hold!
Someone figured this was a good solution. If the automatic dialing got a person before a representative was ready, just tell the person – the potential customer – that they are put on hold. I bet it was considered a technical achievement to put this apology in when the customer answered before the representative could pick up the phone. At no time did the caller robot tell me who was calling or why. Instead, the robot apologized profusely and repeatedly as only a robot caller can do.
What was the problem? The dialer got ahead of the available salesperson (I assume this was a sales call, but I didn’t wait beyond hearing 1.5 apologies). The solution? Make an anonymous apology. Did it keep me on the phone? No. At best they could have used that time to start their sales pitch. That didn’t happen either.
Sometimes we simply pick the wrong solution. Often in these cases we may become experts in the wrong solution. I recall the story of Lee Iaccoca trying to produce the first convertible car any US manufacturer had made in years. His managers and engineers laid out how long it would take to design and manufacture this new car. Reportedly, after listening long enough, Iaccoca’s patience ran out. He told them to just take an existing car and cut the top off!
Setting aside if this produced a quality automobile or not, it highlights how we get stuck in a rut and can’t see another way out. We are very good at working in a rut, even if the rut always results in something that does not work as well as we want. Just like the robot call I got.
When we see we are keep getting the same results, not the results we want, this is a wake up call to try and do something different. In general “something different” should probably scare the wits out of you and possibly your team. If it is not scary, if it does not make you wonder if you are going to keep your job, then it may not be different enough.
I was relatively deep in debt as a young man. I could not pay off my credit cards each month. I had a continuing balance that often went up as fast as it ever went down even as I made payments. I understood the details of the minimum payment, the calculation of interest, the deadlines for payment, and the daily average calculation used for interest computations. I would play a game where I would send in a payment that would result in an exact outstanding balance such as $12,345.67. I knew the algorithms so well that I could produce digits in any order in the resulting balance for next month. I was an expert. But I was an expert at the wrong thing. I was an expert at what the credit card companies wanted me to know, but not in what I needed to know to get out of debt.
Luckily I realized soon enough that if I could afford to pay interest on a credit card then I could afford to pay cash instead of using a credit card. This was one advantage to becoming an expert in the wrong thing. That expertise made me realize the futility of what I was doing. I chopped up my credit cards and learned, really fast, to pay attention to how much cash I had, when I got paid next, what bills I had to pay and how much I needed and when I needed it each month. I became an expert on my needs and income. This was much more useful than knowing credit card agreements inside and out. I never went into consumer debt again (excluding automobiles and houses, all of which I paid off in about a third of the time allotted – for more on this story and on financial management in general see Quicken is a Great Project Management Tool).
I kicked myself out of my comfort zone, my rut, by making a hard change. This is also similar to the notion in The Toyota Way where one gets rid of buffers so that the problems the buffers are meant to cover are exposed (see Project Management Tools Honesty Buffers). This way the underlying problem must be fixed and can’t be avoided. In both these examples the key event was yanking away the safe approach (which while safe, may still be challenging and difficult to do) and exposing the real problems that needed to be dealt with.
In the case of the robot caller, the real problem was to figure out a way for a representative to be on the call as soon as a person answered the phone. Putting in the automatic apology just delayed dealing with the real problem, at least for the moment. It certainly didn’t encourage me to stay on the phone.
Good solutions often require you or your team to be pulled out of your comfort zone. Too many solutions, even while innovative and unique, can simply be the wrong solution and just become another temporary patch on the system. If your past track record of solutions just don’t seem to be making enough of a difference, consider those approaches that put you and your team well outside your comfort zones. These are often the real solutions you are looking for.
Filed Under Change Management | 2 Comments
You Really Can Know If Your Project Estimates Are Accurate
The bottom line is that you can know if your project management tool estimating is accurate. More to the point, estimating in a project can be verifiably accurate.
I recently read the following comment in a conversation about estimating projects:
One nit. We as a community have got to stop using the phrase “mis-estimate”, “incorrect estimate”, and “wrong estimate”.
es-ti-mate: To calculate *approximately* (the amount, extent, magnitude, position, or value of something).
An estimate that’s not “accurate” is still a valid estimate. An estimate can not have errors. That’s why it’s called an estimate.
Too often, I’ve seen estimating handled in this way. The notion is that since it is only an estimate, it doesn’t actually have to be accurate and be without errors.
OK, so what then is the purpose of an estimate? If you estimate it will take one month to do a task, and it takes three, is that OK?
I don’t think so.
How do we get accurate estimates? I regularly recommend using past historical performance for getting good estimates on how to do a current project. This works well because in most environments, the People + Processes + Tools do not change significantly from project to project. This results in a regular consistency in performance (see: Get The Project Management Tool Schedule Right).
How can you tell how well we estimate? This is at the crux of the comment above. Here, the writer didn’t seem to express any belief that an estimate can be accurate in any verifiable way.
So, how do we check how well we are estimating? Measure it.
Let’s say the last five times we did something it took the following number of weeks: 18, 17,16,19,18 (we have to keep track of how long things are taking to be able to do this).
Looking at our old plans, we see that we estimated the following for the same tasks: 15, 14, 16, 13, 15 (again, we have to keep records to know these values).
| Estimate | Actual | Comment | |
|---|---|---|---|
| 15 | 18 | Late | |
| 14 | 17 | Late | |
| 16 | 16 | On-time | |
| 13 | 19 | Late | |
| 15 | 18 | Late | |
| Avg | 14.6 | 17.6 | 3.0 weeks late on average |
| Dev | 1.1 | 1.1 | 1.1 weeks standard deviation from the average |
What we can see in this data, is something I typically see in organizations that struggle to deliver projects and products on time. There is usually a fairly clear and distinct difference between what is being estimated and what generally happens. Just getting this kind of data into a summary slide helps many folks finally see, or admit to, the pattern. Too many believe that the estimates are just fine and we would deliver projects on time if folks just didn’t make so many mistakes!
However, just having estimates being different from the actuals is not an indication alone that the estimating is not accurate.
Suppose I come in as a, hopefully, overpaid consultant and work with the team to improve the accuracy of their estimating. I propose they use the average of the actuals as an estimate and maybe, just maybe, tweak it one way or another a bit if they feel there is something especially significant in this project.
With the next few projects, we get the following results:
| Estimate | Actual | Comment | |
|---|---|---|---|
| 17 | 18 | Late | |
| 19 | 17 | Early | |
| 16 | 16 | On-time | |
| 17 | 19 | Late | |
| 18 | 18 | On-time | |
| Avg | 17.4 | 17.6 | 0.2 weeks late on average |
| Dev | 1.1 | 1.1 | 1.1 weeks standard deviation from the average |
As we can see, some of the projects were late, but more were early or on-time. This is also typical of what happens when we improve the estimating. Estimating isn’t suddenly perfect but clearly we seem to be doing better.
A good indicator is to look at the averages of both the estimates and actuals. In the first example, there is clearly a noticeable and consistent difference averaging three weeks late. In the second example (I purposely made the actuals the same so it is easier to compare), we appear to be doing better at estimating, and consequently delivering on time, with an average of just 0.2 weeks late on average.
You may note that in improving the accuracy of the estimate, the estimate “grew” to become closer to the actuals. This is almost always the case. Too many organizations want to improve their estimations by getting the “actuals” to get closer to the estimates. There is nothing wrong with trying to speed up our processes. However, fixing schedule performance by trying to get real processes to match up with flawed estimates is not the best process improvement approach. Instead, get an accurate estimate then improve your process and watch the estimate – and the actuals – improve with time.
Some managers would not like hearing that our overall average is now “only” 0.2 weeks late. This is another dynamic I often see. Once we start to improve accuracy, anything that is not perfect must be a huge problem. I’ve seen great improvements in estimating and on-time delivery all but discarded because estimates were not perfect and could still results in missed dates. This is where I get back to reminding folks that an estimate is not perfect. This is where the writer above and I do substantially agree.
I’ve used three fundamental ways to solve this “problem” of imperfect estimates:
1. Focus on improving the speed and quality of the process, to bring down the time and variability and reduce the chances of missing a date.
2. Add one or two deviations (e.g., 1.1 weeks from the above example) to the average in making the estimate. This accounts for more of the typical variations seen in the past.
3. Observe that when given the average to work with, teams will often make improvements that allow them to complete a task faster than the average assumed. Just about every team we’ve given the “average” amount of time to not only delivered on time, but did so with a remarkable increase in productivity and quality.
Estimating might well be one of the most critical activities any manager will do on a project. Measuring the difference between your estimates and how you actually do, will allow you to know how well you are estimating. You know your project management tool estimating is working fairly well when the average time to complete a task or deliver a product matches closely the average estimate you made for those projects.
Filed Under Schedule | 4 Comments
keep looking »