In our projects, time comes in two versions:

These truisms are needed for introducing the concept [...]]]>

Nice attempt to hide the guest

In our projects, time comes in two versions:

1. “Fixed” in terms of delivery dates.
2. “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.

1. Risks, duly cataloged, are tamed in their boxes.
2. Senior Managers are assured that the neatly figures and lines will form an insurmountable barrier against every delay or extra costs.
3. Stakeholders have been completely satisfied with the last version of requirements.
4. 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

Since the leadership is classified as source of risk, it is essential to understand it and then find, if possible, a simple way for measuring its efficacy through the evaluation of results. Merriam Webster’s definition: “capacity to lead”. In a project environment, this should be focused on the stakeholders’ relationships. In particular [...]]]>

Leading is about direction

Since the leadership is classified as source of risk, it is essential to understand it and then find, if possible, a simple way for measuring its efficacy through the evaluation of results.
Merriam Webster’s definition: “capacity to lead”.
In a project environment, this should be focused on the stakeholders’ relationships. In particular to the team; when the production is carried out on the site.

The role of communication

Accepting this viewpoint, the most important, if not the only tool made available to the manager is the communication (on this subject, there is a very good post of JD).

Communication is implicit in the manager’s job nature. Whatever is the decision taken, it has been based on incoming information and then – much more important – to find the clincher for selling it, either to the team or other stakeholders.

“Know thyself“

It is one of the three phrases written on the Apollo’s temple in Delphi.
This approach can help ourselves in the process of acknowledging the drives and reasons that entered in our decision and then in the plan. Therefore, the execution of delivering it.

Living in an “illogical” world made of numbers

Whether you are Panglossian or not, our world is far from being subject to rational laws.
However, the results of our projects are measured with figures.
Leadership seems the art of understanding how it works the murky, flawed and semi-primitive nature of our own decision-making, including the heap of uncertainties. Then, using “black arts” convincing our fellows that the proposed act is matching with their personal and professional values; It therefore, will increase their well-being.

A balance between standards and innovations

There is a nice Crossderry’s post about the difference between leaders and managers.

An organization needs governance. Managers are set for checking that the rules are applied at their best. However, people who strive for growing personally and professionally can find difficult to abide to all of them, in particular when external challenges are pressing for new and better solution.

Leadership as source of risks

The previous paragraphs introduce two possible sources of risks:

1. Lack of ability to buy-in the required resources
2. Unbalanced response to the pressures, which could damage the project outcome and the company discipline and/or image in front of the customer.

These keys could suggest an indirect method for measuring the impact of a poor leadership on the project’s output.

Conclusion

Good managers come in all flavors. This matches with the multifarious nature of project’s needs.

In essence, the chances of success are strongly increased when the right group of managers (sponsors, project managers and team leaders) are able to develop an environment, whose rules can work with the global governance, that allows every stakeholder to give his/her best.

Sometimes, problems like disloyalty, kicking back etc. can be made worse – if not caused – by the lack of an environment that does not allow a proper leadership.

Managing risks is about to remove the root of possible problems. In this case, there are some actions to be planned and executed:

1. Being sure that everyone knows and accept the “Responsibility Assignement Matrix”
2. Checking that within the project’s management team there is a good “team playing spirit”
3. Whenever an “order” is issued, be sure of attaching a list of KPIs.

“Leadership is unlocking people’s potential to become better.”

More readings

• http://herdingcats.typepad.com/my_weblog/2009/08/20-reasons-managers-fail-and-ways-to-fix-them.html
• http://www.projectmanagementguide.org/project-management/when-good-teams-go-bad
• http://alistair.cockburn.us/Neurons+with+legs+-+How+wideband+social+media+is+changing+the+world%27s+cognitive+structure
• http://www.greatleadershipbydan.com/2009/08/new-leaders-pocket-guide-to-improving.html

A good chart remains essential

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 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 [...]]]>

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?

It is an adult post. It starts with bees, birds and flowers.

It is not easy to apply these models to stakeholders’ taxonomy. However, these models represent three different conceptions about time (a nice post about it).

The project’s “external” stakeholders have jobs outside the IT industry. Furthermore, [...]]]>

Gear wheels (respect and smile are the best lubricants)

It is an adult post. It starts with bees, birds and flowers.

It is not easy to apply these models to stakeholders’ taxonomy. However, these models represent three different conceptions about time (a nice post about it).

The project’s “external” stakeholders have jobs outside the IT industry. Furthermore, IT projects are not exclusively manned by developers. The multi-cultural aspects have its relevance as well (e.g. working time, time-zone, national holidays etc).

Diverse expertise implicates different rhythms. One of the main aims of the stakeholders’ analysis has to be a model (Collaboration Plan) that can help every key person (approvers) how to work out a common ground for working together.

The “common ground” has to be considered into its “spatial” dimensions:

1. Time (clocks and calendars have to be shared)
2. The unique subject at the base of the project shall be formed clearly enough to be drawn (“Product Description – Prince2”). From this document, other technical outcomes (e.g. architectural designs). After that, the Agile approach can offer good chances for clearing the way to a synergy between producers and users. In an effort to involveall other stakeholders (considering their timing).
3. Lingo (es). Most of the translation job is carried through by the BA. However, the communications at managerial level are based on figures and diagrams. Mostly important, they are supported by mutual trust and respect.

Once the whole matter to be produced is clear enough and the collaborations’ mechanisms (at managerial level) are working. There are subsequent actions dedicated to synchronizing:

1. Estimating the required resources both in terms of skills / capacity and time to be alloted.
2. Asking for resources (information, machine and most important people and their knowledge – either professional or company’s related).
3. Planning, then executing the resources’ released.
4. Working seamlessly people with different professional background, but common targets.

Different speeds cannot hamper the project

Working like an orchestra

One of the most important tasks of project manager (duly assisted by sponsor) is to work as a gear wheel between each stakeholder’s approver and / or influencer.

I become conscious that the concept of “Collaboration Plan” has to be developed (suggestions will be warmly welcome). Today the biggest issue is about to easily render the links between people and time.

Conclusion

Solipsism kills projects. Whenever a person (or bunch of people sharing the “same” space and similar targets) perceive themselves as the center of the universe (it could be reduces as a project), there is a huge risk for failing the delivery of the agreed outcome.

Whatever small can be a project, it is the result of many teams working together. The first and most important matter to be shared is the project’s clock. It will toll the times for controlling and then aligning all stakeholders’ teams.

“The only reason for time is so that everything doesn’t happen at once.”

More readings

http://herdingcats.typepad.com/my_weblog/2009/06/dont-plan-for-change-yea-right.html

http://herdingcats.typepad.com/my_weblog/2009/06/project-rhythm.html

http://sourcesofinsight.com/2009/06/30/there-is-no-shortage-of-time/

http://www.pmhut.com/communication-in-project-management-how-to-communicate