Agile planning and the story points approach - Part 02

In the last post post of this series, we have discussed an Agile project management estimation technique, useful when planning in a context of high uncertainty.
The estimation of tasks' sizes using story points.

The concept at the core of the evaluation by story points technique is to estimate activities’ related efforts, instead of activities’ actual durations. Then, as the project progresses, we will be able to transform points into time, using performances achieved in previously accomplished activities.

In this post, we will talk about why this kind of approach works. We will go a little more in-depth, giving evidence of some common pitfalls and solving doubts that typically emerge when approaching this technique.

Why it does work

Relative estimations are easier than absolute ones

It is much easier estimate something comparing it to what we already know, instead of making up a precise quantification out of the blue. You can get evidence of this claim at almost any moment in your life, in which you have to explain something to someone. What would you rather say “Hey Jack, do you know that Tom is 1.76 meters high and weights 97 Kilograms?” or “Hey Jack, do you know that Tom is almost as high as me, and weights more or less the same as Pete?”

Velocity is the great equalizer
The team could estimate its velocity as the average of the number of story points achieved in the last N iterations. It would be pretty useless for the team committing to the implementation of 25 story points in the next iteration if the average velocity achieved in the last 5 iterations is 10. The velocity concept and the averaging operation will smooth out the effect of any unforeseen problem (or luck) that the team may have encountered in performing the job.

Agile teams are, by definition, multidisciplinary teams
The presence of people with many competencies and skills in the team helps in achieving meaningful and reliable estimations. The number of points for one story should not be decided just by an individual. It should come from negotiations and confrontations between all the team members. This approach leads us to the next principle.

The team, not the individuals, commits to a velocity
The work to do, in an Agile team, should be shared by many team members. It is all right to have a specialist in software testing, as long as he/she won’t take care of all the testing. The most skilled team member would probably take care of the more delicate tasks in its specialization domain, but he/she have not to exclude other team members from this kind of activities. Just, in this case, the team can commit to a common objective. Otherwise, you won’t have an Agile team; you will end up with a bunch of professionals, trying to deliver something in their specialization domain without getting in the way of other people.

To have it working

The team composition should be fixed
Team velocity is based on estimations of task’s size and execution performances. Usually, some iterations are necessary to reach convergence and give reliable evaluations. 

As you may imagine, if the team’s composition is frequently changed, there is no way to reach a condition of stability.

Agile teams must be made up of T-people
Since in an Agile teams, estimations are made collectively, and tasks of the same kind are shared among different resources, you need the so-called T-people. That is to say, people who are extremely proficient in a given area of the project, but sufficiently skilled to be helpful in many others.  

You need ants, not tigers
Agile teams must be made up of average performers, who care more about the team than themselves. Do not directly jump to conclusions; you do not need dumb people. You need a well-balanced set of smart people, with comparable performances. Believe me, you do not want to have lone rangers or superstars in an Agile team.

You have to make a transition from the standard project management paradigm
Obviously, if the team has to commit on an objective to be reached in an iteration, all the members should have a certain degree of freedom in selecting the target itself. This approach requires a particular shift in the project management paradigm.

In an Agile team, the project manager must delegate more than in a standard environment. The team must be free to select the tasks to perform in the iteration, balancing the stakeholders’ requirements with the team’s capabilities.

Common pitfalls

Story points have no meaning per se

Story points define the size of an activity related to the other ones; do not try to convert them to man/hours and to redefine activities’ durations. Story points conversion is a dangerous road to walk by. Work with story points and use velocity.

Do not change estimation of past stories
Sometimes you may be tempted to change the points size of some features; maybe because you become aware that a task is much more difficult (or easy) to perform than previously expected. In such a case resist the urge to change the task’s size. Remember, velocity is the great equalizer. The story points and velocity system will take care of such eventualities. If the task to perform is much more complicated (or simple) than expected, you will experience a physiological velocity increase (or decrease) in next iterations.

Different teams’ velocities are meant to be different
Once I hear a project manager saying “Team A is performing better than team B; in fact, team A achieved a velocity 5 points greater than the one obtained by team B.” Dead wrong. Different teams, with different tasks and different estimations probably will have different velocities, but this means nothing. Remember that story points have just a comparative meaning and are subjective from team to team. Do not compare teams’ performances basing on their velocities.

A last comment

If you think that an agile planning approach is not a silver bullet, you are perfectly right.

Agile planning is an extremely useful tool, that should be present in every project manager’s tool bag; nonetheless, you have to select carefully, which projects could benefit from it.

Furthermore, do not forget that also the business environment in which the project lives should be ready to adopt such an approach.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Perception and project management processes value

Perception is a funny thing; this, if nothing, I have learned in my life.

It has never happened to you, to involuntary hurt someone else’s feelings, just by sending him/her one e-mail, which you thought was neutral? On the other hand, have you ever been upset by a friend’s humorous comment, that, in the author’s intentions, was meant to be no more than a joke?

If this is the case, as I guess it is, you know well, what I am talking about.

Different people perceive the same things in different ways. We have talked about that in an older post.

Sometimes this attitude has to do with one’s culture, sometimes with his/her educations, some other times, simply, with temporary circumstances. You just can say.

Therefore, there is no such a thing as an objectively perceived reality, but rather, we have to cope with many different recognized ones. Luckily, this bunch of perceived realities often overlap enough, to grant a sufficient interoperability margin. The only things that cannot be misinterpreted or disguised are objective data.

