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

Thanks to a Craig’s post for asking a key question. How much does it worth spending energy on communication?
The answer comes, quite straightforward, from the end of the post itself.
Communication, in a project environment, makes its sense only if it can keep stakeholders aligned on the agreed project goals.

From Hemiunu (the Cheops’ pyramid‘ architect ), then citing Genghis Khan to USA president Obama, the power has been exerted through an effective communication.

The incoming results can confirm and feed the power itself. Without a system based on accountability, is it possible to attract bright people to work together?

“Counting” (efforts vs. results) needs a basis of shared values

The lasting success is based on construction of a common ground, where the estimation and evaluation are two faces of the same coin, is based on the concept of responsibility.

In our company’s balance sheet, the values adopted to measure assets, equities and liabilities are commonly accepted both within and outside the company itself.

Sharing common values

The moral and cultural values forming our attitude and forging our behaviors are not automatically recognized by everyone. However, those forces push us to strive for success (or just survival). In a project, there are two key moments (in a successful project, they are repeated many times). Estimating efforts required to complete the tasks needed for accomplishing the target. Evaluating the results of the aforementioned efforts The same metrics used for estimating the allocation of the resources shall be used for measuring results. This implies that people, who proposed the input figures, shared the same values (at least about the metrics) as the people judge the outcome.

Conclusion

Whatever is the role within an IT project, each job includes a certain grade of autonomy.

Therefore, any decision taken by any stakeholder needs to be communicated to someone who can use it for assessing the progress (i.e. evaluating the risks).

Accountability and communication are inseparable values. Both are indispensable ingredients for trust.

More reading

The Llewellyn Group Blog

If it is not seamlessly integrated with the processes to be monitored, it will hamper them. The adoption of ineffective metrics or the disorganized collection of their results will supply wrong information. This will influence the decision-making process It could reduce the effectiveness of the communication through a lack of human relationships. Furthermore, it could introduce / confirm the concept of a “bureaucratic” irresponsibility. External requirements (e.g. legal, company policies) that are not properly managed by dedicated resources.

Is slower also safer?

Which are the reasons for setting procedures for producing documentation?

The documentation shall support the steady flow of information within the stakeholders. The availability of true, clear and updated information reduces the risks of late delivery and/or under performing products.

These are the sketchy steps forming the project’s life cycle:

1. Requiring / Outlining.
2. Producing / Testing.
3. Verification of the outcomes against requirements.
4. Delivery / implementing / maintaining.

Grossly, in every methodology the project is split into three different phases. The way these phases are distributed does not change the reason for a correct data management .
Data are produced, collected, distributed and stored for future reference (learned lessons).

Planning

Outlining, listing and estimating the required effort to complete the necessary tasks to be undertaken for reaching the business outcome, within the allocated time and budget.

Producing

Carrying through the planned activities. This is the phase when plans meet reality. The ability of the team consists into making tactical changes without loosing the final aim.

Controlling

Register each person activity / position related to the project (including the possession of useful data). This kind of information will be used either for sustaining tasks related to the production or counting the efforts spent.

Introducing Risk Management

The dynamic measurement of gaps, between the forecasts and the accepted results, supplies the data for the evaluation of the risk.

Risk Analysis and management are based on the following factors:

• Possible occurrence of the event in the project’s life.
• Estimated impact of the fact on the business’ outcome.
• Planned actions to reduce the impact of each risk on the production.

During the Risk Analysis, the availability of documentation (created in the planning phase) facilitates both the process of evaluating the chances of risks’ events and its impact on the task’s results. These inputs are available for planning actions destined to mitigate the impact of the risk.

An effective analysis of the production (produced in the controlling phase) offers automatically the basic elements for Risk Management. The difference itself between the planned and expected is the first source of attention toward arising or increasing obstacles to the production and subsequent delivery.

Conclusion

The project’s failure hurts anyone who has worked on it, both on the business side and each team member. Good communication can improve the chances of success.

Setting working procedures is, very often, a task beyond the project manager’s scope. However, it is his/her specific responsibility to maintain a good level of understanding within the team and toward the stakeholders.

“If you don’t like their rules, whose would you use?“