A PM's workshop » Gantt

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

Contingencies & Risks

Eugenio — Wed, 05 Aug 2009 12:58:19 +0000

I have glided on Susan de Sousa’ blog, following a chain of links. My interest has been drawn by the section dedicated to Risk Management. A lot of efforts have been spent by this site for divulging this extremely important argument. The used approach is very friendly and involving. This could help the avid reader, looking for the right recipe, to identify him/herself in the hectic process of dealing with unexpected requests, for example: a “contingency plan” [1]. However, it seems to me that an unstructured approach makes much more difficult to deal with planning projects. Especially when they should be framed into a governance.

From a Risk Management viewpoint, before preparing a “contingency plan” (perhaps together with the “fall back plan”) it is essential to establish and allocate the correct amount for risk budgeting (as explained in previous posts).

A oxymoron to be pondered

Contingency: something liable to happen as an adjunct or result of something else. [2].

Plan: an orderly arrangement of parts of an overall design or objective [2].

In essence, the idea of spending energy for reducing the effects of an uncertain event could seem a waste of resources.

“Contingency / workaround plans”, or “Exception plan” [3] should be viewed as a stem of the Risk Plan. A bud, which can sprout quickly and strongly, because it has all the information (DNA, if you have a boy who loves biology) is contained in the trunk.

For post reasons, the PID[4] (Project Initiation Document) is reduced to the Master Plan. Therefore, any reference to Quality, Acceptance Criteria etc. are included in this document.

Using Gantt for preparing the Risk Plan

As described in the previous posts, it is insane to think Risk Management as a marginal activity of Project Management.

The Main Plan[3], which includes all work-packages without details, should be used as blue-print for entering all structured information produced during the Risk Analysis (this requires that all risks – excluding the Critical Path – have been identified). Obviously, this process shall be repeated for each work-package, which could be deemed worth it (especially if it is on the CP).

MS Project offers all the features for setting a good Risk Tracking system and then attaching all necessary documents for preparing the various “contingency plans”.

The “resources” named beside each task could be the natural “monitor” for checking the triggers’ status. Therefore, for each point that can touch off the event, then a threshold value shall be assigned alongside the method to verify it. All these items will be taken as notes and attached documents, to become integral part of the whole plan.

Contingency Plan is not enough

Hospitals are indispensable institutions. This is not a valid reason for a reckless behavior.

The Risk Analysis shall include the Risk Quantification and the Control / Response.

The forms of response are:

Avoidance. When the root of the potential problem can be eliminated.
Acceptance (it is not about ignoring the event, just keep it monitored for controlling the if the impact is within the set tolerances)
Transference. Any form of hedging, including the outsourcing of the item.
Mitigation. When the magnitude of the impact can be reduced within tolerances.

This means that the first issue of the Main Plan shall be reviewed on the basis of the information produced by the Risk Analysis.

This is the first action classifiable as “Mitigation”; others will be implemented during the review of the Gantt chart (e.g. “Leveling resources”).

“The budget evolved from a management tool into an obstacle to management.

Conclusion

I suppose it is in the blog’s nature leapfrogging from one topic to another that should be placed ten chapters later. For me is a wonderful discover, the chance for tackling issues on the spur of the thread.

Gantt -2 (Business Case)

Eugenio — Wed, 01 Jul 2009 11:09:28 +0000

The project has to answer to a (reasonably) well defined need. This answer, to be useful, has to be centered in only one logic that will be transformed into a product.

Complex products are composed by different parts kept together by an unique logic. If, sometimes, it is possible to release prototypes with some “visible” features; it does not mean that the whole product can always be split into separate objects, where each of these parts can be delivered to the customers for their approval.

Another kind of business case

From this starting point, the want for single documents that contains the whole logic is essential.
Everything starts with the Business Case. It is the first and most important baseline for an evolutionary process that includes some iteration.
It belongs to the Sponsor (aka Executive) and forms the guidelines for issuing the Project Manager mandate.
The reasons, for repeating these concepts during the Gantt’s analysis, stem from the need of creating a solid frame for referencing the workflow. The latter will be adapted to each company’s organization necessities.
These are the elements that compose the Business Case:

Reasons:: The drivers as presented by the “external” stakeholders.; The main outcome’s features are presented (possibly in order of priority). Whenever possible an estimation of their stability has to be included. This will influence both the estimations’ validity and the Change Management); The customers’ organizational aspects have to be briefed highlighting the approvers and influencers.
Options (listed subsequently): The available alternatives have to be produced for the following areas:

Technical architecture
Approach (e.g. COTS, from scratch, prototype etc.)
Managerial strategy
Stakeholder’s analysis
Communication & Collaboration plan
Schedules imposed by external factors
Quality
1. Test strategy
2. Frequency and type of reviews and reporting
Procurement strategy
Contract type
Outsourcing
Vendor list
Documentation
1. Future maintenance
2. Handover to implementation team
3. Communication among various stakeholders (from requirements to accomplishments)
4. Manuals destined to training
5. Administration chores
6. Meeting minutes

Benefits Expected

The Business Case is owned by the Sponsor, but it is “used” by PM as well.

This requires including the “business vision” and then its strategical application to the project.

From the PM’s point of view, the strategy has to be focused on delivering the outcome as chartered in the stakeholders’ agreement (something subjected to be change at happenstance).

A solution for improving the success’ opportunities can be offered by linking benefits with the corresponding final product feature (Kano Model). This approach could offer a stronger lever for dealing with customers asking for lodging further requests (unsupported by an increase of budget / delivery time).