The same pattern applies also to project management processes.

The dichotomy, here, is about the value that project management processes ensure and the value that the project’s stakeholders perceive. Please, take a look at Figure 1.

Figure 1.

On the y-axis, there is the value that the project’s stakeholders perceive as granted by the project management processes. On the x-axis, we can find the value that the project management processes deliver.

The 45 degrees line is the place where the perceived value matches the delivered one. The line is the project manager’s Shangri-La, the place where he/she will have to place. 

Criticism zone

The criticism zone is the region under the 45 degrees line. In this zone, the value delivered by project management processes is greater than the perceived one.

The stakeholders see the project manager’s efforts as wastes, as expenses to be cut as soon as possible and, therefore, no effective project management is possible.

The project manager has to get out from this zone as quickly as possible, trying to reposition the stakeholders’ perceptions on the equity line. Such an objective is not an easy one. There are no ‘tricks of the trade’. 

The only possible way to reconcile the provided value with the stakeholders’ expectations, is a constant and well-crafted communication, based on sound and objective data.

Esteem zone

The esteem zone is the region above the 45 degrees line. In this zone, the value delivered by project management processes is less than the perceived one. The stakeholders tend to see the project manager as a kind of wizard, an almighty presence with the ability to fix almost everything. 

Even if the permanence in this zone is far more pleasant, than being stuck in the criticism zone, still, the project manager has the due to reposition the stakeholders’ perceptions on the equity line. 

Why? Well, because taking more credit than you deserve is not fair, in the first place; and because, in the long run, it is a dangerous game. 

My grandfather used to say, “A donkey can dress up like a horse but, sooner or later, it will bray”. 

If you regularly fool your stakeholders’ perceptions, what will you do when you will have to rely on those perceptions, and you will find them spoiled by your management style? 

Again, the only possible way out, is a constant and well-crafted communication, based on sound and objective data.

The line

As we have already suggested, the 45 degrees line is the place where the project manager should stay.

Here, the perceived and the delivered value match. 

As we can see in Figure 1, three different zones can be identified on the line.

The minimum zone

The project management processes in place do not deliver great value, but this is crystal clear to all the stakeholders. They know what the project manager is up to, and if they feel like, they can ask for processes that are more valuable. 

Remember that you do not have always to be number one. Maybe, the value you are providing is good enough, for the project at hand. 

The minimum zone is adequate for small projects, characterized by short schedule, low budget, few people and few uncertainties.

The standard zone

The project manager is providing a standard level of value, with the management processes in place. Everyone knows it. No one can argue that the project manager is wasting money or is underestimating the effort required.

The premium zone

The project manager is providing great value, using complex and articulated processes. Still, everyone knows it. If the stakeholders require less effort, they will do it on a real data basis, and not just relying on perceptions. They will know that they are going to trade money with control.

The premium zone is right for big projects, characterized by long schedule, very high budget, many people and many uncertainties.

If you want to be considered a "project management superstar", this is the place where you want to be, not the esteem zone.
Even if, sincerely, my advice is always to provide the value that is required for a good management style, without artificially raising the stake.

Bottom line

Do not pretend to be a horse if you are a donkey and do not pretend to be a sheep if you are a lion. Play fair. Align the stakeholders’ perceptions to the value you are providing. Let the stakeholders decide if you are providing the value they expect from you, on real data basis and not on perceptions. In the long run, this will pay, no doubt about it.

Maybe they will not clap their hands at you, but sure enough, they will remember you when the next project is in sight.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Which are the agile project management's disruptive features?

Some years ago, an expert program manager told me that agile project management was like sex seen by teenagers. Everybody keep saying that he does it, just a few really do it, and almost anyone does it properly.

I do not know if this was a sentence of her own, or if she had read it somewhere. I can recall that such a judgment, at the time, had seemed to me a little bit too harsh. This before I got involved more deeply in agile methodologies. Now I think that she had been far too indulgent. 

In my experience, what many professionals seem to identify with agile methodologies are just iterative planning, light (or evanescent) documentation, and no strict prescriptions.

These beliefs are wrong. The listed characteristics do not exhaustively describe nor define agile project management. What these so-called agile advocates preach is flexibility, not agility and believe me, flexibility is the wardrobe of hell.

Iterative planning is a part of agile project management, but it also used in many methodologies and frameworks that have nothing in common with agile.

Documentation is so important in agile project management that it is mentioned in the agile manifesto. At the same time, a too cumbersome quantity of documents could be to the detriment of any project managed in whatsoever way.    

Many agile project management methodologies are extremely prescriptive and rigid. As an example, Scrum, one of the most known agile methodology used in software projects, prescribes the team to perform a stand-up meeting each day, like first thing in the morning. Not exactly flexible, do not you agree?

So, what are the characteristics of agile project management, that are disruptive, if compared to standard project management methodologies and framework?

The iron triangle

A project is normally subject to multiple constraints, of which the most famous are Time, Cost, and Scope.

Time, Cost, and Scope make up the so-called “Iron Triangle” and are used, and sometimes abused, as indicators of a project’s success. 

Personally, I believe that more constraints should be included and taken into account, in evaluating a project’s performances. Maybe this argument will be the subject of a future post. Nonetheless, Times, Cost, and Scope are a well-known trilogy in project management and often the only three tools that a project manager can leverage to control a project. 

The Iron Triangle can be deformed to accommodate for project changes or execution deviations from the referenced baselines.

