Doing some maintenance to the “crystall ball”

Enjoy the game!

The estimations represent the deadliest risk for any IT professional. The first reason for this is the “battle ground” between technical people with customers. It represents the collision between the power of knowledge and money.

IT people are a special kind of technical people, we are proud of our creativity. Like the Polynesian sailors, who defeated the Pacific Ocean armed only with their skills, we fancy to colonize new islands bringing with us the old seeds that will grow up into new plants.

Alas, we have to respond to the ship-owners, who put the money for our wandering.

In this good post James Waletzky, an experienced developer proposes to avoid the problem of exposing the frailty of the estimation through the tactic of focusing on a small batch of requirements that will be followed by frequent releases. There is a big flaw, in my opinion, in this attitude.

Good tactics can win small battles. However, they never assure the peace. A lasting peace is based on meeting common interests between two strong powers.

Whenever an IT professional is not able to sell his/her own ability that shall include the correct presentation of risks (overcoming the Iron Triangle values), the war is lost.

There ever are two powers:

1. Business with money and needs (with strong skills for gaining the upper hand in negotiations)
2. IT professional with their set of skills (and their needs that range from feeding the family, to growing up in a demanding professional environment)

These two (group of) people meet themselves in the ever unique ground of the project.

The PM should be on the technical side for the simple reason of leading the producers’ team. He/she has to work as interface between the “external” stakeholders (business) and the internal ones (technicians).

Dealing with “big bang”

Whenever the business is looking for the “big bang”, it is PM’s job to transform it into a feasible plan with the help of  all stakeholders. Instead of taking it as “suicide mission” (it is dangerous!), the PM – with the help of the team and the sponsor – shall be able to negotiate all elements (starting from the Iron Triangle) that form the business target.

This process has to be iterative, but not repetitive. They can resemble to inward spirals, starting from big concepts until clear lines are set for the “producers” team(s), just because the project includes the development, but it is not the only one item.

The first cycles of negotiations will form the framework (from architectural aspects to quality settings). Then it is possible to move into product’s features (taking into consideration the Minimum Marketable Features –   this is an excellent example of strategy).

The first and the most visible result from this first phase is the plan.

The essence of plan’s feasibility consists in the property of answering to the contingent situations.  It is something that goes beyond the Risk Management. The focus shall be kept on the best way to reach the target set by the business.

More distant is the destination, shorter and more frequent the legs.

Most of the times, the business’ nature will not allow to radically change the course (scope). However, the presence of many control points allows both to evaluate the validity of the benefits as stated in the Business Case at the beginning of the project, and the feasibility of the project for itself.

This kind of approach can offer two solutions:

1. A certain grade of freedom for managing stakeholders’ expectations either about the available features or delivery time.
2. The opportunity to close down the project, limiting the wasting of resources.

Conclusion

The fear of failing (estimations) cannot be accepted as reason for avoiding a credible plan. Business vision, to be transformed into the harsh reality of software development, needs robust tools and strong skills for every person who belongs to the team.

Responsibility has to be calibrated to each role. It does not change in terms of volume, just in terms of scope.

When you blame others, you give up your power to change.

More readings

We Don’t Have Requirements Yet, But How Long Will This Take You?