As the time goes by – Managing versions

Eugenio — Fri, 14 Aug 2009 16:04:24 +0000

Nice attempt to hide the guest

In our projects, time comes in two versions:

“Fixed” in terms of delivery dates.
“Flowing” like a cursor moving with a uniform velocity on the calendar (toward the milestones).

These truisms are needed for introducing the concept of versioning.

Managing initial drafts

Until all “Acceptance Criteria” (to be intended as a general concept, not yet finalized in the Prince2 document) have been collected and approved. The documents (e.g. plans) are drafted for a shorter scope.

However essential for building the final results, these documents shall be clearly marked “Draft” and carefully doled out. This is done for avoiding stakeholders’ false expectations.

Once, the final draft has received the “imprimatur” from Sponsors, it shall be considered as a “living” document. From its changes, duly and correctly recorded, it is possible to manage the project.

Plans with short lives

Some Project managers haste to issue the “final” version, the one that shall freeze the time until the milestone will not be reached.

Risks, duly cataloged, are tamed in their boxes.
Senior Managers are assured that the neatly figures and lines will form an insurmountable barrier against every delay or extra costs.
Stakeholders have been completely satisfied with the last version of requirements.
Producers can spend all their energies on their assigned tasks.

Then all the magic disappears.

A new tall order has arrived in for changing the reality.

Again new plans are produced, usually without any consultation with the producers (probably in order to save their time).
Any trace of the previous past, shall be carefully erased. Just in case any doubt would be arisen about the far-sightedness of the project manager.

Facing difficult changes

Instead of “crying over spilled milk” (in other words, “unexpected” stakeholders’ requests for important changes, incoming big issues – until now considered as remote, risks that needs actions well beyond the PM allowances) the project management should investigate properly the accident (Prince2 Exception Report).
This means to analyze the current situation using the terms contained in the (updated) Business Case. In this analysis, the involvement of producers is essential, if it is properly focused on the event itself.
Emotions could be a big obstacle to the correct management of a brainstorming. If the current policy about changes is based on “erasing the past”; the authority could be challenged, jeopardizing the whole project.

The importance of baselines

The impact of the possible solutions shall be verified using the whole history of the project. From the well maintained documentation (including plans) it is possible to single out the trends (statistical tools – especially based on Monte Carlo system offer excellent support).
These results would supply, and then confirm, the validity of the options made available through a structured and honest confrontation with all stakeholders.
The validity of those proposed solutions shall be reviewed under both on the “Business Case – Reasons” and then “Acceptance Criteria”, especially for the “technical” aspects that influence the users.

Conclusions

The terms “life” referred to a project is not a simple label.It is a strong concept that allows managing properly any aspect of the processes needed for the outcome.

The idea of using plans as worn carpets that can be piled on, just to hide the elephant, does not work.

“I have a memory like an elephant. In fact, elephants often consult me.”
Image: http://www.phrases.org.uk/meanings/elephant-in-the-room.html

Risk contracts in Business Case

Eugenio — Thu, 23 Jul 2009 15:42:58 +0000

Finding the right connections

In the Business Case, Risks are future occurrences that could reduce the ability to respect Costs and Timescale (and Performance).

The risks are shaped by “Options” and the resources needed for reducing their impacts should be found within the “Benefits Expected”. If the strategy for tackling a risk is based on its acceptance (yesterday’s post) , “Reasons” should be strong enough for sustaining the (potential) damage for the ratio that has not been covered by any form of hedging.

Risks in relation with contract’s type

PMI supplies three forms of contracts:

Fixed price:

A lump-sum amount will be paid for the delivery of well defined outcome (either product or service).

Cost reimbursable:

The seller will receive the corresponding amount of the incurred expenses plus a fee representing the seller profit. Costs are categorized in direct one (those incurred for the exclusive benefit of the project) and indirect one (the company’ overheads).

Time & Material:

The seller makes available resources, whose costs are categorized by professional skills. In this case there is no incentives related to meet or exceed selected project’s targets.

Whatever is the chosen contract’s type, the basic risks remain the same. They could be resumed in few questions:

Are the estimations (likelihoods) “good enough” for allowing the people with the right skills and means to match the requirements?
1. What does mean “good enough?
  1. If estimations are too optimistic create a situation where less money available reduces the possibility either to hire the people with right skills, or they do not have time and “machine” sufficient for delivering the “product” with the stated properties and qualities (either features or performances)
  2. If estimations are too large, the buyer would find difficult to accept a price beyond the market value.
Is the concept of “Quality” shared among all stakeholders? It shall encompass all aspects of the project. These are some important topics:
1. Clarity and feasibility of requirements.
2. Criteria for evaluating the importance of each feature (i.e. bluntly: how many users will benefit from it?)
3. Is the chosen architecture (COTS) near to the product’s needs?
4. Is there enough familiarity with the proposed technologies?
5. What can be considered properly “done”?

Productivity is not enough

Reducing the process of producing software to the development (perhaps with the collaboration of a “special” stakeholder) offers a good chance of “if you build it, they will come” situation.

Whether the project covers all step of the product’s implementation, or it is limited to the production, the Business Case has to supply valid interfaces for the remaining processes.

This is a simple list, just for reminder:

implementation
functional tests
documentation
1. for users
2. maintenance
3. learned lessons (best source for next estimations)
training
maintenance

Conclusion

Considering the “Reasons” as questions and “Options” (with Costs and Timescale) as answer could improve the role of “Risk” as first test for the project’s feasibility, in first instance and then to probe the organization’s capacity to deal with the uncertainties.

Collaboration remains the key value.

“A ship is safe in harbor, but that’s not what ships are for.”

A PM's workshop » Options