In traditional project management, it is usual to modify Time and Cost as a first choice. Contracts define Scope strictly, and a change in Scope may result in endless and painful negotiations and litigations. 

Therefore, the situation is “fixed” Scope and “variable” Time and Cost. 

Agile methodologies choose an opposite approach.

Therefore, the situation is “fixed” Time, “fixed” Cost, and “variable” Scope.

Commas remind us that this is just one possible approach, that fixed and variable are not strict, and that changes in certain situations can affect all the given constraints.

Let me push this a little further. Agile methodologies are based on the concept of a variable Scope.

Changes in scope are the way in which agile methodologies try to maximize value for the customers, in response to projects’ uncertainty and ever-changing environments.

Scope creep

Changes in scope are the way in which agile methodologies try to maximize value for the customers, in response to projects’ uncertainty and ever-changing environments.

So is Agile project management the glorification of the ever-despised Scope Creep?

No. It is not.  It is not because Agile project management implies a change in perspective.

The scope does not change. The Scope evolves. 

Of course, the scope cannot be left growing out of control; Scope evolution must be continuously monitored and controlled, to ensure that it will provide the greatest value to the customer’s needs. 

To achieve this objective, it is imperative that 

• Customers actively participate in feature prioritizations with the team. Customer must be continuously and extensively involved in the project.
• Planning is iterative and frequent (2/4 weeks).

Servant leader and team accountability

The figure of the project manager is a little bit different in agile methodologies. The project manager assumes the role of a servant leader, who protects the team from interrupts and distractions, always trying to ease the team’s efforts, removing obstacles and solving problems.

The project manager is not the key decision maker since decision are made at the team level, and the whole group shares accountability for them. Some Agile methodology even refuse the term “project manager”. 

The team, not the project manager, is accountable for success or failure.

Relationships building within team members and the team and the customers are at the very core of every agile methodology.

Self-organizing team

From the two previous sections, it follows that an agile team must be self-organized.  

No manager say what each member have to do, nor when he/she has to do it. The team shares any organizational decision, with the project manager as a supervisor.

Obviously, there is the need to have good processes and practices in place, to avoid that this great possibility could lead to anarchy.

People

Not everyone has the characteristics needed to fit in an Agile team, so the construction and the development of a proper Agile team are quite difficult tasks.

We do not need superstars, we do not need people that want to emerge above the others, we just need comparable performers, with real and authentic aptitude to team playing.

A project, in Agile methodologies, is seen as a whole effort made by the team. Any member of the team can participate in any work package (even if agile practitioners do not love this term) and work on any deliverable.

Consequently, so-called “T people” must compose an agile team. 

That is to say, we need people highly qualified in a particular area, but capable (and willing) to participate in work packages even outside their specialization zone.

Conclusions

In this post, we have presented the characteristics that, as far as I am concerned, characterize Agile project management. 

Agile project management is not a silver bullet; it is well suited just for some kind of projects. 

Agile methodologies, in my opinion, tend to perform well on projects with some of these characteristics

•    Small size (Cost and Time)

•    Small teams (no more than 8/10 people)

•    Initial scope not clear

•    High uncertainty

•    Many risks in different areas

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Agile planning and the story points approach - Part 01

We begin with this post a series dedicated to the exploration of a well-known agile planning techniques. The story points estimation method.
In this post, we will introduce some fundamental concepts with the aid of a very simple example. In subsequent posts, we will dive a little more into depth, discussing why this approach works, exposing common pitfalls and, hopefully, answering some doubts.

Let us try a little experiment.

In the middle of a field, there are three swimming pools

• Swimming pool #1    2 meters long, 1 meter wide and 1 meter deep.
• Swimming pool #2    4 meters long, 1 meter wide and 1 meter deep.
• Swimming pool #3    3 meters long, 2 meters wide and 1 meter deep.

Imagine you have to empty all the three pools, one after the other, starting with the smaller pool and finishing with the bigger one, using just a bucket. Every time you pull a bucket of water out of a pool, you must pour it in a well, at one corner of the field. The bucket is known to bear a small defect that will slow down the tasks’ execution, without impeding it. You do not have any clue about what the defect is.

Could you give me an estimate of the time you will need to perform the three tasks?

No. You cannot.

You cannot, because I have not been fair to you. I deliberately have hidden some information that you would need, in order to construct a reliable estimation.

• You do not know how big the bucket is. It may be the size of a mug or as big as a gasoline tank.
• You do not know which the bucket’s defect is and how this will affect the tasks’ execution.
• You do not know how far the well is. You know that the well is at one corner of the field, but you ignore how big is the area. The field could be a 10x10 meters square, or it may be as big as a football court.

A guess about the tasks’ execution time would probably be so much erratic, or its standard deviation of such a magnitude, that the estimation itself would end up to be utterly useless.

Points instead of time

Let us work with what we have. 

We know that swimming pool #2 is twice the size of swimming pool #1, and that swimming pool #3 is three times the size of swimming pool #1. 

Defined X the time required to empty Swimming pool #1, we can state as 2X the time required to empty Swimming pool #2 and 3X the time required to empty Swimming pool #3.

Since we do not have any clue about the value of X, we drop it in our estimations. 

We define that 

• Emptying Swimming pool #1 (activity #1) is 1 a point activity.
• Emptying Swimming pool #2 (activity #2) is a 2 points activity.
• Emptying Swimming pool #3 (activity #3) is a 3 points activity.

