Framing the Question

“I need this project done by date D and within cost budget C. Now calculate an estimate on the project.”

A friend of mine used this example to illustrate anchoring bias in estimation. Note, however, that he doesn’t make the question explicit. Further conversation revealed that he had in mind that the date and cost should be the output of the estimation. With that assumption, that statement preceding the request will definitely anchor the answer, and realizing that this bias is likely will call into question whatever estimate is given.

Given the stated need, however, I would reframe the call for an estimate from “When will this project be done and how much will it cost” to “What is the likelihood that the project can be done within these constraints?” (Continued)

Changing Behavior by Asking the Right Questions

My article, Agile Adoption: Changing Behavior by Asking the Right Questions, has been published over on ProjectManagement.com (free registration required). It talks about when managers want change, but don’t want to squeeze the Agile out by force.

Accomplishing Organizational Transformation

Scaling Agile across the Enterprise attracts a lot of attention these days. There are a number of models suggesting ways to organize Agile development inside a sizable organization with a lot of teams. I suspect that all of these models share the same basic flaw—that you can do something the same way across a large enterprise. Even if your policy manual says exactly how to do something, people are people and there will be variations in understanding and execution. And how does a team self-organize in a prescribed manner?

Beyond that, there’s the problem of getting from current state to a future state that resembles the model. It does not work to “install” a new way of working across a large system composed of people and their interactions. Some people suggest starting the transformation with management, as that’s the “highest leverage point” and the “system’s major influencers.” Others suggest starting with the teams, because without competence at building reliable software (or other systems) in short cycles of small steps, you’re not going to get the benefits of Agile Software Development. I don’t think that either of these starting points work.

“When we try to pick out anything by itself, we find it hitched to everything else in the Universe” — John Muir (Continued)

Agile: What’s in it for the Project Manager?

Over on projectmanagement.com, my article “Agile: What’s in it for the Project Manager?” has been posted in two installments: part 1 on gathering requirements and work breakdown, and part 2 on interpreting requirements and tracking progress. Projectmanagement.com requires free registration to access the full content.

Building Frameworks For Internal Use

Suppose you have a number of products, or a number of applications, that share some common functional needs. It seems obviously reasonable to create a separate team to build those functions in common. Often these grow to become known as a framework, and the product or application teams are expected to use it.

It’s a seductive concept, but don’t do it. Why not? I can think of several reasons. (Continued)

Project Communication: Caught in the Middle

My article, “Project Communication: Caught in the Middle” has been published on projectmanagement.com now. It talks about the communication issues for a project manager in charge of an Agile project, and ways to manage both downwards and upwards.

(Free registration required)

Coherence vs. Standardization

I’ve talked about the rush to standardization before. My article, Coherence vs. Standardization, published yesterday on projectmanagement.com, offers a more detailed look at the problem, and offers an alternative.

[Note: projectmanager.com requires registration, which is free.]

Unintended Demotivation

Are your well-intentioned actions having consequences you don’t intend and don’t want? Read “Unintended Demotivation,” my latest article on Gantthead (free registration required).

Also, I don’t think I ever announced my previous article on Gantthead, “Better Success Across Large Projects.”

Agile Planning Tools

One of the most exhilarating moments in my coaching career was when I entered the client team room one Monday morning to find they were pulling the cards and tape off of their backlog corkboard, and arranging it in a different fashion. I knew then that they had taken charge of their own process. That team became one of the best I’ve coached.

One of the low points was when several people, including a business analyst, product owner proxy, and the program manager, individually said that they couldn’t alter the “user stories” to cut across multiple components of the system because they were already in the computerized planning tool (and Word documents) and it would be too much work. That team did not appear to be getting much value from their “Agile approach” and had significant integration risk that was being studiously ignored.

One of the most frequently asked questions on public mailing lists and forums devoted to Agile development is “What Agile Planning Tool should we use?” There is always a chorus of answers touting this or that computerized tool, usually without asking any questions about the context. Is there one best tool? (Continued)

Errors in Project Management

An article in USA Today (December 12, 2012) about highway projects in New York has the sub-head, “Design errors, planning lapses drove up costs more than 14%.” Among the things listed that “drove up costs” are

  • More asphalt than projected due to a math error
  • More temporary concrete dividers than planned, as plans called for only half what was needed
  • Unanticipated excavation costs.

It’s true that no one likes for costs to exceed estimates, (Continued)