Management, MBA, Project Management, Projects

Mirror, mirror… (Project shadow management)

The average project manager is affected by all sorts of diseases. One of the worst, that could be labelled as project manager’s myopia, in line with other sectoral diseases like manager’s myopia (that is related to perfectly managing something that should not be done at all) or marketeers’ myopia (when we further seek perfection to our product, to an extent that our customers do not demand neither understand or value).

Project manager’s myopia is something similar to paranoia, albeit in a much lesser way. There are some symptoms to be aware of:

  • Reality denial, we still are working as if things were like they used to be,
  • Reality avoidance, skipping focus on the symptoms of change,
  • Deflection, blaming change on others or seeking scapegoats that temporally justify mismatches,
  • Projection, attributing one’s feelings to other people, we have this disconnection because of someone else,
  • Splitting and radicalism, there are final groupings into good and bad things, good and bad people, good and bad customers… greys tend to converge into black and white only
  • Somatisation, in late stages people can even become ill to avoid facing reality

Ok, those are extremes, but what is it that usually happens?

Sometimes we simply focus so much on a project’s completion and success that we tend to forget that projects are not isolated realities but that they are inserted into organisations. With time our big project is able to evolve and change. This is something that we can naturally accept and live with. In fact we need a big dose of flexibility when driving our project through execution, when risks are being faced and decisions being made.

But the project is not the only thing that is about to change through its lifetime. The organisational reality in which it must fit is going to change also. A change that can even be induced or catalysed by means of the project that we are taking care of.

And what do we do in the face of change? First we still keep the serious intention of managing the match, usually following a stakeholder model like this one:

This stakeholder matrix represents the main groups of stakeholders, or people that have a say, that we have to manage. They are divided in four groups related to the power and influence they have and their importance (or stake):

Stakeholder Management
Low Importance High Importance
High Influence Keep Satisfied Manage Closely
Low Influence Monitor (minimal effort) Keep Informed

Those are reasonable and wise words but, in the end, when the project has overcome the frustration and hysteria phases, we are so focused on the final deliveries that we tend to forget about stakeholders at all. And then the mismatch occurs and blows up on our faces. That’s when the aforementioned symptoms start to occur.

There’s another model that I especially like. Made by Holland and Skarke, projects the need for change with an additional dimension: time.

The model is taken from an article focused on IT and organisational alignment, but it’s also applicable in many other contexts. It says clearly that we must be manage two projects at the same time:

  • Getting the system ready for the users, our main goal or the project that we are struggling to manage to completion
  • Getting the users ready for the system, the often overlooked part.

Getting the users ready for the system will entail much more than the simple stakeholder engagement described with the classical approach. In information systems will be related to the user acceptance processes that we know should be analysed and managed, but in many other contexts, user acceptance must not be taken for granted. The users must be ready for the new infrastructure, and that means that they must not only know about it, but about the benefits it entails for their work processes, the alignment with their own personal and organisational objectives and the motivation to learn to use, and effectively use them.

Only this way we will be able to quickly climb the productivity drop in the adaptation curve, and only this way we will be able to adapt the deliverables to what the organisation expect: actively managing both ends of the final acceptance bargain.

b-school, Management, MBA, Project Management, Projects

Under-promise and overachieve (the expectations model)

One of the things that happen to often in program management is that contractors, specifically their project managers, want to be too nice. Yes, of course they must be nice, but not that nice.

I’m not talking of nice presents or sumptuous dinners. I’m talking of making too much promises. Well, it’s understandable when you don’t have the contract but, once you have it, it’s a most annoying practice.

Reality is stubborn, bull-headed, disobedient, especially to the wishes of a project manager. It’s not her but her team who is really doing the hard work and, as they try to please her, they will tell her whatever she wants to hear… until the milestones get closer and the completion gets -or should get- nearer.

Then, nervousness gives way to hysteria and the hidden truth arises and comes out of the closet. The project is not going well. Guess what? Now hard decisions must be made, there’s almost no time and they (we) all go crazy.

Follow my advice: it’s all about managing expectations correctly. Too eager to please, sometimes we are too optimistic and make our projections forgetting risk management, inefficiencies, overheads, limited budgets, mistakes or that people are simply people.

If you are realistic in your predictions, and still take out a small bite allowing for some slack, you’ll be able to actually achieve what you have promised. Even, on the eyes of your benevolent customer, the under-promise might become an overachievement. You won’t lose your face but keep your credibility and increase your perceived efficiency.