Ok, but how much is a point? Velocity is the key

At this point, we can start emptying Swimming pool #1. I have decided to help you in the job. You do not have to thank me for this; I love emptying swimming pools with a broken bucket.

After a very hard work, we realize that the activity has taken us 1 day, or, that is equivalent, we have a velocity of 1 points/days. We can now estimate, using the concept of velocity, activity #1 to be a 2 days activity and activity #3 to be a 3 days activity.

Propagating and refining the estimation

The next day you start emptying Swimming pool #2. Yes, you. 

I feel a little sick and tired of buckets and water. After three days of hard work, you finish this activity too. It has taken longer than expected since I did not help you till the morning of the third day and that, probably, you felt a little tired from the previous days of hard work.

How long will take finish activity #3?
It had been initially estimated as a 3 days activity (3 points with a velocity of 1 points/days), but our velocity has changed. Using the last activity velocity (0.67 points/days), we can now re-estimate activity #3 as a 4.5 days activity. 

This approach may work, but I think it is not a good idea. I will help you in activity #3 and do not forget that tomorrow is Friday. We will have two days to rest. 

Let us estimate our velocity as the mean of the velocities achieved in the last two activities, obtaining a velocity of 0.83 points/days and an estimation of activity #3 ‘s duration of 3.5 days.

Conclusions

In a context of high uncertainty, estimate an activity’s duration could be a daunting task. We could do our best but sometimes, as Christopher Cross would say, it is not enough. An estimation would be so much erratic, or its standard deviation so wide, that the estimation itself would be completely useless.

Instead of guessing and correcting, we could rely on an agile project management concept. 

The concept is to estimate activities’ relative efforts, instead of activities’ absolute durations. 

Then, as the project progresses, we will be able to transform points into time, using performances achieved in previously accomplished activities.

The more we proceed in a project, the more the estimations of activities' durations become accurate, since averaging velocities smooth out particular events, which could have affected, positively or negatively, our performances.

Doubts

In this post, we have presented a widely used agile planning technique, the estimation of activities’ efforts by (story) points. We have introduced the approach by mean of a simple example, and we have investigated how it works.

In the next post of this series, we will talk about why this kind of approach works. We will go a little more in depth, removing some simplifications that I have introduced for the sake of simplicity. We will give evidence to some common pitfalls, and we will try to solve doubts that typically emerge when first approaching this technique.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Planning in a changing environment - Does it exist a perfect plan, and does it matter?

Which characteristics should a perfect project management plan possess?

Find an answer to the above question could be a very interesting intellectual exercise, but not very useful. Rather, I think that this activity would be a complete waste of time, not worth the effort. Do you know why?

Because I think it does not exist such a thing as a perfect plan, and even if it did, I won't be very much interested in it, because I would rather prefer a useful plan.

Project plans should be useful, not perfect.

So I believe that a far better question should be 

Which characteristics should a useful project management plan possess?

I mean, there are features that we all consider mandatory in a project management plan, but those features are there to make the plan useful, and not to make it perfect.

Precision vs. truthfulness

I think that we can all agree upon the fact that a plan should be precise to be useful. 

If a plan is too generic, it won't serve its primary purposes, which are planning, monitoring and controlling a project.

Unfortunately, the more a plan is precise, the less is probable; That is why a plan is a simplification of the reality and a single snapshot of many possible interactions within a changing environment.

So we come to a paradox. The more a plan is precise, the more it becomes useful, and the more it becomes false. The objective of a project manager is to find a good balance between accuracy and truth. Paraphrasing the famous statistician George E. P. Box about statistical models, we could say that all plans are false, but many are useful.

Figure 1.

Take a look at Figure 1.
The x-axis represents the plan’s accuracy (moving from the left to the right accuracy increases) and the y-axis the plan’s truthfulness (moving from the bottom to the top plausibility increases).
Each one of the 4 quadrants is divided into 3 zones. The green zones represent areas where the balance of accuracy and plausibility allows the creation of useful plans. The orange regions represent areas where the balance of precision and plausibility leads to the creation of not very useful plans or plans that are not worth the efforts. The red zones represent areas with impossible or absurd balances of accuracy and plausibility.
Let’s dive a little more in the graph and analyze in depth each one of the quadrants.

• (a) Plausibility is preferred to precision. This quadrant is the domain of agile project management methodologies. We have to be ready to integrate our plans frequently with new details and project insights. 
• (b) A plan that is accurate and plausible, this is the project management’s holy grail. 
• (c) Precision is preferred to plausibility. This quadrant is the domain of classic project management methodologies. We have to be ready to change our plans frequently. 
• (d) This is a very strange quadrant. Why should anyone create a project plan that is not accurate and, at the same time, not plausible? Let’s look with suspicion even the green zone.

A way to finding a reliable balance between precision and truthfulness is not to exceed a reasonable time horizon, beyond which planning is no more a process, but it becomes a gamble. This horizon is different from project to project, depending on organizational process assets, enterprise environmental factors, industry, technologies involved...
Fortunately, a project manager has many tools in his/her pocket to build useful and sound plans, like rolling wave planning, division into phases, Agile methodologies and so on.

Plans vs. Planning

In any case, even if we succeed in crafting a project management plan with a good balance between accuracy and truthfulness, we cannot forget that this is just a temporary win. Projects, as we remarked before, are living entities that try to survive in a hostile and imperfect world.
Helmuth von Moltke, chief of staff of the Prussian Army in the second part of the 19th century, known for his innovative methods, used to say that no plan survives contact with the enemy.

