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.