Is creativity generated by partial disagreement in a team?

The four stages of a team

Every new team is bound to pass through four main stages before reaching what we could call a "productive maturity", namely Forming, Storming, Norming, and Performing.

Forming

Forming is the first stage of a team when people are selected and assigned. Team members start to know each other, usually in a low-engagement and low-trust environment. The stage is characterized by an artificially quiet mood, and people do not enter spontaneously into heated (and sometimes productive) debates. 

Storming

Storming is the second stage of a team. Now heated discussion starts to happen and people begin to get hurt by each others edges. 

It may appear a paradox but the storming phase is when the members of the team lay the foundation of trust. People are keen to confront each other openly just when they start to feel trusted and safe in the environment in which they work.

Storming is also a very delicate phase; if clumsily managed, the team may never be able to get to the next step, remaining stuck in an endless Forming purgatory.

Norming

Trust is established, safety validated, and people start to work together as a team. There is again some gray area to be explored, and some boundary have not been trespassed yet but results start rolling in with consistency.

Performing

The team is in its "productive maturity", and performances are consistently maintained. 

And then...What happens next?

In many cases, we can observe a kind of "performance plateau".

Throughput does not increase with time anymore, rather, it can decrease slowly but steadily.

Non-professional relationships strengthen, empathy increases, complicity gets in the way, and the team lacks the healthy level of antagonism which allows creativity to thrive.

Can too much harmony kill creativity and conscientiousness? 

It may seem so.

How can good performances be maintained in the long run?

The project manager shall keep alive the professional pride which allows excellency. It can be done in several ways

• Turnover If possible, let new professionals enter the team. The suggested approach will force the team to step back a little from its evolution plateau. My advice is to carefully select the new members of the team and not to exceed the number of new entries, otherwise, the team may run the risk to step back into the Storming phase.
• Training Push the members of the team to take training on project related topics. Moreover, encourage them to give presentations about their new competencies to other members of the team. The approach will stimulate good competition and, as a side effect, will benefit the project itself.
• Manage Conflict Do not suffocate conflicts, let them flare in a controlled and safe environment. Responsible and effective conflict management is the key to a team's cohesion. Please refer to my previous posts (Link1, Link2) on the topic.
  Also, I suggest reading the great book "The Five Dysfunctions of a Team" by Patrick Lencioni.
• Gamification Introduce gamification in some of the activities of the team, replicating in the work environment the very exact stimuli that keep people motivated in playing games.

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

Practical Earned Value Management

Introduction

The Earned Value Management (EVM) is a well-known and widely used technique, to monitor and control the budget of a project.

Since there are a lot of good books and posts about the theoretical approach to EVM, we will walk through it following an applicative perspective. The followed approach will enable us to apply EVM concepts to real situations, right from the beginning. 

Let's consider the budget/cost situation of a project, as shown in Figure 1.
What can we say about the project's performance? Are we happy with it?

Figure 1. budget/cost situation of a project.

The truth is, simply we do not know. 

We do not even have a clue about the performances of the project, because we lack an essential dimension, other than Time and Money. We lack the percentage of scope implemented at any point in time.

Taking a look at Figure 1, we can clearly understand if we are ahead or behind the budget, but what about the schedule?

Point #1

We are underspending, which is good...but how about the deliverables completed so far? What about the schedule? We are spending, let's say, 40% less than expected, but maybe we just have delivered 15% of the planned scope.

Point #2

We are behind the budget, which is not good...but maybe we already have delivered 95% of the scope, and we are dramatically ahead of schedule.

Point #3

Ok, we saved some money, but have we delivered everything we were supposed to produce?

EVM comes into play to answer the questions raised in the previous points.

The Method

First, let's introduce a little bit of jargon. I know, it is a bit annoying but EVM, for historical reason, uses the terminology of its own to define standard variables.

Planned Value (PV)

The budget of the project. Budget is called PV in EVM techniques, to stress the idea that it represents the quantity of money we plan to have spent up to a precise moment of the project.

Actual Costs (AC)

The quantity of money spent so far in the project.

Earned Value (EV)

Earned Value is the dimension we lacked in Figure 1, that is to say, the value generated from the project up to a specific moment. We could also define EV as the budgeted cost of the work performed so far.

Figure 2. EVM.

The correct determination of the EV can be a little tricky; it is usually evaluated as the sum of the figures of the budget forecasted for the generation of the completed deliverables. The budget for partially completed deliverables may be counted in using an estimated percentage of completion. The effort for not directly measurable activities may be considered in the evaluation using an apportioned effort approach. 
We will come back more in detail to the topic in a future post of this series.