Even in the worst case, it’s better to know the truth. Maybe the customer decides not to go ahead with the contract, but that will be better for you because there is no glory in projects that are doomed beforehand. Or maybe you and your customer can discover a better way of doing things, put some safeguards in place or simply make some drastic measures that might increase the probability of success. In any case, honesty is always a good advice.

I’ve tried to describe all this in the following expectations model:

It’s all about aligning expectations and results. The credibility zone is along that line but also tending to the overachievement. In short, people might expect you to do things better as they thought you would, but they won’t forgive if you do worse.

When you go down the credibility zone, there’s only danger: dissatisfied customers are your worst enemy: they may spread the word of a poor job.

Still there’s another danger zone in the upper left hand: giving too high achievements when you’ve managed poor expectations. In this case the problem is the bottom-line: probably you’ve spent more resources than were necessary and your customer would have been satisfied with less. It seems to me you should make a better use of your resources, or handle a few of them back to your organisation: after all they have a cost, although you might not perceive it. But with less capital employed, the profitability grows higher.

Remember: don’t be the one to put the rope around your own neck but do your best to keep it healthy instead. You might have much more leverage than the one you think you have.

Aviation, b-school, Blogging, Henley, HRM, Management, Project Management, Projects, Thoughts

Living with the Terminal 5 syndrome

As the average reader of this blog knows, and wordpress knows such individuals exist to my amazement (THANK-YOU), I do several things in my job, one of them is the integration of the baggagge system in the Terminal South (or Terminal D) in Barcelona’s airport.

Well, it used to be one of them… but it has been growing and growing, absorbing my time and effort, sometimes with complex things, of course, but very often with little and silly things, sometimes simply to overcome the lack of communications between parts in a huge project, sometimes just repeating the same things again and again.

Organisations prepare themselves to manage projects. They start shyly with one and, if they are able to envisage an strategy, they include project management into their capabilities. There are models to describe how project management competencies are integrated into organisational capabilities. Different organisations are at different levels, and thus are able not only to manage projects but also to increasingly learn from them.

But, at the end of the day, panic happens. That’s when they forget everything and start to triple-check everything based on the gut feelings of people, high enough in the ladder, that don’t really know about the systems to be implemented. Trivial things get inflated and strategic things suddenly obviated.

That’s what has happened to me with the Terminal 5 syndrome (to know more about Heathrow’s Terminal 5 click here). It will take some time to settle. In the meantime some issues have been enshrined as the most relevant by the organisation and are draining a lot of resources. Yes, organisations are able to learn a lot about project management but, when panic starts, they sort of regress to a previous state, top level managers want to micromanage what they still don’t know anything about, and reality gets distorted to adapt to the top management expectations.

A hard critique? Fortunately the tide is just a tide and we will be able to focus the existing energies on the real issues… having top management’s attention is very helpful as long you can manage it in the right direction, and to help you instead of interfering.

b-school, Henley, Management, MBA, Project Management, Projects, Thoughts

From macro to micro (and backwards)

When you think of building a terminal you always think of huge construction works. And yes, that’s the bulk of the budget, and sometimes the most spectacular part. But in a 80/20 rule fashion, that 20% ends up entailing 80% of the work. As I like to say, the devil is in the details.

For example, in Barcelona’s airport, we started 2006 doing something like this:

The horizontal axis is roughly equivalent to one mile. The South Terminal was beginning to take shape. It was still divided into several parts instead of being a single building. That’s the way it was decided in the tendering process: there should be a few smaller cakes instead of a big one. A dilemma between having to co-ordinate or letting more companies participate. It was decided towards the latter… no wonder co-ordinating has been one of the main issues here.

But three years later, with the building almost done, we are focusing on a lot of different and much smaller things. Things like the following:

The white structure you see is inserted to the glass block. The purpose of the structure is to hold a couple of flat screens to be able to inform the passengers for the boarding process. It is thus provided by a different company than the one that is building the green glass block, the one that is providing the energy, the one that is providing the communications (that the screen will surely need in order to work), and the one that is providing things such as the air bridge or the cooling systems.

Yes, it’s all about interference again. In this case, as we get closer to the endgame, the different paths start to converge into one set of critical paths, all interrelated with each other. There’s no more unique critical path, but every single path becomes dependent on the others’ every delay: a web of interdependencies, a critical network instead of a path. 

My impression is that this part is much trickier than the other one. Finishing something is much more difficult than just going along with it. Slack has been consumed: the endpoint is not far anymore, pressure is increasing, hysteria is hovering, and we have to go down to every detail.

