In my post, following a thread created by Craig Brown and developed by Glen Allen, I closed it confessing my difficult to offer a clean definition of what can be defined as “done”. In my mind there is the “Prince2” definition that sounds:

“Everything that has passed the tests based on stately accepted [...]]]>

Where to cut

In my post, following a thread created by Craig Brown and developed by Glen Allen, I closed it confessing my difficult to offer a clean definition of what can be defined as “done”. In my mind there is the “Prince2” definition that sounds:

“Everything that has passed the tests based on stately accepted criteria”.

However, this leaves some room for the human factor. It is true, especially the perception from stakeholders about what can be accepted. Many stakeholders’ categories (graph) have different viewpoints on both terms of features and quality. In particular about:

1. What can be delivered (developers)?
2. What can be accepted (customers)?

The answers could be found in the Glen’s questions and my answers:

1. Can we state clearly and concisely what “done” looks like? Can we state the intermediate versions of “done?” Can we state this in some units of measure meaningful to all the stakeholders?
   • It can be carried through the completion of all required operations, followed by the functional testing of the output. The results, expressed in percentage, state the readiness of the product. In this way all stakeholders can find a common ground.
2. Do we know what it will cost to get to “done” or any smaller version of “done” along the way? This cost is usually measured in money. But people and other resources are part of the answer as well.
   • EVM (properly managed) could measure the ratios between efforts (monetized resources) and results (passed functional tests).
3. Do we know the date of when we’ll see “done” or any part of “done?” What the variance on this date? If we don’t know the date of the final “done,” how about a “date for the date?”
   • At work-package level (team) these evaluations shall be done frequently and openly (involving the customers in clear and friendly terms). At a “higher” level, the “IMS” (major plan) should be based on precise dates (including tolerances).These will supply (together with the WBS and then Product Backlog) the criteria for shaping the gateway destined to evaluate progresses. The terms and conditions each of these processes shall be verified (and confirmed) at each level. In my previous post were described the risks implicit in setting a rigid structure up.
4. Do we know how we will measure progress along the way? How will we have confidence that progress is actually being made? What are the units of measure for this progress?
   • Planning (at project level, leaving details for the work-packages) shall include Risk Management and Test. The definition of capabilities (features) cannot be done without stating clearly what has to be used for measuring them.
5. Can we see what is going to impede our progress toward “done?” Do we have any way to remove these impediments so we can get to “done?”
   • Only if the product is clearly described (at various levels and times) it is possible to manage the production and consequently the outcome.

Conclusion

“You can manage only what you can measure”. This notwistanding the article of his father (DeMarco).

D/load PDF version

The existence of a neat diagram seems to reassure enough most of the stakeholders (and sponsors).

Like a loom, Gantt’ diagrams offer (with apparently easiness) the possibility of adding weaves in order to create a design that will be self-explaining the whole project’s logic.

There are some questions for probing this viewpoint (and [...]]]>

Logic applied to art

The existence of a neat diagram seems to reassure enough most of the stakeholders (and sponsors).

Like a loom, Gantt’ diagrams offer (with apparently easiness) the possibility of adding weaves in order to create a design that will be self-explaining the whole project’s logic.

There are some questions for probing this viewpoint (and its opposite, which privileges the patch-work approach).

In order to make a little bit easier to deal with the many issues, they are split into two main sections:

Visual aid (Q)

1. Can the bars, showing the task durations, conveying enough information for understanding the required efforts (These are some hints)?
   1. Total costs for employing resources
   2. Kind of resources (people, machine, premises) when it means different costs and/or suppliers.
   3. Informing about the structure of the task, if crashing is required
2. How can the bar (a rectangular shape) shows the un-linear (front/back) workload within the represented period?
3. How many activities can be reasonably represented without cluttering the whole screen/sheet?
4. Is the diagram focused on the target audience (either Snr management or developers’ team?)
5. Are milestones set in order to give a rhythm to the project?

Visual aid (A)

1. No. The bar’s length shows only the task’s lasting.
   1. The total cost of each task – based on the allotted time for each resource (either people or machines), will be worked out through the estimations. However, the budget has to be spread on various tasks using the WBS. The resources (and the dreaded job of leveling resources) have to be managed separately. There are plenty of reasons for considering this as a “special” job. It shall start and maintained with the estimations (initially based on WBS).
   2. The kind, number and skills of people needed for completing the task shall be dealt separately (earlier than the Gantt’s issuing, this because of the need of producing estimations that will supply the model’s figures – i.e. bars’ length)
   3. It depends upon the targeted audience (and specific issues to be dealt with) to deep into details. However, each task should be linked to specific (either procedural or architectural plans).
