Deliver soon and frequently - an Agile approach to planning

My family and I, live in a minuscule Italian country town. We are lucky enough to inhabit a house surrounded by a private garden, in which our kids can safely play. Our sons are seven and four years old. 

As a side effect, my house is often crowded with children from April to October. In some particular occasion, as birthdays, I have personally counted more than 20 children playing around.

The “Sandwich” project

So, let us imagine preparing sandwiches for 20 kids, following a waterfall approach

• Ask each child what kind of sandwich he/she would prefer (initiation - requirements gathering).
• Put all the needed ingredients on the kitchen table (planning).
• Lay on the table 20 slices of bread (executing).
• Cover the bread slices with the selected sausages (executing).
• Add the selected type of ham (executing).
• Add to each sandwich a cheese’s slice (executing).
• Complete the sandwiches with the upper slices of bread (executing).
• Deliver the sandwiches to your stakeholders (closing - delivery).

The kind of approach described in the previous paragraph is probably the most efficient and organized, to manage the “Sandwich” project.

What is wrong?

If you think that this could work, you probably have never had to deal with third-grade kids. At least not with 20 of them in a bunch. 

When you are ready to enter the executing phase, requirements will start to change. Kids will start thinking that they would prefer other types of sandwich, instead of the one they chose; this typically goes on to the delivery phase.

In addition, as soon as you start to deliver your outputs (the sandwiches) to your stakeholder (the kids), they will begin complaining about the sandwich they chose.

Probably a great part of them will begin asking for the same kind of sandwiches selected by their best friends.

It is a kind of nightmare. 

You will be bound to deal continuously with scraps, rework, out of specifications…and to eat yourself for dinner a good share of your products.

How can agile help?

The answer is easy. 

Start delivering soon, and deliver frequently. 

The fast delivery of finished outputs, at the end of short execution cycles, is a disruptive characteristic of agile project management, as we have seen in an old post. The fast and continuous delivery approach can easily cope with projects, or work packages, in which requirements are not clear or bound to change frequently.

The key here is not to plan recursively; the key is to plan recursively and to deliver, at the end of each cycle, completed outputs, or partial outputs with newly completed functionalities. The focus here is to have, at the end of each execution period, something ready to be immediately delivered to production.

The “Sandwich” project in an agile framework

As an example, let us add a little agility to the “Sandwich” project

• Ask each kid which kind of sandwich he/she would prefer (initiation - requirements gathering).
• Put all the needed ingredients on the kitchen table (planning).
• Start the first delivery cycle
• Lay on the table 1 slices of bread (executing).
• Cover the bread slice with the selected sausage (executing).
• Add the selected type of ham (executing).
• Add to the sandwich a cheese’s slice (executing).
• Complete the sandwich with the upper slices of bread (executing).
• Deliver the sandwich to your stakeholder (delivery).
• Listen to feedbacks (planning).
• Start a new delivery cycle. 

This approach may be a little more time consuming, but in an environment plagued by uncertainty and requirements changes, will deliver the maximum benefits, minimizing the wastes.

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

Acceptance criteria. A real life example.

Once, while travelling for business, I spent a couple of days in one of the most famous Italian art city. My staying was limited to a single night; anyhow my company booked me a 4 stars hotel. I knew that hotel classification in Italy goes to 1 to 5 stars. Therefore, I was more than pleased with the accommodation.

When I arrived at the hotel, I was a little bit puzzled. I genuinely thought to have entered through the wrong door. The hall was disordered and gloomy, crowded with horrible knick-knacks and decorated with cheap paintings. The walls would have greatly benefited from a new coat of paint. Many couches, scattered around with no evident purpose, impeded the way toward the hotel’s bar, who, in turn, seemed to have run out of every kind of international drink.

The elevator would have been more at its place in a warehouse than in a high standard hotel. My room was a mix of heterogeneous old cheap furniture, and there were no tents on the window. The television was a very old and economic model of an unknown brand. The bathroom was small, without windows and enlightened by an undersized fluorescent lamp. There was a problem with the shower's hot water tap, and the sink drain was not working very well. The room was very clean, I have to admit it, But I consider this a prerogative more than a feature.

Obviously, my company had no fault, since they have based the hotel's choice on the high rating. 

I had to stay for just one night, and my schedule was very tight, so there was no point in searching another accommodation. Besides I can adapt myself to far worst situations than that.

Still, once at home, I remained with the curiosity to understand how such a terrible hotel could have been rated 4 stars out of 5.

So I searched for and eventually found on the internet the last Italian national regulation in matter of hotels rating. I read it…and finally understood. 

I won’t report the entire normative; I will just give some examples of characteristics that a room of a 4 stars hotel must possess in Italy.

Double Room

• Surface of at least 15 squared meters.
• Private bathroom (surface at least 4 square meters).
• 1 double Bed, 2 bedside tables, 2 chairs, 1 small table, 1 armchair, 1 wardrobe, 1 mirror, 1 wastepaper basket, 2 bedside lamps, 1 stool.
• Satellite television.
• Phone and internet connection.
• Safe.
• Mini bar.
• …

As I have previously reported, these are just a few excerpts from the normative, but I think that you will have got my point by now. 

We have a list of requirements…but how about their acceptance criteria and quality constraints?

We have prescriptions about the rooms' size and the number and the kind of necessary furniture pieces...but nothing about their quality, their age, their aspect.

There must be 2 chairs in the room, and they can be different. One of them could even be a plastic garden chair, for what concerns the normative.

The requirement about the television could be equally satisfied by a plasma monitor 65 inches wide or by an old 13 inches CRT. It is not even mandatory that television is equal in all rooms.

The list could continue.

I understand clearly now that the hotel in which I have been is, without any doubt, a 4 stars hotel. 

The lesson I learnt on that occasion is that quality is the essence of a project and that requirements and deliverables without quality and acceptance criteria, are almost useless and deceptive. More precisely, a lack of care in registering quality and acceptance criteria for each requirement or deliverable, could seriously impede the project execution, raising an abnormal quantity of quality issues. This situation will inevitably have a huge impact on the project constraints and stakeholders satisfaction.

Please take a look at Figure 3.

Figure 3.

On the horizontal axis, a qualitative representation of the delivered quality can be found, while on the vertical axis there is a qualitative representation of the expected quality. 

The violet line is the locus of point for which the delivered quality is equal to the expected one. 

Under the violet line, there is what I call the “waste area”, a zone where the delivered quality exceeds, without purpose, the quality expected by the project’s stakeholders. A project manager, who get caught in the “waste area”, is probably wasting resources that could be saved or used more profitably elsewhere. A long permanence in this area could lead to constraints issues.

Above the violet line, there is what I call the “disappointment area”, a zone where the delivered quality is below the quality expected by the project’s stakeholders. A long permanence in this area could lead to rework, quality issues and, more generally, to problem in getting along with the project’s stakeholders.

In both cases, the implications and repercussions of a project manager’s deviation from the violet line are obviously proportional to the deviance's magnitude.

Inside the dotted rectangle, there is what I call the “safe area”, that is the locus of point for whom the delivered and expected quality, although not alike, can be considered satisfactory from all the project’s stakeholders. This area is generated by registering quality and acceptance criteria for each requirement and/or deliverable. It is a zone where the project manager can safely exchange quality with satisfaction, causing no harm. Understanding clearly the “safe area” position and extension can prevent a lot of problems and incomprehension or, in the worst cases, it can help the project manager in foreseeing them and in dealing with them.

Please, note that if criteria have not been registered, the “safe area” still exists, only that in this case there is no accordance about its extension and its position in the graph by all the project’s stakeholders.

A project manager must, of course, pay close attention to the fact that the acceptance and quality criteria be quantitative and measurable. Otherwise, they could be useless and deceptive too.  

So, every time you collect or express a requirement for a project, please be careful. Pay great attention to the quality of your solutions.

Otherwise, you could end up delivering an old 13 inches CRT instead of the new plasma screen expected by your stakeholders, or a Luigi XVI sofa where a plastic garden chair would have done the job.

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

Are your project objectives S.M.A.R.T. enough?

I love acronyms.

I have always considered acronyms as incredibly shrewd and useful tools, for communicating and for remembering complex concepts in a simple and effective way.

In this post i will focus on one acronym that I came across the first time while studying Prince2 and that, as often happens, I then met again several times in the following days, even if slightly modified.

The acronym is S.M.A.R.T. and, related to project objectives, stands for Specific, Measurable, Achievable, Realistic, and Time Bound.

Honestly, I have to say that there seems to be no universal agreement on the words whose initials make up this acronym, as you can see by following this link. However, the version presented here is the one that I find more congenial and useful to my needs.

Specific

How could you hit a target, if you do not know where the target is? Or worst, how could you hit it, if you do not even know what the target looks like? In the same way you cannot achieve a objective if you do not provide (or if you have not been provided with) a clear description of the objective itself.

It seems obvious, I think that everyone would agree with the previous statement...but please keep in mind that defining specific objectives for a project is not an easy task.