So we have to be prone to change our plans. Changes in project plans should never conflict with project charters or business cases. Nevertheless, in order to deliver great values as outcomes of our projects, we must be ready to change, to change quite often, and to change quick.
As a matter of fact, Helmuth von Moltke used also to say, probably as a compendium of the previous citation, that plans are nothing; planning is everything.
We need to shift our focus from the plan to the planning process. 

If it takes too long to adjust our planning documents, we cannot be as effective as we should. So it is not enough to plan accurately in a reasonable time horizon, we also need efficient planning processes running.

Conclusions

We definitively need plans for our projects, and we need to make them precise enough to be useful, but not so accurate to be remarkably unreal. We must be ready to go through well-suited change management's processes, whenever there is a need since planning is at least as important as plans themselves.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Are you sure that a project management software will solve all your problems?

Probably you won't guess it in these days but, centuries ago, I was a long hair guitar player, 70s rock estimator, Texas blues lover, Delta blues listener and guitar magazines reader.

Well...Not that much has changed over the years...except for the length of the hair and the time I devote to playing. 

Once, while reading an issue of one of my favourite guitar magazines, I came across an interview released by Joe Satriani, one very famous guitar hero back in those years. The interviewer asked him which of his guitars he would have saved, if given the opportunity, in case his studio would have been put on fire.

Joe, in a colorful way that only a rock guitar player would be allowed to, answered that he would have left all of its guitars to burn. He would have instead run for his hard disks, scores and notes. He said that every good luthier could build you a new guitar, what is unique and really precious, are your ideas.

I was astonished by this answer. 

Partly because, at that time, I silly believed that part of a guitarist’s skill was in his/her guitars (well...I could not be that bad...there must have been a kind of trick hidden somewhere...in a better guitar maybe...) and partly because I didn’t have enough money to buy myself the instruments I longed for.   

Getting older and (I hope) wiser, I now fully understand Joe’s words...and I have learned that they fit also in project management. 

That is, what is unique and really precious are your processes, your methodologies and your project management’s team skills, not the tools you use to enforce them.

Many time I have heard or I have been reported the sentence “We need a good project management software. We are experiencing troubles in our projects because we do not have an adequate instrument in place”. Well, the truth is that in many of those cases, problems would have been experienced even if the best possible project management software would have been provided. 

Do not fool yourself believing that part of a project manager’s skills are in the software he uses.

Any project management software worths just the methodology it helps to enforce.

There is no secret. If you have sound processes in place and an adequate project management methodology, you can manage a project even with a pencil and a notepad (obviously is an hyperbole...but I think it render the idea). At the contrary, if you have lousy processes and a poor methodology you would have trouble managing even the simplest of the projects, no matter what.

Having said that, obviously the presence of a project management software can noticeably speed up the management work...but just if the work to be done is crystal clear...and that is a consequence to have a well trained and expert project management team.

Let’s see it this way. Suppose we want to cultivate wheat on a 10 acres field. We could do a better and more efficient job using a modern piece of agricultural machinery, rather than an old plow towed by two oxen. This provided that we know how to properly plow the field, how to sow the wheat and when to harvest.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Reflections on leadership - Part 02

Success is a team play and great achievements are possible just through cooperation and trust.

I strongly believe in this statement and I keep on repeating it like it were a mantra. 

Today I would like to focus specifically on the part about trust.

Let’s try a little experiment

Let's pretend not to be in a big city in the middle of the twenty-first century, but in the middle of a wild jungle some thousand years ago. We are part of a tribe of hunters where farming and agriculture have not yet been adequately developed. Our hunting area is dangerously depleting and the lack of animal proteins is putting at risk the survival of our clan.

The only possible solution consists in an enlargement of our territory and a group of hunters, of which you are a part, will be forced to explore new areas, going well beyond the boundaries within which our tribe has lived until now. How do you feel about that?

Please, write on a piece of paper which are the three things you worry about most. 

The highway to extinction

Even if there are no rules and different people react differently to the same stimuli, chances are that in your list you have included, in the first positions, your beloved ones. 

Your children, your partner, your parents, especially if they are elders...in essence all the people that count on your presence and your care.

In the end you would take part to the expedition just the same, knowing that a failure could put at stake the entire clan survival, but probably you would not be able to commit at 100%. Too heavy would be the burden, to heavy knowing that someone you love could be negatively affected by your death. Probably all your team mates will experiment the same concerns and this could seriously jeopardize your mission and your tribe’s survival. 

A trustful environment leads towards evolution

This will be the outcome if you cannot trust that your community will take good care of the people you love the most. Because if you know that someone is going to help them in case something terrible will happen to you, if you know that they won’t be left alone, if you know that your clan will take good care of them...then you will be able to accomplish extraordinary deeds...and probably you will be destined to great achievements. 

Obviously not everyone survive the process. Casualties occur along the way. The bottom line is to have a team whose value is at least equal to the values of its members.

A trustful environment allow to follow the difficult path towards evolution, this was true 6000 years ago in the middle of a wild and hostile environment as today in our polished and sparkling towns. 

It could be objected that do exist subjects that do not conform to this behaviors. There are individuals that take giant risks without safety net (behavior leading sometimes to great evolutionary leaps) or that don't think to themselves as part of a community. That is true, but it is also true that you cannot rely on those behaviors because they are normally unpredictable and not sustainable in the long run.

