Managers Manage Ambiguity

I was thinking about the Glen Alleman’s post, All Things Project Are Probabilistic. In it, he says,

Management is Prediction

as a inference from Deming. When I read this quote,

If you can’t describe what you are doing as a process, you don’t know what you’re doing. –Deming

I infer from Deming that managers must manage ambiguity.

Here’s where Glen and I agree. Well, I think we agree. I hope I am not putting words into Glen’s mouth. I am sure he will correct me if I am.

Managers make decisions based on uncertain data. Some of that data is predictive data.

For example, I suggest that people provide, where necessary, order-of-magnitude estimates of projects and programs. Sometimes you need those estimates. Sometimes you don’t. (Yes, I have worked on programs where we didn’t need to estimate. We needed to execute and show progress.)

Now, here’s where I suspect Glen and I disagree:

  1. Asking people for detailed estimates at the beginning of a project and expecting those estimates to be true for the entire project. First, the estimates are guesses. Second, software is about learning, If you work in an agile way, you want to incorporate learning and change into the project or program. I have some posts about estimation in this blog queue where I discuss this.
  2. Using estimation for the project portfolio. I see no point in using estimates instead of value for the project portfolio, especially if you use agile approaches to your projects. If we finish features, we can end the project at any time. We can release it. This makes software different than any other type of project. Why not exploit that difference? Value makes much more sense. You can incorporate cost of delay into value.
  3. If you use your estimate as a target, you have some predictable outcomes unless you get lucky: you will shortchange the feature by decreasing scope, incur technical debt, or increase the defects. Or all three.

What works for projects is honest status reporting, which traffic lights don’t provide. Demos provide that. Transparency about obstacles provides that. The ability to be honest about how to solve problems and work through issues provides that.

Much has changed since I last worked on a DOD project. I’m delighted to see that Glen writes that many government projects are taking more agile approaches. However, if we always work on innovative, new work, we cannot predict with perfect estimation what it will take at the beginning, or even through the project. We can better our estimates as we proceed.

We can have a process for our work. Regardless of our approach, as long as we don’t do code-and-fix, we do. (In Manage It! Your Guide to Modern, Pragmatic Project Management, I say to choose an approach based on your context, and to choose any lifecycle except for code-and-fix.)

We can refine our estimates, if management needs them. The question is this: why does management need them? For predicting future cost for a customer? Okay, that’s reasonable. Maybe on large programs, you do an estimate every quarter for the next quarter, based on what you completed, as in released, and what’s on the roadmap. You already know what you have done. You know what your challenges were. You can do better estimates. I would even do an EQF for the entire project/program. Nobody has an open spigot of money.

But, in my experience, the agile project or program will end before you expect it to. (See the comments on Capacity Planning and the Project Portfolio.) But, the project will only end early if you evaluate features based on value and if you collaborate with your customer. The customer will say, “I have enough now. I don’t need more.” It might occur before the last expected quarter. It might occur before the last expected half-year.

That’s the real ambiguity that managers need to manage. Our estimates will not be correct. Technical leaders, project managers and product owners need to manage risks and value so the project stays on track. Managers need to ask the question: What if the project or program ends early?

Ambiguity, anyone?

4 Comments

  1. Speaking strictly for myself: estimates are instantaneous values, even if they persist in the minds of some managers. One of the things I like about the Prince2 approach to managing projects is that, at each phase, the business case is re-evaluated. We know far more, part way into the project, than we knew before we started. Therefore, we should update our estimates, our risk assessment, and our business case. If there’s no longer a reason to continue, cancel the project and let the prospective Death Marchers go on to other work.

    Estimates are used by well-managed organizations for decision support. If you work for a poorly managed, Dilbertian organization that uses them in lieu of rebar, then I suggest the problem is not estimates. Every other type of worker in modern civilization, from airline pilots to waitresses, sees the value to the customer in estimates. While I certainly agree that software development is different from food service and trucking people through the skies, these days the customers are the same. Would you fly an airline that refused to publish a schedule? Would you eat in a restaurant that had a policy against telling you when your pizza would get to your table? Me, neither.

    Reply
    • Dave, you are correct. The estimate is not the problem, it’s what people do with them. The nice thing about estimates for flights and pizza is that there is no learning involved. Well, we hope not for airlines! As I like to say, when people ask me how my flight was, “Uneventful.”

      But that’s not the same with software. In order to create a valuable estimate, we need to create very small features. Only then can we create useful estimates. Those estimates, of very small features are useful. I even like your idea of “instantaneous values.” Very nice idea.

      But what value is anything other than a gross estimate for a project? The Prince2 approach makes sense if you have gates. Each gate reduces your ambiguity. You replan at each gate, right? You know much more about the next phase. Makes total sense to me. If you don’t know more, or if what you know doesn’t make more sense, don’t keep going.

      When you use estimates, and only estimates as a way to manage ambiguity, you set yourself up for failure. Why not use demos? Why not use running, tested features? We have access to them.

      I am not saying we can do away with estimates all together. I don’t live in that world, although I wish I did sometimes. But I do see teams estimate, estimate, and estimate again, as if the estimate was the proof that they understood what was going to happen. An estimate is a prediction. Why not use reality? Especially if you are using agile?

      I see agile teams finish faster than the estimate said that they would all the time. And, I see not-quite-agile teams struggle to meet their estimates-as-targets, because of the political pressure. They have death marches. That’s because the not-quite-agile teams estimated once, and got held to an estimate as target. Crazy, eh?

      Reply
  2. I don’t consider schedules to have the same characteristics as estimates. Estimates are tightly coupled to the nature of knowledge and it’s constrains both in our epistemological understanding of it and our psychological influences on it’s creation: https://vimeo.com/7471593

    Reply
    • Anthony, thanks for the link to Linda’s talk. I’d forgotten about that talk, and I was there!

      If you know about the work, you can create a schedule that makes sense, especially in the short term. If you then create a rolling wave schedule, you can provide yourself (and your team and your management) good insight and good risk management for the project. You’re updating the schedule, accounting for the problems with the estimates as you proceed.

      Thanks for your comment. I’m not sure I would have made quite this connection without your comment.

      For those of you want to read about rolling wave planning or rolling wave scheduling, here’s a search for you: http://www.jrothman.com/blog/mpd/?s=rolling+wave. I’ve written a lot about it. Over on my main site, there are a number of articles. You can start here: http://www.jrothman.com/2005/01/starting-with-rolling-wave-planning/

      Reply

Trackbacks/Pingbacks

  1. Managers Manage Ambiguity | - […] Reblogged from:¬†http://www.jrothman.com/blog/mpd/2014/08/managers-manage-ambiguity.html […]

Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>