Why we hate changes (part 2)

< Previous: Why we hate changes (part 1)

Continuing from part 1, our project manager is now struggling in his attempt to make a schedule.This is important as the customer demanded a detail plan for the entire project.

Fortunately, the customer has “proposed” a handful of milestones, which are expected to be met together with the other implicit expectations: keep the budget and make an error-free solution.

In order to get the schedule done, the project manager base the work on the customer required phase for development, system test, acceptance test and operational test. It is natural to do so, as it pleases the customer and is quickly done.

Fig. 1: More than often, schedules are indiscriminately based on a waterfall approach with no traceability to scope or estimate. Because of that, the milestones given are often no S.M.A.R.T defined and it is hard to tell when the milestone was reached.

This is accepted by the customer, although he of course would like a very detailed Microsoft Project plan as well specifying all activities by all name resources reaching into the next year.

Now, you're absolutely lost when the customer begins to change the scope as you have no traceability to requirements or deliverables in your schedule. Even worse, you have no traceability back to your estimate or scope model as we saw in the previous part 1 (also see below).

You’re absolutely lost when the customer begins to change the scope!

For obvious reasons this level of detail does not makes sense as plan changes and resources are replaced during the project.

For now, let us focus on scheduling related to the work our project manager did previously. He made the cost estimate and some sort of scope definition, which really just are the customer requirements. We saw that there is no traceability between requirements and cost, which makes it difficult to manage changes.

Lost control

Looking at the schedule we see no link to the estimates, or to the requirements.

Fig. 2: There is no traceability between requirements and cost, nor can you accumulate the cost two estimates. You cannot relate schedule to requirements or to cost. How can you determine if a change have any effect on schedule? You did not even know the cost or schedule position of the origial requirement!

How is schedule associated to estimated work?

How does the project manager know if the schedule is realistic? Is it possible to explain how the schedule was constructed at all? If it is difficult to link the schedule to the estimate or scope, it is difficult for the customer too.

Do we know if we are busy in this project or have plenty of time – well, we probably assume we are busy, because we always are.

Let’s assume that the steering group ask for project progress reporting, what to do then? At this point we even can’t draw a traditional S-curve, because cost estimation and schedule is not tied to each other.

The truth is often: “I don’t have a clue”,
but that is not legitimate to say to a customer”

When the customer asks for a change, he also asks for the project managers view on consequences: “I like to request a feature that enables me to edit two at the same time.

This is probably very expensive, so I remove requirement #A-02. What is the extra cost? Can you still meet the milestone?”

What should the Project manager answer that?

Well, answering the truth: “I don’t have a clue” will often be a no-go, so now he starts dreaming (or lying) with a postulate, that he cost is more less the same and we probably will have to postpone the milestone a week (why not earn an extra week; we are probably busy).

Is this an exaggerated and too caricatured situation?

Take a hard look at projects in your organization and do this simple check: Are there traceability from requirements to the estimate, from the requirements to the schedule and from the schedule to the schedule?

More often than you would think an obviously structured approach to planning is absent.

The magician

When the customer asks for a change, he also asks for the project managers view on consequences:

“I like to request a feature that enables me to edit two at the same time. This is probably very expensive, so I remove requirement #A-02. What is the extra cost? Can you still meet the milestone?”

What should the Project manager answer that?

Well, answering the truth: “I don’t have a clue” will often be a no-go, so now he starts dreaming (or lying) with a postulate, that the cost is more less the same and we probably will have to postpone the milestone a week (why not earn an extra week; we are probably busy).

It is actually even worse in situations where the project manager believes in magic. When he thinks that some miracle will happen - a "ketchup effect": e.g.:

"When the initial framework is finished all developers will be much more effective; hence, the remaining work might be completed way below estimate!" - guess what? Not gonna happen.

Is this an exaggerated and too caricatured situation?

Take a hard look at projects in your organization and do this simple check: Can you find traceability from requirements to the estimate, from the requirements to the schedule and from the estimates to the schedule?

More often than you would think an obviously structured approach to planning is absent.

Next: Why we hate changes (part 3)