A trustful environment transforms ordinary men into heroes

Projects are quite similar. If you nurture a trustful environment then your team mates will be capable to achieve extraordinary results, because they will be eager to take the extra risks that sometimes are required by evolution. They will try their best, because they will feel protected and supported, and you could count on a team whose value is greater than the values of its members. Because they will know that no one will be left behind. No matter what.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Milestones - Advice for beginners

Please, take a moment to look this very short video, just to introduce the topic of this post.
A project manager reminds a project's supplier the approaching of a milestone, that heavily depends from a work package assigned to the supplier’s team.
Probably you will have noticed by now what these people are doing. They are trying to enforce a milestone that had been set some weeks before. Just that they are not enforcing the milestone that they are thinking about. They are not enforcing the milestone “This year, at the middle of July”, whatever that means, “some work packages will be completed, including WP 121-A”. The milestone they are enforcing is "This year, in July, there will be big troubles".
Let alone the fact that months are not a unit of measure, since they have different lengths, and that the same month contains a different number of working days from one year to the other.
The real problem is that “The half of July” has not a shared meaning at all.

Should it be the 15th or the 16th, since July has 31 days? Should it be somewhere in the week that contains the 15th (or the 16th), since the indetermination of the milestone seems to call an equal indetermination? Should it be the tenth working day of July, since normally we have twenty working days in a month?
This sort of things leads inevitably to problems. It would not be nice gather the sponsor and the main stakeholders in a room one month in advance, just to discover two days before that the milestone will be inevitably missed.
And this is just when all the parts involved are negotiating in good faith. If someone is trying to use this carelessness fraudulently to get some advantage, like the case in our short introductory video, there will be even bigger troubles.
Lucky enough, this is a kind of mistake that the greatest part of project managers would not make...but it can happen.
Especially if you are managing a small project, using just internal resources with whom you feel you have a special relationship, maybe a friendship, and apparently documentation is not a big concern for anyone.
The bottom line is to be extremely precise in setting milestones. Always. No matter the project complexity and size, no matter if it is a project with just four team members and one of them is your brother.

Milestones are just moments in time and have no duration,  as a consequence they can be set with an extreme precision, a clock's precision. And they should. 15th of July is not a moment, is a time span, it has a duration and this could be confusing. When will your deliverables be ready ? In the morning, in time for the 4pm o’clock meeting with the sponsor or in the evening, just before everyone leaves the office and they are pretty much useless till the day after?
Set your milestones specifying calendar date and time in hours and minutes. This way everyone knows exactly what will be accomplished and when.
Otherwise…look at this other very short video to see with your eyes what the worst consequences could be…

Bye.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Output, Outcome and Benefit - Managing today to shape the future

One of the most interesting and fascinating themes in Prince2 project management approach is, for what I am concerned, the business case one.

I find extremely interesting the constant focus on the project's business case and the continued assessment of the project justification, viability, and sustainability.

Also, I have been so impressed by the distinction between Output, Outcome, and Benefit.

Figure 1.

Output Each specialist product that the project has to deliver, be it tangible or intangible. Outputs are commonly delivered after the project’s closure and sometimes even during the project’s life.

Outcome Results of the changes derived from the use of the project's specialist outputs by the users. Outcomes typically start to be achieved after the handover of the project's specialist products to users.

Benefit Measurable improvement resulting from an Outcome. If the outcome is perceived as a disadvantage, we are dealing with what is called a dis-benefit. Benefits generally start to be achieved after the Outcomes and (should) continue to be achieved for a time span planned in advance. Prince2 states the establishment of a specific plan that describes the methods and times to verify the achievement of the expected benefits.

In Figure 2 we can see a quantitative representation of the relationship between these three ideas. Obviously, the exact Outcomes/Benefits realization times heavily depend on the project’s characteristics and peculiarity. 

Figure 2.

Let’s make a simple example to better clarify this view.

The Buymybooks Limited is a small company that sells books via the internet. Orders are collected by means of their internet site but after the initial collecting phase, orders are printed and processed manually. Also, Buymybooks Limited does not have a software to manage its books warehouse.

Their sell and delivery processes are highly inefficient, resulting in delivery errors, high costs, high customers turnover, and progressive reduction in the market share.

To face this situation, the board of director has decided to introduce a management software system to manage the sale and delivery processes.

Output of the project will be an integrated software management system (orders and warehouse management). 

Outcome of the project will be an improvement of Buymybooks Limited sell and delivery processes efficiency.

Benefits of the project will be delivery errors reduction, smaller costs, higher profits and greater customers' fidelity.

So we can agree that there is need to pay a great deal of attention not only to the execution phase of a project but also to the design, support and closure phases. Furthermore, it is of utmost importance check the actual realization of benefits after the project closure. This action should be performed by program or corporate management as prescribed in the project’s documentation. 

As a consequence, I would advise to

1) Have a series of compatible and well-crafted benefits

This seems obvious, but it can be sometimes tricky. I have covered the topic in one old post. It has been conceived for project objectives, but it is well suited for project benefits too.

2) Do not just focus on the outputs delivery

Sometimes, is easy to focus just on output delivery and lose contact with project’s outcomes and benefits. It could happen if outputs are the only substantial point of contacts between the project and the team members (that sometimes ignore the big picture), or between the project and the external stakeholders. 

Also, it is not uncommon to rely just on outputs delivery to measure project’s completion or success.

3) Choose the best possible approach to maximize benefits

