Time machine

One of the most difficult obstacles for applying practical rules to a specific situation is about the timing. This topic can be pointed out by Paul in his Crossderry’s post. Where he complains about the lack of willingness (perhaps ability) of some project managers to read and then try to put to use the precepts in their predicaments.

Is time a resource?

It has a little use if it is taken alone. With no energy, skills or any other form of resources, it remains an empty container. Namely, every person has his/her own unique value for the time; it depends upon the existing conditions.

A stakeholders’ analysis shall include the time perception, not only aiming at gauging the energy level or cultural influxes (for example, example in Mediterranean region, evening hours are considered very valuable). Different departments of the same company have distinct calendars and then meaningful granularities.

The value of time as commodity

From a project manager’s viewpoint, the value of time shall be counted on the set calendar to which the available allowance shall be added.

The importance of allowance does not merely consist in its buffer’s function. This reserve gives the real value to the time. It properly distributed and monitored in each work-package, permits to measure the feasibility and then the importance of opportunities arising in the production phase. Namely, it gives the necessary freedom to producers’ creativity.

This value can be worked out through (at least) two different ways:

1. A negotiation during the Business Case preparation (i.e. when the delivery date is an integral part of the “Reasons”). In this scenario, Scope can be prioritized or an allowance can be added to the available Budget. In any case, these evaluations need to be supported and integrated by a Risk Analysis.
2. (P)adding each estimation. This strategy, in essence, based on the preemption of time as the only manageable resource. The reasons for this choice can vary; however, in most of the cases they are based on lack of confidence in the proposed estimations (on this specific topic, there is an interesting post on projectsmart.co.uk

Different granularities

Each project has its own way to measure time. It is not only the incumbent delivery date.

For example, the available history adds a huge value to the Risk Analysis rendering any estimation much more reliable and less costly. Each stakeholder’s experience is one of the main values in this element. On the opposite side of the measurement units, there is system’s response time required/perceived by users.  These items are listed just for giving a quick glance of the importance of understanding and sharing the time unit.

The importance of time as metric

Before starting the scheduling, each process needs to be defined in its qualities, for example:

1. Scope and results to be measured in a consistent way.
2. External and internal priorities.
3. Financial costs.
4. Time’s granularity.
5. Duration and reviewing periods.
6. Resource availability.

Once all these items have their own price, and this has been approved, the process needs to be framed (synchronized) in the mainstream; then, the calendar shall be issued considering the interest of each participant.

Coming back to Paul’s post, the Risk Management Plan is much easier to be managed when it is created and maintained with the “Main Plan”. In my post there is a simple proposal for adopting MS Project as the standard tool for managing all plans, arriving at the Work-package level (going under adds a big burden to technical people).

Conclusion

“Reading furnishes the mind only with materials of knowledge; it is thinking that makes what we read ours.”

Image courtesy of: maxthemac.com/…/2008/04/time-machine-logo.png

Venice view from Canaletto

This post is a small contribution to a great presentation from InfoQ.com pointed out by Herding Cats. Moreover, there is a nice comment from Better Projects.

Where Up Front Design (long terms technical plans made at project’s beginning) are conjugated with all possible cases:

1. Big design. All roots of risks (in particular changes in requirements) are carefully reduced. The OBS –and related financial support – shall be strong enough to supply the necessary workforce that would cover any possible issue.
2. No design at all. The gap between the requirements and available resources tends to nil.
3. Relative design. Strong foundations are well entrenched for allowing tactical adjustments.

Criticizing the big design

James Coplien & Kevlin Henney are smart and experienced developers (and leaders as well). Their ideas are based on the “Agile” concept of organizing the production for making easier to accept modification until the latest moment.

This viewpoint will find strong advocates in those customers, who need short time-to-market approach. Therefore, risks related to increasing budget can be reasonably accepted in view of maintaining unchanged the delivery date, scope and quality.

The limits of “beautiful” design

The idea of designing all details (RUP), leaving the simple act of coding to the developers, could be considered as an evolution of the “Big design”. In fact, there should be more interactions with customer, who should be enabled to judge the correspondence of designs with their requirements. To support this viewpoint, they cited L.B. Alberti – who warned architects about the risk of drawing a “would be” reality, instead of spending energy on “mechanical” concepts (those which make a structure working).

In their viewpoint (confirmed by my experience) this approach has two big weaknesses:

1. This is based on the assumption that the customer can read and go through scores of even more complex diagrams.
2. The creativity of developers is nullified, increasing the chances of risks either caused by lack of adherence of the design to the “hard” reality of coding; or different results produced by misunderstanding between analyst and developers due to the lack of intelligent human interaction.

No design at all

The only reasonable scenario offered is produced when developers have experience (technical skills and domain’s knowledge) enough for dealing with the “new” project without the need of a plan produced by an “external” analysis.

Missing this condition, the result is a failure.

Strong pillars, smaller creativity and continuous interaction

After a “short” period of inception, the architect (senior developer) starts to write down the necessary (working) code for creating the fundamental (abstracts) classes. Once, these objects are tested for responding to the major customers’ requirements. This enables the (junior) developers to work within a working and dedicated frame where they can tackle the details and accommodate the changes requested during the development.

Conclusion

Given the uniqueness of the projects, this classification offers a good system for understanding the correct (technical) approach. However, the choice shall be taken considering the real options available.

A thorough and impartial assessment of the available resources (that starts from the senior management) is the unavoidable process that shall precede and strongly influences the organizational and then technical choices.

“All generalizations are false, including this one.”

More readings

http://alistair.cockburn.us/Notes+on+the+writing+of+the+agile+manifesto

Focus on value

One of the biggest problems that affect the IT projects is generated by lack of clear roles and responsibilities. To avoid this dreadful sin is essential to stick to fundamental concepts. The effort of clearing the sources improves a holistic approach.

Whatever the reason for undertaking a project, there are some people who will spend their goods (money – customers and energy – workers) to obtain benefits. Once those benefits are strongly shared among the participants, the enterprise can challenge the future with its load of risks.

Whether these advantages are financial profits or not makes the nature of the project itself. In terms of business, the available monies take the name of budget.

There are many budgets as many stakeholders’ groups. Here below is a simple list where they are listed as per magnitude:

1. Customers’ organization. (How much money they will make available in the time span from the order to the delivery)
2. Performing organization. (The expected revenue shall be deducted from the above amount)
3. Performing team. (The money to be allotted for buying the needed resources).

After some shearing, the Project Manager receives the financial means to carry out all the tasks necessary for producing the “stated” outcome.
The “financial means” shall not reduce everything to few pliable figures. Money is the measurement’s unit to be used for gauging the estimated efforts required.
It is not a mere philistine point of view. Inspiring people is an essential component of management. A strong ingredient, for coalescing people into the idea, lies in its chances of success (Nervos belli pecuniam infinitam) Endless money forms the sinews of war.

Time as well needs to be transformed also in money

.
Time and money form a bi-dimensional measure that will be used mainly for sustaining the efforts and then gauging results. These are the main reasons for that:

TIME

Is the delivery date calculated on market’s expected benefits? If so any decision about the arising variation (usually delays) shall be taken on the estimated costs (reduced benefits).

It could be a fine’s amount, if the project’s scope is about conforming to new regulations.

EFFORT

All estimations about the tasks’ duration, shall be worked out into financial figures. Using a simple spreadsheet where each role (or detailed at person level) is “priced”. Put on a second sheet all required tasks (grouped per features). The result comes from adding the single products of time allotted per person to accomplish with the task delivery.

Strategy

How much does it cost the involvement of that professional role?

Does it worth assigning longer time to a junior developer instead of a seasoned one?

SCOPE

Assuming that the whole product can be split into “detachable” features, each of them could receive a value. From this a production’s calendar (priority) can be set in accordance with technical constraints.

Change management

As soon someone (either from customer or technical people) springs up with a “little modification” (too bad if it regards some existing and working code), every bit of time (effort) needed for changing the plan shall be worked out and put on the scale, looking for a new balance between costs and benefits.

Linking time and money brings in two different and complementary tools

.

EVM.

Cash flow

Is it possible to split the project’s budget into instalments? If it is, when money shall be made available? This information improves

• the opportunities to shape better contracts
• the company’s financial management
• reduces the project’s (financial) risks.

Can money evaluate quality?

It is possible until the product’s acceptance from the customers (users) influence the perception about the project’s success. In many situations, it is very easy, these are some cases:

1. The application produced by the project helps users to reduce the required working time to complete a task.
2. A market success, where customers pay for the project’s outcome.

Conclusions

Time and money should be the basic figures to be used for setting metrics.
A seasoned (and cynical) person said that setting metrics is a good way to prod people’s fantasy for eluding them. .Complex metrics offer enticing opportunities for this kind of undue creativity.

Concepts like: clock and wallet, are simple enough for being understood by everyone. This is the arena where the manager’s communicating skills are tested.

Timebox

It requires creating a capsule, where one or few people possessing sufficient skills and resources can deliver quicker and better results. The pressure of time gives energy to them. The sense of affiliation increases the communication system inside the group. It works if the bubble doesn’t burst.

It could be the internal pressure (poor leadership).
Another cause could be the lack of external interest; when the outputs are not synchronized and or aligned with the project scope.

This group shall be managed externally. It is part of the whole project, an essential share that must be integrated (at the capsule opening) with remaining stakeholders.

For this elitist nature (only the brightest and the best can join the team), this approach should be limited to the initial phases of the projects. When the people aspirations will be transformed in objectives. Thefore the business case can be issued.
An example:

1. Eliciting requirements that will create the foundation of the project scope.
2. Devising the architecture.

In both cases the scope of each task is clear, therefore the time (then money) allocation is easy to be managed.
The planning and then production phases need a much more prosaic approach.