Obviously, EV at completion is by definition the budget of the project.

If scope is added or removed, the budget is modified to reflect the changes.

The assumption made here is that our budget is a meaningful figure and that the efforts for the comprised activities have been estimated reasonably well.

In any case, EVM technique gives us tools to prove the truthfulness of our assumptions, and to remodel the budget during the project's execution. 

Coming back to our previous example, we can now say more about the project's performance.

Point #1

We were underspending, and we completed more scope than expected. That's very good; ahead of budget and ahead of schedule.

Point #2

We were behind the budget but still ahead of schedule. Not bad, even if, in a situation like this one, there is the possibility to incur in a cash-flow problem for the project, if not enough funds had been allocated by the time.

Point #3

On schedule and ahead of budget. What else?

In the next post of the series, we will show how to use EV, AC, and PV to keep the project under control.

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

Agile Projects & Lazy Contracts

Here is my speech about Agile Project Management and contracts at the Torino Agile Conference 2018.

The video is in Italian but slides are in English.

Agile projects & Lazy Contracts from Emanuele Passera

Enjoy and feel free to contact me for feedback, advices, questions, or just to say hello. 

Impact Mapping - How to Map Requirements to Business Value

Impact Mapping is a goal-oriented requirements practice, largely described in the book Impact Mapping - Making a Big Impact With Software Product and Projects by Gojko Adzic, on which this post is based.

Do not be deceived by the title of the book; the Impact Mapping technique can be applied proficiently to all kind of projects, in different industries.

The idea is that each deliverable in a project should be graphically linked to a well-defined business objective, which shall be achieved through the impact users will create by using the deliverable itself. 

The graphic representation is considered paramount, in order to clarify links that may be well defined just in the back of the mind of an executive and to show assumptions that may benefit from some investigation.

I believe Impact Mapping to be very close to the Prince2 view of "Outputs", "Outcomes", and "Benefits". So I recommend considering the Impact Mapping approach when using Prince2 Methodology.

Steps

1. Choose the Objective

To start creating an Impact Map, you shall begin fixing a business objective in the main node of a standard mental map. 

As an example, we could start with the objective "Increase our quarter sales of product A by a 10%".

Obviously, remember to consider just SMART objectives, to be able to create real value.

2. Identify Who 

The second step in creating an Impact Map is to identify key people that will help you to reach the objective. Basically they are internal and external stakeholders of the project, who will create the impact you need to achieve the goal.

Referring to the fictional objective stated in the previous paragraph, we could identify "Salespersons", "Marketing", "Retailers", and, obviously, "Customers". 

The ability of the stakeholders to create an impact through the utilization of the deliverable(s) is paramount. If stakeholders cannot produce the expected impact, the purpose is defeated.

3. Identify How

The third step consists in defining how the identified key people can make the impact we need.

Referring to the previous example, "Salespersons" could increase the frequency of their contacts with the customers, "Marketing" could start a new campaign on social networks, "Retailers" could promote our products in more efficient ways, and so on. Obviously, more than one "How" should be identified for each "Who". 

Pay attention to this point because it can be a little tricky. The definition of "How" is hard-wired with some assumptions. We assume that key stakeholders are able or willing to create the impact we need. Such assumptions must be continuously checked and validated and, if proved to be false, requirements dropped.

4. Identify What

The last step is to identify what we can do to enable stakeholders to create the impact we want from them. 

Coming back to our example, we could deploy a more sophisticated CRM to help "Salespersons" achieving greater efficiency, allocate some budget for a marketing campaign, and implement a bonus-based engagement program for "Retailers". 

When creating the map, I recommend a kind of brainstorming approach. Create a comprehensive map to start, and then prune the tree, removing redundant branches or parts not well sustained by solid business reasons. 

Moreover, compare Impact Maps with different central objectives, to find requirements that support more than one business goal. Search for synergies between business objectives, remove useless paths, enforce multi-purpose requirements, and remove duplicates. 

Benefits 

There are several benefits achievable by using a goal-oriented requirements practice, such as Impact Mapping. 

• Every requirement is strictly connected to a business case, so, If we drop the business case, or if we prove it to be no more valid, we can drop the feature itself.
• If a business case is already well-addressed by enough features, we can drop some requirements and invest in other areas of the project.
• Scope creek avoidance. The scope is controlled following a quantitative logic, so it is very difficult for pet-features to sneak in.

For a better insight in the technique, I recommend you to read the book, Impact Mapping - Making a Big Impact With Software Product and Projects by Gojko Adzic, which contains some very good points and insight in project management. 

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