Since a significant part of the project’s value will be realized after project’s closure, take care, during project planning, in choosing the best possible project approach to maximize the expected benefits and not just the outputs production. 

In the same way, while drafting the business case, do not take into account just the specialist products realization and delivery costs. Keep an eye also on handover, maintenance and operational costs. 

Manage and execute the project thinking also to the desired outcomes and benefits, trying to increase the probability of success and to maximize their impact on business as usual. 

4) Close a project if it has been proved to be no more justified, viable and sustainable

A project is a mean to reach an objective and not an objective in itself. Stop investing in a project if it is not longer worth it, is not a failure. Honor to the project manager who conscientiously proposes an early closure of its project, out of respect for the corporate vision.

Keep on throwing money out of the window. That surely is a failure.

To keep track of some of this aspects, I suggest the use of two very simple tools.

benefits/benefits matrix (Useful for points 1 and 4)

The first one is a matrix on which all project benefits are listed in columns and rows, sorted by descending importance, from left to right and from top to bottom. Each benefit's importance is recorded near the benefit's code. You can find an example of the benefits/benefits matrix in Figure 3.

At the intersection of each row and column of the matrix, there is a symbol that explains the benefit's relationships. 

Figure 3.

The “+” sign represents a high degree of correlation between two benefits' viability. This bond leads to risky situations because there is a high probability to realize both the benefits (opportunity) or to miss them both (threat). 

The “-” sign accounts for a low consistency between two benefits. This bond leads to risky situations because the realization of one of the two benefit could jeopardize the achievability of the other one.
In the example depicted in Figure 3, the achievability of benefits B2 and B3 is correlated. Benefits B1 and B4 are not consistent, but the real problem is that benefits B2 and B4 are not consistent too and, as a consequence, also benefit B3 is jeopardized. So benefit B4 jeopardizes benefits B2 and B3, that are the most significant benefits of our project.

Especially if one or both the benefits are assessed as paramount, strong “+” or “-” relationships have to be dealt with the greatest attention by the project manager. 

if too much “+” and/or “-” relationships appear in the benefits/benefits matrix, it could be wiser TO conduct an additional analysis of the project's expected benefits and to reassess the project’s riskiness. 

If two benefits do not have specific relationships, the intersection between their columns and lines is left empty. Obviously, the matrix is symmetric by construction and the slashes on the main diagonal are inserted just for the sake of clarity.

Other symbols could be added to account for different relationships, even if I advise to keep things as simple as possible.

Even in this very simple form, this tool could help in identifying dangerous (-) or risky situations (+), and contribute to the definition of the project's objectives.

products/benefits matrix (Useful for points 2 and 3)

The second tool I want to present is a matrix on which all project products (outputs) are listed in rows and all project benefits are listed in columns. Benefits are sorted by descending importance from left to right. Each benefit’s importance is recorded near the benefit's code. You can find an example of the products/benefits matrix in Figure 4.

Figure 4.

Each intersection between a row (product) and a column (benefit) contains project's outcome's codes, and represents through which outcome a single product helps to achieve a benefit. The color code states the degree of importance of the product to the expected benefit's realization (e.g., red could mean high, orange average, and yellow low).

We can see, reading the matrix by columns, which product helps to achieve a benefit, and to which degree each product is necessary to this end.

In this way, we can maintain a constant focus not only on project’s outputs but also on project’s benefits, through project’s outcomes.

If we are forced to drop out a product, we can immediately see which benefits are at stake, their importance for the project and how much they are at risk. It is a simple way to depict the effect of a project scope modification on the project benefits.

In the same way, if we decide to sacrifice a benefit, we can immediately evaluate if there should also be a project’s scope modification.

If you feel like to read some suggestion on how to assign importance values to project benefits, please refer to this post. It has been conceived to suggest how to assign qualitative values of impact and probability to project risks, but I think that the content is perfectly adaptable to the current problem.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Are your processes fair enough?

Let me play a little game with you, just to introduce the subject of this post.

I am a project manager and you are a member of the project team. 

I have put in place all sorts of management processes and I have bound team members bonuses and prizes to the outcomes of these processes.

This is one process that I put in place and that now you will have to apply.

Your quarterly bonus depends on the fact that I will consider reasonable and satisfying the outcome of the process.

Follow this process. You can use a piece of paper and a pen.

1. Choose a number between 1 and 9. write it on the piece of paper.
2. Double it.
3. Add 8 to the result obtained in point 2.
4. Divide by 2 the result obtained in point 3.
5. Subtract your original number from the result obtained in point 4 and write the result on the piece of paper. 
6. Convert the result from point 5 into a letter in the English alphabet (es A=1, B=2, C=3,...)
7. Choose a U.S.A. state whose name begin with the letter you have found.
8. Add 1 to the result obtained in point 5 and write the result on the piece of paper. 
9. Convert the result in point 7 to a letter with the same method you have used in point 6.
10. Choose the biggest animal you can think about whose name start with the letter you have found.

Now...well...I am very very very disappointed from your performance.

there are no elephants in Delaware...very unsatisfying... you can kiss goodbye your quarterly bonus.

Are you disappointed? I think you are. You have plenty of reason to be disappointed.
Many mistakes have been made in implementing this process, but we will focus on what I judge to be the worst four.

Give measurable targets

At the beginning of the post I wrote that I would have granted you a bonus if, and only if, I would had found “reasonable and satisfying the outcome of the process”.

