Posts filed under ‘Projects’
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.
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 
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.
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.
Ashby’s law (law of variety), sometimes simplicity isn’t enough
I’ve always defended simplicity. From Occam’s razor in the 14th century we know the lex parsimoniae, meaning parsimoniae simplicity, brevity and succincty. When different explanations are available, ceteris paribus or other things being equal in plain English, the simplest wins. Thus the simpler the better.
Probably you’ll also remember Einstein‘s quote: “make it as simple as possible, but no simpler”. Why should we want complicated explanations when simpler are available? We shouldn’t, unless we were missing something.
What does that have to do with management? Well, there’s a connection. A fairly strong connection if you use systemic thinking. Remember the holistic approach I was proposing? The local maximums don’t lead to a global maximum, optimising the parts doesn’t mean optimising the system… that means that not only adding simple strategies in an organisation’s parts don’t lead to a simple global explanation but that maybe the simplest strategy may not be the most suitable one.
So, should we aim for the simplest solution? Well, that depends… it just may be too simple. There’s an exact point of compromise between simplicity and effectivity.
W. Ross Ashby, psychiatrist, one of the founding fathers of cybernetics
That takes us to Ashby’s law:
«The larger the variety of actions available to a control system, the larger the variety of perturbations it is able to compensate.»
Ashby’s law is also known as Law of Requisite Variety. It’s a funny concept because we intuitively know that sometimes we need very complicated solutions, but the idea of simplicity sells a lot more. So it’s not too fashionable to search for complex solutions. Looks like that you have the obligation to come up with something simple.
Guess what? Reality is stubborn. And while you try to implement simplicity, complexity will crawl and arise again and again. This basic law of life will stab your project.
One example: a railway level crossing. Engineers design the signals on the road efficiently. Other engineers design the traffic lights, with several tests and taking into account the different timings. Both teams with my-box thinking. Efficient. There are some problems, cars get very close to the trains. The system is reviewed and timings measured again. Nothing’s wrong again, until 1995:
October 25th 1995, Illinois. One of the worst track-crossing accidents in the history of the US. A train collides with a high-school bus. Seven teenagers killed. No human error. All the systems working fine. The warning lights activated on time. There simply was an unexpected, very improbable, combination of events that led to the disaster. $27.3 million were paid to the victims’ relatives, but that didn’t save them.
The control system was too simple. It didn’t contemplate all the variety that could be produced. It simply had some timings established and a big margin above them to ensure safety. But statistics and margins are not enough. There is a need to understand the system to be able to control it. That’s why there are still humans controlling machines.
There’s more to systems than meets the eye. The typical examples belong to engineering: from the first Tacoma Narrows bridge in San Francisco, also known as Galloping Gertie, that collapsed November 7th 1940, to the £18.2m Millennium Bridge in London, that was opened in 2000 and was closed three days later because of swaying and extreme wobble and remained closed until 2002 and an additional £5m. Bridges are good examples of systems doing things they were not meant to do.
But don’t read this as an engineering story. All this is also applicable to organisations. The manager must be able to counteract disturbances, and she is always outnumbered. Only organisations with enough variety and diversity will adapt to changing realities -and thrive in them-. Only that way they are prepared to foreseen -or unforeseen- contingencies. Those too homogeneous will crash when the wrong wind blows, unable to adapt.
The need for methodologies (to keep the geeks leashed)
Working in an airport, systems are everything. They let you use and optimise resources, from energy to stands, from baggage handling systems to closed circuit television, from alarms to air conditioning, from runways to platform stands.
Systems do not last for long. Technology evolves so quickly that what wasn’t possible three years ago, it’s common knowledge now. And when building a new airport almost all systems must be rebuilt following new requirements: more security, more resources and users, new technologies, leaner operation.
And those new systems need to be designed from scratch. What there was before is rarely usable.
That’s when methodologies are essential. I’ve always believed in methodologies in many developments, but when developing information systems they are more than essential.
Why?
One of the worst things that you have to avoid is the crazy-coder syndrome, that is the guy that sits in front of the computer and begins coding and application, or, which is the same, the guy that quickly calls a few providers and tries to learn from them. The companies that go directly to execution scare the hell out of me.
gambling with systems
Let’s make that clear, there’s nothing wrong in learning from providers, in fact it’s necessary if you want to have a clear view of what will be in store for your project, what you can achieve and cost and time-frames. The wrongdoing in this case is to approach providers directly, from the first moment.
Why that? Because everybody has his own interest and his own point of view. And while your purpose is to be able to deliver in time, scope, quality and at no extra cost, the companies are there to earn money (yes, a lot of things more: corporate responsibility, serving the customer, establishing long term relationships… I do know that stuff)
First think, then act
Which is my recommended approach? Follow a methodology.
Yes, sounds strange, but that essentially means following some very sensible steps:
- First think of the viability of the project. If there are major changes to be made, the moment is now.
- Review all the contractual requirements, your stakeholders, as a project manager you’re not working for yourself but for your customer (the airport in my case, and the security director in this case). Make the contractor to review all the contractual obligations, sometimes they are not even aware of all of them.
- Then define the needs of the customer, that’s the requirements of the system you are going to build will have to comply with. Have the provider write them down too. Have the customer validate them. Don’t expect the customer to validate everything once all it’s said and done. That wouldn’t be nice or fair.
- Then design the system. Before building anything you have to have it described to detail. Validate with all your technical customers, those that will have to maintain the system after the launch.
- Now, and only now, you can unleash the geeks and begin to build. In that process you’ll have to be aware of the scope creep, and many more things. I’ll talk about this another day
- Then try, try and try. Do not expect to put everything in operation at once and find the flaws at execution. (I won’t let you) At least three testing levels: at your office, in front of me and in front of the final users. Be ready to test everything once, twice or thrice if necessary. Test integration with other systems.
- Last, but not least, transfer to operation. Keep the possibility of a roll-back available, and make everyone know and participate. Think of formation, of support, of replacement parts.
But that wouldn’t work without planning: general plannings, detailed plannings. And plannings must be alive and constantly updated, as well as properly disseminated, along with meeting memos and the documents supporting all the tasks that have been undertaken.
Sounds reasonable? You’d be surprised on how many projects do not follow any of these.
Recent Comments