2. As seen before the kind and number of details (in this case a breakdown of the bigger task) shall be tuned on each audience’s needs. However, each view has to include all stakeholders’ contributions. By the way, MS Project offers an icon to signal the type of workload. This would be useful as placeholder for further in-deep analysis.
3. The main aim of a diagram is its readability. The scope of rendering key information to the audience. The global picture has to include:
   1. All stints forming the analyzed range (i.e. project or work-package)
   2. Their relationships that shall show the dependencies in terms of resources involved (e.g. input /output and controls).
4. Whoever is the viewers (approvers) and doers, the names are a due sign of respect.
5. Milestones are set both for business and internal (quality) reviews. Their time-spans are the best suited tools for giving the vital rhythm to the project. Synchronizing reviews close to business deadlines will improve the communications among stakeholders. The simplest and the most efficacious way to realized it comes from setting the work-package duration. Fixed stage reviews (like “springs”) underpin the correct pace.

Validity and maintenance(Q)

1. Has the feasibility (costs) of regularly feeding the model probed?
2. Are the relationships among the tasks clear enough for spotting responsibilities?
3. Are the estimations provided in a way that highlights their dependability on the producing teams?
4. Can it be considered as the main (principal) tool for managing project (considering the following provisos)
   1. Supporting Risk Analysis and Management (i.e. “Critical Path)
   2. Financial aspects (i.e. NPV / Cash Flow)
   3. Stakeholders relationship analysis / management
   4. Quality management at work-package output level
   5. Human Resources management (focused on estimations)
   6. Financial aspects (i.e. NPV / Cash Flow)Supporting Risk Analysis and Management (i.e. “Critical Path)

Validity and maintenance(A)

1. As communication tool. It is meaningful for its reliability. Older data are wrong data. Any assumption and decision based on that information is a big source of risk, both for the project and for the manager’s reputation. The costs for building / interfacing with the existing network will be easily repaid by an increasing in productivity (as discussed in the previous posts)
2. Estimations are the lifeblood of the project. They shall be presented with their margins of accuracy (risks). On this vital topic, some more posts will be spent on. The pace of their updating will depend upon the following factors:
   1. Change management (modification of requirements from stakeholders).
   2. Coming closer the work-package to be produced (the initial estimations will be probed using the previous productivity figures).
   3. Input from the Risk Management.
3. Using MS Project with care, it can support:
   1. The Risk Analysis and Management. The starting point will be the “Critical Path”
   2. Managing financial aspects based on the usage / costs of allocated resources. These jobs shall be integrated with spreadsheet and company’s ERP.
   3. The Gantt’s diagram must cover all project (not only the development stage). In this way, the stakeholders relationships are linked to their effect on production.
   4. The adoption of the concept of fractals could introduce the same structure (with different levels) in setting and managing quality controls.
   5. The tags besides the bars represents human beings. Each person is accountable for those figures and the related results.
   6. For producing reliable and understandable figures, Gantt’s diagrams have to be treated as tools for collecting information that will be dealt with spreadsheets(more to come in the next posts).

Conclusion

A simple solid fractal

Project management consists in orchestrating activities of different teams. This requires well working infrastructures that collect and deliver reliable data about any resource for which the project is accountable for.

The strength of this tool lies in its capacity to produce visual patterns.  To overcome the graphical limit, and those related to maintain a meaningful names’ map (to be used for drilling into details), it is useful to adopt an approach based on fractals.  Once the structure (compatible with the WBS) has been presented for the highest level, it shall be repeated for each diagram (this is a viewpoint that will be discussed in the next posts)

In this way, the column containing the labels will maintain the same fonts/colors and references to the previous diagram (with the help of hypertext links).

This goes beyond the visual aid, it can be sold as project management mark.

“A poor tradesman always blames his tools”

More readings

http://www.projity.com/

The WBS is one of the earliest “top-down” techniques in the project management. To acquire the sufficient knowledge about the feasibility of an initiative, it is necessary to split it into smaller tasks. This action brings the following advantages: