Why we hate changes (part 3)

< Previous: Why we hate changes (part 2)

What we saw in part 2 was two critical observations: The schedule did not relate to the estimate, nor did it relate to the scope at all. Instead we simply took the customer proposed schedule as granted and thereby blindfolded accepted the milestones without worrying if we can meet them.

The risk gambler

In fact we do not realize what risk we have just accepted. This is called unconsciousness incompetence (we are not aware of, what we do not know).

We simply accept that this is the terms of project life with the words:

“It is always like this, schedules are only a contract thing – not something we stick to on daily basis”

– well, it might even be that the latter is unknown to some project managers as well.

So we are committed to some milestones that the customer suggested. We have scoped the solution or just the requirements, we have estimated the effort or resources, but not managed to tie this to the schedule.

Why is that a problem? First of all you don’t know if the project is busy or not. How can you staff your project if you cannot relate the scope and estimate to the schedule? How can you report progress and how to determine if a milestone is met or not? What will your burn rate be on monthly basis? How can you know if you are overspending or just moving fast forward? You don’t.

Why employees register time?

Let’s face it: You put a lot of effort into estimating, asking your employees to judge best or worst case scenarios – or more typical just making undocumented guesses about how much a requirement cost to implement.

What do you tell your employees if they ask the logical question:
Why shall I register time spent on this project?
– “Because, that’s company policy!”

Next thing to setup is the time sheet. I really doesn’t matter what accounting system or tool you are using if you don’t pay attention to the structure. Most places I have been, the project managers ask controllers to create an account for usage tracking. The default template often looks like this:

• Analyze
• Design
• Develop
• Test
• Implement
• Project Management

If you do not care about structure, chances are that the structure you will get from your controller will not match how you structured your estimation.

Actually you already lost traceability in part 1, now it just became worse: Nobody can actually justify any time keeping!

Fig.1: We require all the employees to spent valuable time tracking hours spent in a useless structure that will not benefit our reporting at all. We cannot tell anything about project progress based on these registrations, only how much people worked during the day. Guess what, they probably worked full time anyway!

Trouble are building up

So we got lots of registration on hours spent on analyzing, designing, development, test, implementation and project management. But to what use?

• As you cannot relate these registrations to the estimate, you will not know if we use more or less than expected. For subcontractors we don’t know if their invoices reflect progress!
• As you cannot relate these registrations to the schedule, you don’t know where you are according to schedule.
• As you cannot relate the registrations to the scope, you will be in trouble very soon when changes occur.

Changes occurs – things gets out of hands!

What is change management in real? You might be misguided if you think it is only about managing changes to requirements. That is just the easiest part of the story – ignoring the hard part is why project managers hate changes!

Let us examine how changes are communicated. Even though the customer gave us 500+ requirements in the first place, they usually communicate changes in terms of new needs without worrying a bit about requirements.

“We have just merged with another company. Please change the administration module in order to show both inventories in one table”. When you examine that it contradicts previous requirements you must to adjust those – simply because you have to verify that requirements are met to the customer at project acceptance.

You can do that. It’s just hard work analyzing requirements, re-write and book the changes. Now comes the hard part when the customer naturally asks: “How expensive is this change?

How does the change impact the schedule?”

This is where the things get out of hand, when you respond: “We will be busy, but we can probably manage it. The cost … hmm, well… ehm, ekstra 15%”.

From now on things moves from bad to worse, when the customer asks: “Will you manage to keep schedule and cost neutral if remove requirement #41 and #84?” – No clue at all?

This is where your communication and promises starts to get you in trouble.

If you are optimistic and respond: “We will manage”, an intelligent customer might continue the pressure: “Oh, so if we don’t make the change, removes the two requirements, you will be finished earlier – how much?”

The sum of troubles

Changes are formulated as change of needs. Your scope is built around requirements, which only are a bad interpretation of needs.

Your estimation has no link to the scope, which makes it impossible for you to determine the impact of the change to the estimate. You don’t know the extra cost or cost saved by implementing the change.

You sail a about with a faulty map, with no idea of the fuel level or the distance to go. Furthermore you have no idea of time spent with the engine on

Your scheduling has no link to the estimate or scope, so you are unable to determine if the change will have impact on your schedule.

As your usage tracking has no link to the estimate, scope or schedule, you cannot say anything about progress so far; hence, even if you knew when to deliver parts of the scope, you have no clue about where you are according to plan.

To sum it up:

You sail a about with a faulty map, with no idea of the fuel level or the distance to go. Furthermore you have no idea of time spent with the engine on, and now your mother calls to know if you could make detour and have tea at five o’clock at her place.

Whatever you say, you’re lying or worse: unconsciousness incompetent!

> Next: How to love changes - 1