Risks

In this preliminary phase, it is possible to outline their nature. The list can help the PM and Sponsor to exclude those do not represent a menace to the project’s survival.

Other two essential sources for laying out the Risk Analysis come from:

Stakeholders’ analysis
Design walkthrough

Usually a narrow range of choices is a potential source of risk. This is due to the supposed indispensability of the “supplier”.

Costs

Available budget. This amount shall be confirmed by WBS results and should include tolerances (reserves). These have to be differentiated between those available to the PM and those requiring the Sponsor approval.

Timescale

Delivery date(s). Again the values provided by the estimations have to confirm the feasibility of the enterprise. The nature of the outcome and the customers’ interest could favorite the schedule of various releases.

Investment Appraisal

This is a topic to be tacked at two levels.

The (beneficial) impact(s) of the project on the business shall be stated by sponsor and/or stakeholders.
While the Project Manager has to be aware of the influence of the project on the whole business, he/she must keep the focus on the daily management of all tasks that allow the delivery of needed outcome.
At PM’s level the project’s value is the budget made available.

Evaluation

This section pertains to the Sponsor. It contains the results of the “Investment Appraisal” (financial) benefits to be weighted against the costs.

Conclusion

The project is a complex enterprise. It requires the strong and clear willingness of participants to spend their resources (money and energy) for delivering an outcome that fulfills their expectation.

The adoption of a common pattern (as distilled sum of previous learned lessons) renders this operation easier. It has to be flexible enough for responding to each specific environment.

A business that makes nothing but money is a poor business.

Gantt – 1

Eugenio — Tue, 30 Jun 2009 18:03:35 +0000

For its apparent ease of displaying complex situations, the use of Gantt’s diagrams could be considered a flag in the project management’s methodology dispute.

From one side, traditionalists see in the bars a tool for organizing the future. Framing any source of risk in order to obliterate them.
On the other side, the “agilists” try to substitute neat tags and figures with more friendly panels covered by leafy post-it.

Both wings have in common the disrespect of the rules supporting this tool. The first and most important forgotten rule is about the information that feeds the model.

This is a very short list of questions that should shed a little light on the nature of Gantt’s diagrams:

How the project’s benefits are managed?
Are the stakeholders’ interests being taken into consideration? If yes, where is the strategy for answering to their interests and desires?
Where the list of tasks does come from?
How the listed tasks are linked to the product’s features?
Who is accountable for the figures forming the estimations?

Next posts will be dedicated to share a series of connected points of view. The aim is to produce valid answers.

How is Gantt’s diagram working?

It is based on a Cartesian concept. The total time allocated by the project is split into segments (which each length represents task duration). The logic that fastens the tasks together is highlighted by arrows that could start either from the end or start of each element.

The milestones’ added value

Can you build solid controls on milestones?

In order to make easier the readability of time flowing, “milestones” are added as perpendicular lines. These are set as boundaries for checking out the “readiness” (in front of clearly stated quality criteria) of the various tasks.
The choice of setting the Milestones should be taken considering both business and production needs. To them should be associated reviews and decision points. Milestones can be associated to one or more work-packages or springs.

WBS is the main source, Business Case is the major reference

Starting from the B.O.M. of the product (service) to be created, each feature and all the required operations to obtain it have to be detailed. The granularity of this process shall be tuned with the distance in the future of the examined item (farther the target, bigger the scale).

A bit of stakeholders’ analysis

Whether the customer’s forces are sufficient – for maintaining these lines – or not it has to be cleared during the subsequent iterations (negotiations) that follow the process of issuing the plans’ baseline. Sometimes the choice of COTS, that fulfills most of the main constraints (Iron Triangle) could introduce a bias on the vendor and/or producers’ skills.
In other situations (i.e. where web is predominant) customers are a subset of users. Notwithstanding their potential power in the project, the customers’ voice is feeble. Other professional figures (e.g. SME and BA) can gain the sponsor’s ears.
Whatever would be the stakeholder importance during the process of designing the Gantt’s structure, it is paramount that a clear strategy will be followed.
The target for this process, that builds the project’s foundations, is to make available to the people responsible for the next steps (BA, then designers) a structure strong enough to be put it through all risks.

Conclusion

Since the first draft, the plan has to be designed with a clear strategy. This will make it robust enough to be put through all incoming pressure. A coherent logic shall be sustained by the stakeholders’ interests to receive the benefits produced by the project’s outcome. Gauging their willingness and capacity to supply the wanted resources offers a good measure. These can have multifarious natures and shapes. Here below a simple list:

Money – benefits vs. costs
Skills / Resources (e.g. premises, machines etc.)
Information

At the beginning of the process for preparing the “baseline”, the only constraints to be considered are:

Time (delivery date)
available budget and cash flow
Scope (logically-bound features)

In this way, the priorities are forming the project’s strategy.

“Bad planning on your part does not constitute an emergency on my part”

A PM's workshop » Gantt

As the time goes by – Managing versions

Managing initial drafts

Plans with short lives

Facing difficult changes

The importance of baselines

Conclusions

Contingencies & Risks

A oxymoron to be pondered

Using Gantt for preparing the Risk Plan

Contingency Plan is not enough

Conclusion

More readings – References

Gantt -2 (Business Case)

Conclusion

Gantt – 1

How is Gantt’s diagram working?

The milestones’ added value

WBS is the main source, Business Case is the major reference

A bit of stakeholders’ analysis

Conclusion

More readings