Posts filed under ‘Project Management’
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 
Disagree, but don’t be disagreeable!
What happens if in a meeting something is said and you think it’s not right? Easy. You say no. You can say it softer or louder, directly or through complicated verses, but you say no. That’s all.
Now let’s add another ingredient to the soup: power. Some people have more power than others, and I’m referring to an organisation. And you are the one not to have it. Unlucky you. And relationships are in a touchy state… you no longer can afford to say no… but you still have to disagree. What can you do?
Just remember that you can acknowledge something, being either the cat or the mouse, and that doesn’t mean you agree. It means you’re still able to listen. Don’t let your defensiveness show through your lack of attention. Don’t let your position, whatever it is, impair your education or politeness, you’re still a professional.
You don’t have to think that listening, and acknowledging what you’ve heard means yielding. Nor you should thing that expressing your point of view means winning. It’s good to put your cards on the table even so to understand everyone’s position. And it’s something that speaks highly of you to acknowledge the position of the other, the only compromise is on behalf of your professionality.
Still if you are the mice you have to find ways to make the ideas move around the table, to show contradictions in the other’s position. Just visualise their ideas from your point of view “so you mean that if things are done like this then… but if they are done that way like you say, those issues are no longer problematic… is this, thus, what’s at stake?”. Don’t refrain to be challenging “… isn’t that a contradiction” or even reassuring yourself “isn’t this more less the same I was saying” and minimise the differences “could that be that our only difference is where we locate that square… is that really so important?” or don’t fall into distractions “aren’t we moving out of track here?”.
And last, but not least, wherever you are, don’t make it personal. People are not at stake here, issues are. The rather provocative “could you express this less personally?” requires to have shown interest in the other person, to have been careful about showing attention, to avoid gestures that show rejection, to avoid aggressive voice tones. Only then you’ll be able to mediate yourself, be able to reconcile whilst being an active part, keeping the link open whatever happens…
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.
A few questions to ask yourself (from strategy to reality, purpose and accountability)
As you probably know, lately I’ve been thinking a lot about organising people. That’s great because in fact I am studying Human Resource Management (again) and the content without the reflection is just data. And there’s much more than data to learning. (Remember my old post Ackoff’s spectrum of learning?)
There’s so much philosophy on purpose. Ok, let’s change the word from purpose to strategy. Which is the strategy of your (my) company? The obvious answer is…
Let’s stop for a moment. I need your attention here. I’m going to ask again in bold:
*What’s the strategy of YOUR company?*
Do you really know? Think again.
Don’t cheat. It’s not a valid answer to say that the board does know. That’s not enough. For any strategy to be effective it must permeate the whole of the company. Not just to be in the board’s minds. No way.
Usually the use of the word strategy makes us defensive. True, this is nothing that affects us. Or maybe it does affect us but it’s nothing that we have a say on.
Wrong answer for an effective organisation. If the strategy is not only top-down but bottom-up, we should have a say. In fact I really think we should.
Let’s swap words again. Let’s talk about purpose. Purpose is not a scary word but, at the same time, has a lot in common with strategy. And ask yourself another question.
*What is the purpose of your job, of your post?*
That is easier to answer, but not quite. Is that really what you are doing? Don’t you think that’s the first thing that you should be clarifying with your boss? Along with a complementary question: what’s the purpose of her/his job? How do both purposes match?
This kind of questions should be asked periodically. Let’s not fall into the management trap. Let’s not end up being increasingly efficient with something that, at the end of the day, we shouldn’t be doing.
Let’s ask again.
*Are you being held accountable for the things you should be doing in your post or simply by the things you’re doing, for a few of them or, even worse, for things you are not doing and neither related to?*
Or in a more positive (and extrinsic) fashion:
*Are you being rewarded coherently with the purpose of your post?*
Why is that question important? Well, first there must be a clear purpose to our job, although probably one that will change quite often, but then all the metrics should match. And when I’m talking about metrics I’m not only thinking of “hard” financial metrics, but also the soft, and often much more important ones, from customer satisfaction to employee turnover rates, and the cause of these rates.
But these reflections wouldn’t be complete if we didn’t close the circle.
*Do this purpose match the strategy of the company? Is the accountability matching that purpose and strategy?*
Because if we could answer this question, we would be effectively knowing, and working for and along the strategy of the company. The strategy wouldn’t be tongue-in-cheek or lip service. It would be a common tool, a shared vision, something that would help the whole company move in phase and amplify its efforts. It would be part of a glue that would tie the parts tighter to the whole.
Being too busy (when some things are not working as they should)
I know it sounds like an excuse, but I’ve been too busy lately. Work has drained my energy to exhaustion, even disturbing my usual studying pace. But, what’s funny, it’s not work in itself but dysfunctions at work.
I think I already told you we had a new group of engineers assisting us. They are 20 people (and they will be 25 so if you want to send your curricula you still have time).
But then the problem with management arose. They are not aligned with our objectives. Mainly because their managers simply spend too few of their time and energy here, and there are a series of symptoms of that dysfunction. Let’s see some of them.
Continuous shifts of priorities. They are moved as a whole towards any priority that simply arises. That is not practical at all because they simply loose focus.
A possible solution: plan, plan and plan. Don’t lose the big picture. Don’t swerve. Keep an straight direction and people will be able to follow.
Diluted responsibility. Mid-level managers are not enforced but overrun by the team’s director. That way they simply abhor of their due responsibility and blame it all on the manager, at least subconsciously. In the end they prefer not to decide anything and simply demoralise.
A possible solution: enforce them. If someone holds responsibility for something, it’s for real. His boss shouldn’t come and change it all but listen to him, and maybe learn from him. He should, if he can, defend his position in the organisation.
Visible internal cracks. I have been in several meetings where documents have been presented that didn’t satisfy some of them. There was discussion amongst them about things that should have been already deemed.
A necessary solutions: grow consensus before presenting anything to the customer (that’s us). Their differences need to be cleared beforehand. It’s very important to show unity to the customer, not indecision or doubt. And that only means giving it some extra thought.
Lack of dedication. This symptom relates to the previous ones. To offer a good product, specially in consulting, you need to spend a lot of hours thinking and rethinking documents and ideas. That’s what is expected from you. It’s not acceptable to be in front of the customer and reopen subjects that have already been closed or read your notes on a paper towel from a restaurant.
A possible solution: effectively dedicate the people to the project, not try to have them in several projects at the same time with the result that they cannot focus on any of them. People need to focus to be effective.
Lack of knowledge of the customer. Not knowing how we are, what we want and how we work. That means that sometimes we don’t understand each other or they simply propose alternatives that have already been discarded. In a project that is quickly reaching its critical phase that may lead to confusion and trouble.
A necessary solution: you must know who are you working for, how they work, how they share responsibilities and not focus uniquely on the front man or the director who awarded the contract. The director always has people that he trusts to do things and with responsibilities (us) and that’s the ones you’re really working for (the ones that need the resources and the ones that will report about completion and effectiveness of tasks).
The final result is that, when we don’t understand each other, the problems escalate and derive into confrontations that, in time, become harsher and harder. Anger appears and people start not to listen to each other. And the rest of the team simply don’t know what to do. They feel confused, and lost.
I could go on adding more basic ideas, and make this entry long and boring. But my final message is that you’d be surprised on how many companies simply forget these basic rules.
Rules that should be understood by any manager providing consulting services to a client.
The final consequence of not following them is that people suffer. The team is not enabled but alienated. People don’t identify with and push for for the project but instead lose initiative and retrace to defensive and reactive positions. You end up burning up your team. People are so valuable yet so sensible to uncertainty. Even consultants.
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.
Enraging a contractor (a.k.a. may it be better for your career not to care about what you decide?)
Today I enraged a contractor because I postponed a meeting to September and they are in a hurry for a decision.
Let me explain it further, they need a decision on something quick. But we don’t have the information to make the decision.
Yesterday I had a meeting with the communications group. There we talk about communications and related systems and we decide if projects can be executed the way contractors propose or we need to change them. When we decide for a change, then we justify our decision and we ask for new analysis to evaluate the impact on costs and deadlines. Then, with the whole analysis done, and alternatives pondered, we reach the final decision.
This contractor knew I was having a meeting with the communications group and approached me the day before telling me that they can do the changes we have requested but that will cost us an additional 700.000€. It would help them if I talked to our peers and tell them if that could be assumed or not. Of course it would!
But I didn’t agree on that. First the information, then we analyse it, make changes to the project if necessary and then, and only then, we evaluate if the cost is realistic and worth assuming or not. Sometimes if we see that a contractor is too high on cost, we can even decide not to execute that part and give it to a different contractor. That way a contractor can also loose a game if pushing too hard.
But after waiting two months for the study I’m not going to provoke a meeting before even having the information. There’s no way I’m going to do that. Or try to make a compromise or decision over ambiguous information. No way.
So I just decided to tell them. They got very annoyed, they see, from their point of view, that they need the decision now, so they try to pressure as much as they can. Fortunately they cannot do anything because, right now, there’s not even a proposal over the table.
But, that’s my reflection, is that good management practice? I think that a meeting shouldn’t be done unless it can be effective. And I don’t think there are the conditions for an effective meeting here. So I decide not to do it. It’s my say.
But, could it be that I like to be in control and I’m simply punishing them for not having done their part of the bargain? There are still some days left before people start disappearing for holidays. If they send me the information right now it still could be done. (At least I’ll try if they do that, I’ve already seen them move quickly under pressure, so it would be worth it anyway).
What would a good politician do? Well, he’d make the meeting anyway, not enrage anyone, and he would hold a completely useless meeting, maybe one that he wouldn’t even attend (I could send someone else too). And the decision wouldn’t be made until September anyway… or he would simply step back and let others make that foul decision with incomplete data (and other people’s money).
I hate wasting my time in useless meetings. But that way people is happier with you. I’ve seen many guys make a career out of this. (And skyrocket because of it). But that means to me something like giving up my own values.
But I can’t do it because I care about the decision, about the outcome for the project. I think I have to give my best to it.
Am I lying to myself? Am I just wasting my chances? Am I doing the right thing? Any thoughts? 
Management: challenging your own assumptions
Today I’ve been working through dynamics of management. There was an important part about the importance for organisations of challenging their own values, their own well established assumptions.
This is something I’ve seen many times in many organisations. They learn from the past, and their past configure their corporate culture and values, but they somehow think that those are enough to lead them into the future.
And this is not to diminish the value of what they have achieved. It’s like the picture I’ve chosen. This organisation has already gone half-way into the Golden Gate bridge. Could they drive the rest of the bridge only with the rear view mirror?
The answer is yes. But only because the Golden Gate is just an straight line. And you can trust that the future will be identical to the past. So you can even avoid looking forward.
But I’m sure you’ll agree with me that is not the best possible strategy. And in turbulent times in which changes happen almost everyday, looking backwards is just useless. We need to learn from the past, but not to be constrained by it.
Last but not least I’d like to include some words from Harvey Maylor, from a good book he authored on project management.
These are about project management rejection attitudes. What do you think? Sound familiar?
- Ready, shoot, aim!
- Everything is already planned in my head!
- We work at a hectic pace, there is no time for planning
- Project Management? This is just common sense!!
- We tried before and did not work
- This will never work here!!
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