And studying for the final exam doesn’t help. In fact I sometimes arrive so tired that I don’t have the will to do anything. Still I have to. I strive to find some free time whenever, sometimes eating a quick sandwich and hurrying to imitate the waiting passengers in any available coach. The only difference is that they are waiting for something, just passing the time. I, on the other hand, I’m trying to use it. My macbook comes with me wherever I go, preview -for PDFs- and powerpoint to take notes always ready.

It’s funny how the process here is the other way around. When I studied the people, processes and financial modules, it was a matter of going into detail, of submerging into a wealth of information and trying to find the details, the reflections, the hidden wisdom, sometimes simply the stories behind, the assumptions, the reasoning. In fact that was a mistake because my teachers didn’t want me to prove that in the assignments: they just wanted to test that I knew the basic models. And I paid a price for going too far.

Now I’m going back to the basics. An exam is a place where you have to prove that you understand the basic reasoning, its assumptions, and apply it to some cases. It’s something like the terminal, but backwards, from detail to widely accepted models. That’s what they expect from me, and that’s what I should be giving them… I’ll try to refrain myself from doing otherwise.

Aviation, b-school, HRM, Management, MBA, Project Management, Projects

Learning from Terminal 5 (Interviewed for the Times)

I was interviewed by Widget Finn for the Times, and she wrote the following article:

The disastrous debut of Heathrow’s Terminal 5 was a nightmare experience for all involved, but for Gabriel Mesquida it has proved a valuable live case study for his MBA dissertation.

Mesquida is a programme manager for Aena, the Spanish equivalent of British Airports Authority, that is in charge of the expansion of Barcelona’s airport. He is responsible for the coordination of projects in the information systems, communications and security programmes. His dissertation for the distance-learning MBA that he is doing at Henley Management College is on managing airports for the future, so he is watching carefully how the Terminal 5 saga unfolds.

He says: “Our terminal is similar in size to Heathrow, which is considered the plane capital of Europe, and I visited T5 several times when it was under construction. I was impressed, at the time, by how much detail they were going into over safety and they were scrupulous about everything.”

But when the terminal opened it became apparent that there would be other useful lessons to be learnt – including how to manage a meltdown. “An MBA has a foundation of theory but it should be practical, so having a live case study means you can watch events as they unfold and draw conclusions from them.”

The conclusions may be different when the case study is current rather than from a textbook comments Dr Richard Barker, director of MBA programmes at Judge Business School. He says: “One of the benefits is that you don’t know the outcome, which simulates the management situation more effectively. With a five-year-old case study there’s a result to the story which is difficult to escape. You can look at different options that management had at the time but knowing what happened influences your ability to assess the case.”

Mesquida is already putting into practice some principles of leadership from his MBA that were highlighted in the Terminal 5 episode. He says: “Resources are important, but people are far more so and leadership is everything when you have a flock of people wandering around a huge new infrastructure. However carefully you prepare, the unexpected can happen, and that is when your staff should have the flexibility to use their initiative. If the company has a blame culture people will be reluctant to take risks or do anything except cover their own backs.”

Durham University Business School uses live case studies in boardroom simulation exercises where students focus on a real company. Dr Julie Hodges, director of MBA programmes, explains: “They look at the strategic data, where the company is now, what challenges and issues it’s facing, then students come up with recommendations based on the information.” But textbook cases also have their value. “These give an historical perspective so that the issues can be put into context. More data is available and we can identify the medium and long-term lessons.”

Textbooks’ case studies are polished, tried and tested so they are easier from a teaching viewpoint. Barker points out that they are also pigeonholed into subject areas. “They may be labelled a strategy or marketing case, which isn’t always obvious when you’ re trying to deal with something in the boardroom.”

He can predict some of the labels that will be put on Terminal 5. “I see it as an operations management case – make sure your operation works before you start overloading it, or a people management case – train your people properly and handle recovery situations effectively.”

Mesquida agrees that more lessons will emerge from Terminal 5 as time goes by, but together with his MBA learning, it is already shaping his decisions for Barcelona airport. He says: “We need performance indicators and a more systemic approach. Stakeholders and users shouldn’t have the impression that you’re out of control or they’ll feel abandoned. They must be kept fully informed of what’s happening and how you plan to remedy the situation.”

Terminal 5’s launch onto the world stage may have been a fiasco but, clearly as a learning resource for business students, it will run and run.

Thank-you Widget 🙂

b-school, Management, Project Management, Projects, Thoughts

After a dreadful meeting (when did people stop listening to each other?)

I’m too busy these days. That’s why my blogging activity has been errr… nullified. And having to cope with my MBA is far too harsh. A lot of side activities have suffered a lot. Right now I feel I’m even paying too much for my gym!

This morning I’ve had a surprising meeting. I can’t talk too much of it because of confidentiality reason, and because I know that at least one of the people in the meeting checks this blog (hi!). But the thing is something like what follows:

We had a project. We changed it a couple of years ago to accommodate a different corporate sensibility. We excluded some parts that had to be provided by the “official” corporate provider. Now it’s getting late and we really need those parts, and the central sensibility ends up saying that it’s not sensible to provide those parts, that should have never spun off the project.

Which are the alternatives? either find a compromise or change the project again. But the project would suffer from delays if it had to change again. Too late for changes.

What surprises me is that the reasons that I exposed today were also exposed two years ago. Then they weren’t a problem. Now they are. Why? The devil is in the details. And when people have to start assuming responsibilities for their decisions… they baulk out.

Why should we be discussing philosophy in a late execution phase? I expected a quarrel over completion dates, that’s true, but never a review of the bottom line. Didn’t we talk about all this before? Didn’t we understand each other?

Is the proximity of completion a necessity for people to effectively listen and think practically? Is it true that from the distance everything is possible and people just don’t care? Is it the way we do things around here?

If people could really share in advance, listen to each other, try to understand… things could be different. But I guess is easier to let the time sleep by. And to assume that an old idea of yours just matures and becomes universal with the march of time. Then you slam it on someone else’s face and say “I already said that, two years ago!”

But even when that happens, the game of retreats is utterly useless. I firmly believe that people should be accountable to themselves, and my duty is to still be constructive and try to push things ahead amid the unexpected difficulties.

b-school, Business, Henley, HRM, MBA, Project Management, Projects

Roles of product/project managers in organisations (a matter of power)

Organisations are all about power. And it’s the share of power the most important element that defines their structural form. Some might say that it’s strategy, and that’s true also, or used to be true, but the shape that an organisation takes it’s all about control, flexibility and who says what.

One of the most classical forms, as Mintzberg would say, is the functional structure. If we focus on a certain product (or project) within the organisation, it can be seen how it spreads throughout the diverse functions but, at the same time, has to surpass many walls: those that separate the different functions.


Those are the walls that the Matrix Structure that I commented some days ago wanted to tear down. The fact is that our product or project will have to cope with different areas, different styles, and different line managers. Could that even be enough to make the project fail?

Following with the discussion that arose in the referred post, while studying operations I diverged and ended up with and old article from the McKinsey Quarterly from 1991. In there Kim B. Clark (Harvard Business School) and Takahiro Fujimoto (Tokyo University) focused on the role of the product manager in the car-design industry.

Guess what? It’s the same situation than the need for the matrix organisation. The only difference is that they think of the horizontal levels as product managers that need to access a spread of resources throughout the organisation. They are the ones that need the keys to the corporate walls to make their project advance. They are the ones accountable for it too.

Clark & Fujimoto defined three different ways of product managers. The first one would be the lightweight product manager:


As you can see, this one has a limited area of strong influence. Probably he only controls some parts of the process, maybe coordinating engineers or activities. But the weight still relies on the functions.

They won’t have direct access to people. Instead they will use liaisons (drawn as Ls). The people still belong to the functions so they are only able to ask for things. And it’s the task of the functions to assign priorities. They will, nonetheless, help the several groups to resolve their conflicts. They will be able to broker the information, but they can’t be held responsible for the whole product because that responsibility will be widely distributed. And… do you know what might happen when responsibility is so distributed?

The answer of that question leads us to the third form: the heavyweight product manager structure:


A reinforced product/project manager comes to the aid of the completion of the project. Now she has a broader responsibility, being the organisation still functional. It’s not the liaisons that she will be talking to, as before, but also she will have access to the whole team when necessary, and thus will be able to go down to detail with engineers.

So what if we reinforce them further? That’s when the project execution team structure comes into play.


This structure is also known as tiger team. Now people do work on the project, not just their liaisons. They have been somehow extracted of the functional structure and they belong to a new structure as a team. Some people will still work on several projects at the same time but some will be solely in this team.

What do functional managers still do in this case? They provide the people needed. So the product manager won’t have to worry about sourcing her team. She will have the maximum possible influence. And from her position she will be able to establish direct links to additional external sourcing if necessary.

It seems clear that this structure has some things in common with the matrix structure. But yet it’s still functional. As many organisations are.

Teaching about project management I can always sense how people are worried on how to match project’s needs within their organisational structures, usually not supportive at all: They have to cope with their functional/divisional requirements and the extra interdepartmental tasks. These models provide a useful framework for discussing all that. It seems clear that if you give a project manager a responsibility you have to enable her to be able to carry it along. Otherwise good intentions won’t endure and the project manager will simply become demotivated after beating a dead horse.