So? What is this supposed to mean? Nothing.

If you put in place a project management process and you bind your team members bonuses and prizes to the outcome, be sure to give measurable objectives.

Otherwise every denied bonus will be seen as an arbitrary punishment and every granted bonus as an unjustified gift. Each case you will be experimenting a sudden collapse of trust among your team members.

Give team members a chance to influence the outcomes they are evaluated against to

You had no control on the output of the process that I put in place and that I forced you to follow.

Every input you would have given would have led you to the same result. So what is the point in binding your bonuses on that? 

Again, as in the previous point, every denied bonus will be seen as an arbitrary punishment and every granted bonus as an unjustified gift. You will be experimenting a steady collapse of trust in the team and you will grow harsh criticism about every step the management will take. Discontent will spread.

Always perform a sanity check of your processes

The process that I forced you to follow was corrupted (How could I possibly knew your answer otherwise...). Look at the equation you have implemented following my process

1. Chose a number between 1 and 9. write it on the piece of paper. Let’s say the number you chose is X and the result you obtained is Y.
2. Double it. Ok, now you have Y=2X.
3. Add 8 to the result obtained in point 2. Here we obtain Y=2X+8.
4. Divide by 2 the result obtained in point 3. Now Y=(2x+8)/2=X+4.
5. Subtract your original number from the result obtained in point 4 and write the result on the piece of paper. Y=X+4-X=4.
6. Convert the result from point 5 into a letter in the English alphabet (es A=1, B=2, C=3,...). The letter you got was D.
7. Choose a U.S.A. state whose name begin with the letter you have found. There is only 1 U.S.A. state whose name starts with D. Delaware.
8. Add 1 to the result obtained in point 5 and write the result on the piece of paper. The number you got was 5.
9. Convert the result from point 7 to a letter with the same method you have used in point 6. The letter you got was E.
10. Choose the biggest animal you can think about whose name start with the letter you have found. Elephant is a good choice.

If you put in place a project management process and you bind your team members bonuses and prizes to the outcome, be sure that your process is flawless.

Otherwise two things could happen

• Your team members will not follow your process, because they want achieve their bonuses and prizes and because your process outcomes go to detriment of the project.
• Your team members will follow your process and contextually will experience a lot of frustration. You are sure to have an high degree of disengagement...and probably a lot of elephants in Delaware.

Either cases lead to the same result.

The project will rapidly go out of control and disappointment will spread among all of your stakeholders.

Always check that your processes are fair

Make another little experiment. Buy a cookies box and tomorrow morning, as soon as you enter the office, gather three of your collegues and offer them some cookies. You will offer four cookies to two of them and you will say to the third one that he/she can take just one cookie.

Chances are that the third collegue will ask you why he/she can get just one cookie.

There is no point in asking, since cookies are yours and you do not owe nothing to your collegues. You can share your cookies if you want to and decide freely how many cookies offer to whoever you want but still, the third collegue will ask you about it, maybe laughing, but he/she will ask. Maybe even the other two collegues will enquiry you about your behavior. And you know why?

Beacuse deep inside they feel that your process is unfair. Even if they have been prized in this occasion, they know that they cannot trust your process. They know that they cannot trust you.

My point is to always check that your processes are fair.

People can stand almost every situation and deprivation, but just if they feel that the processes are fair.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Stakeholders management - A human touch

In my last post I dealt with the stakeholder register, I described its importance in project management activities and offered some suggestions for its filling.

stakeholders identification processes are of the greatest importance for a project and so are stakeholders information gathering activities, though this is just the starting point for effective stakeholders management.

In the following of the post I will give just some tips (or I should say some crumbs)  to avoid that everything become too unbalanced towards the documentation part, casting a shadow on the human aspect of these processes.

It is not I and them but us

Usually many of your stakeholders belong to your professional network and in many cases, well, they are your professional network.

Therefore it is extremely important the protection of your relationships and an effective management of their expectations. 

There will come the time in which, as a project manager, you will need your stakeholders help, support  and contribution to deliver succesfully your project.

Try to build and mantain loyal relationships with them through sincerity, sense of belonging, trust, consistency of performance, … relationships that go far beyond reciprocal satisfaction.

Relationships based on reciprocal satisfaction are about what they can do for you, or what you can do for them, if you see it the other way round.

A relationship based on loyalty is about what you can build together.

I have found extremely inspiring about loyal relationships a speech given by James Kane that I attended to the last PMI North America Global congress and this book by Simon Sinek.

  

They are individuals

They are individuals not just entries in a dedicated register. Group them together according to some criterion is definitely useful and convenient for generic project management activities, but this is just a modelization of reality. 

They are not a group. They do not want to be a group. They want to be individuals and they deserve to be treated like that. They are men and women with their complexities, beliefs, needs and expectations.

So respect their individualities. There is not such a thing like one size fits all stakeholder management and communication.

They are not sheep to graze nor cows to milk

They are people that can add great value to your project and all you have to do is listen to them (well...maybe it is a little more difficult than that...but this is a good start). Help them to express their potential, help them to enrich your project with their contributions and work together to build something unique.

Manage expectations and manage requirements are not the same sport

Managing requirements is about incorporate some characteristics in project deliverables.

Managing expectations has a far more broader meaning. It is about deliver to stakeholders the benefits they expect through project deliverables. This obviously has a lot to do also with your stakeholders needs understanding, project insight and vision, as I pointed in this my old post. 

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.