"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.
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 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!
No comments:
Post a Comment