Why we hate changes (part 2)

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 bases the work on the customer suggested phases 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: Customers usually requires a standard top-level schedule to be followed and outlines milestones that are tied up to the contract payment plan. Who knows if that plan is suitable and if the milestones are realistic? No wonder that most projects are busy from day one!


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

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

For obvious reasons this level of detail does not makes sense as plans change 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. 1: 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 to 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 the 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 always 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 estimate to the schedule?

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

Stay tuned for part 3. It gets even worse!

Why we hate changes (part 1)

The main reason why project manager hates changes and project administration is lack of structure. If you do not implement a well-defined structure, you are navigating in chaos.

Recently I reviewed a Project Plan that turned out to be a textbook example of how not to start a project.

I you ever wonder why project managers hates making status or re-schedule, the reason behind is more than likely due to lack of structure.

You simply cannot answer the question: What are the consequences if we remove some requirements?

Requirements

Of course the project has a list of requirements to meet. These requirements are the customer’s attempt to describe their needs. Now, 
our project manager takes it for granted that these requirements are all he needs to deliver. 

That is bad for two reasons: A) they are incomplete and B) we do not make requirements; we live up to them (we think). But right now, let us focus on structure:

The requirements were structured by the customer, e.g. like this:
A-01: Validation of zip code syntax
A-02: Dertermine if customer exists
A-03: Cross-browse compliance
…etcetera..

Cost estimation

Looking at estimation, I saw a very common approach. The project manager had calculated the cost as resources needed, like this:

4 Developers in 1,500 hours
2 Architects in 500 hours
1 Test Manager in 200 hours
2 Testers in 400 hours

A subcontractor, that had to deliver part of the solution, calculated their part like this:

Analyze phase: 300 hours
Design phase: 600 hours
Development: 2,200 hours
Test: 900 hours
Project Management: 500 hours

Fig. 1: There is no traceability between requirements and cost, nor can you accumulate the two cost estimates. It's like mixing apples and oranges and the only common determinator is the grand total.

Oh my… part 1

This is bad. The two calculations are incompatible and the only way we can accumulate our budget is on total hours. 

Actually it is really bad, because we cannot determine how much each of the requirements cost; hence, change management is difficult if not impossible.

If the customer asks us to remove requirement A-02 and reduce the price accordingly, we will be reluctant to do so, because we really do not know the impact.

A final word: The requirements are sort irelevant when calculating the estimate, as we deliver a solution that meet the requirements. Obviously, the project manager must calculate the cost of the solution, not the requirements.

Could this be worse? You bet! Stay tuned for part 2.

The blindfolded project manager

One day in the Project Management Office (PMO) we heard ourselves saying this:“

One of the PMO tasks is to provide an overview of project status. But seeing how project managers act, I really don’t trust the data underneath, which makes all my reporting untrustworthy!
Even worse: I don’t even trust the projects to know their full scope; hence, their estimates, schedule and control are untrustworthy too. It seems we have a common challenge.”

Of course this is generalized a lot, but it had a grain of truth. Some project managers are unconsciously incompetent in their daily work.

The blindfolded project manager

Visualize yourself riding a bike blindfolded. What would that require? You’ll probably ask people around you constantly to report about cars, pedestrians crossing the road; distance to the curb, other bikers and the road’s course.

Now take away the blind and consider how many reports you could do without. You won’t have to get informed about the road’s curse, other bikers, pedestrians or cars and you’ll even not bother about the distance to the curb. You’ve that by intuition. You’re in total control without much effort.

I have met a lot of project managers, project owners and steering committee members, who demand reports and measurements about irrelevant things - sometimes without even knowing why the project was initiated in the first place.

This blog focuses on how a Project Management Office (PMO) can provide project managers tools to “see” instead of running blindfolded and constantly “acquiring reports from others”. It is also about providing better project information for the PMO and the financial department.

What is to see? What is control?

Project Management is about many things exciting to the project manager: Team development, pushing technology, understand customer needs, proper communication, handling politics and building something unique. But it is also being an accountant: Setting the right scope, estimate efforts, determine optimal flow and developing a sound schedule. Most important though, being able to adapt changes and control usage and progress.

What part is most interesting and what part is often boring?

Most people like the freedom and challenge in the first part. Less people are attracted to the accountant work, digging into economy, planning and control. Got it?

If project managers are able to plan and control their project properly they’ll gain confidence in their project to a level where they no longer need reports about everything. They easily see it for themselves.

In this blog I will write about our steps getting better to spot problems, be more predictable and mature so we can focus more on the fun part and make the boring part simple routine.