To state or analyze a clear and well crafted business case, considering all present and future developments, benefits and advantages, requires both great project insight and business vision. You could need the aid of a business analyst and, possibly, great support from your corporate management.

If you have been provided with project documentation, in the form of a charter or of a project brief, take your time to examine it carefully and request clarifications wherever necessary.

Never get tired to inquiring your project's documents because, you know, the devil is in the details.

I believe that not to specify clearly project objectives is not a smart (and obviously not a S.M.A.R.T.) shortcut but the highway to failure.

Measurable

All the objectives must be measurable. Period. Always. Period.

If you do not have measurable objectives, it will be impossible to determine if you have been successful or not. It will also be impossible to determine the degree to which the project has fulfilled its expectations.

Also as you might rationally decide to terminate or to continue the project, if you do not have precise targets to measure progress? How could you reassess  the business case? This could result in a massive expenditure of money without proper justification. Also, if you haven’t properly quantified your objectives, it is consequently impossible to determine their risk exposition and, as a consequence, it is impossible to determine the project’s risk exposition. No good. Believe me. 

The problem here is to find proper ways to measure objectives.

Even this one can be a daunting task, depending on the particular industry you are in.

It is easy to measure the number of defective pieces of equipment coming out from a production line, or the lifetime of a new electric bulb. It is more difficult when it comes to customer satisfaction, software quality, reputation improvement, products quality improvement...In these cases an indirect measure could do the job.

As an example you could measure the number of contacts of your customer service  and put it in relation with an improvement or a worsening of your products.

The bottom line is: everything can be measured, the problem is to identify suitable measurement units. It is a complex problem but is a problem that can be and must be solved.

Achievable

Some objectives just do not go well together. They seem to live in orthogonal dimensions.

Sometimes it seems that a complete scope, a fast time to market, a low budget and an high quality standards mix well...as oil and water.

So take care in having an achievable and consistent set of objectives. If it is not the case, try to reconcile reality with management's desires and expectations.

Never start a project that has not achievable objectives, pretending that everything is just fine and thinking ahead how to justify the unavoidable failure or below average performance.

Realistic

Everyone would like to be in charge of the next multi-billion dollars, thousands resources, hundred contracts project, with all the whistles and bells. Reality is, many times, different. 

The project manager’s duty is to reconcile budget, time, scope, quality and all the other constraints into a shared and satisfying vision, be he/she in charge of a mega project or working in small businesses. The duties of a project manager toward the sponsor and the stakeholders do not change with budget’s size. Again, he/she must reconcile reality with management desires and expectations and must resist the temptation to artificially raise the bar in order to magnify its own role.

Time Bound

Every project should have a starting date and an ending date. Every objective should be achieved in the defined timeframe. Benefits could be achieved later on but a time span have to be defined as well.

This is an important commitment for a project manager.

So there is no point in defining objectives that cannot be achieved in the project timeframe or in the expected time for benefits realization, once project products are released in the operation environment.

Otherwise, an attitude of this kind could frustrate team members, create distrust in corporate management and alienate stakeholders. 

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.

If I had asked people what they wanted...they would have expressed a requirement

Henry Ford is supposed to have said once

“If I had asked people what they wanted, they would have said faster horses”.

It is not really important if he had said this sentence for true, as is not very important the context in which this sentence would have been said.

What really matters is that many project managers, from time to time,  feel like saying that about their stakeholders. Such a statement implies two things

• A lack of trust in the stakeholders' insight and vision of the project.
• A lack of trust in the stakeholders' capability to express solid requirements.

This attitude could potentially lead to grave consequences in the long run, like stakeholders disengagement and failure in managing stakeholders' expectations.

The funny thing is that many times it is true.

Stakeholders do have limited insight into the project and yes, sometimes, they are not able to express requirements efficiently.

This lack of clarity is because they look at particular aspects of the project and not to the project as a whole.

In fact, they rely on project managers for activities such as the gathering of requirements, the definition of the scope, integration...

It is a project manager duty to provide the right degree of expertise, insight, and vision on the project. It is a project manager obligation managing stakeholders expectations and distilling requirements from necessities.

As Michelangelo Buonarroti wrote

"Non ha l'ottimo artista alcun concetto 

ch'un marmo solo in sé non circoscriva

col suo soverchio, e solo a quello arriva

la man che ubbidisce all'intelletto."

That is to say that the statue lives inside the marble block; the artist just removes the excess.

The sentence “If I had asked people what they wanted, they would have said faster horses” is an expression of a necessity that hides an implicit requirement.
The requirement is the need for a faster and more reliable transport.

Understand the best way to satisfy this requirement, respectful of the project's constraints, is a part of our job.

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