Gabriel’s scarcity rent - it’s management stupid!

Some weeks are so hectic that you simply don’t have time to write. And if you do, it’s not because you’ve had the chance to sit back and reflect about something, but because you have some free time in-between things to be done. That’s the case for today: a few free minutes.

The day began in Madrid, in the Indian embassy, queuing for such a simple and stupid thing as a visa. It’s incredible how certain processes are still done as the last century, or even the previous one. The fact is that if you want to travel to India from Barcelona, first you must go to Madrid to get your visa. The alternative is waiting around three or four weeks to have it.

And if you went there without a warning, you’d be astonished to know that they only issue a limited number of visas, clearly outnumbered by the people that need them. So the queue starts around two hours before they open. By the time they unlock the doors, there’s enough people waiting to fill the entire waiting room. If you arrive at ten, just forget the visa. Come back tomorrow (in Spanish “vuelva usted mañana” although the Indians speak more English than Spanish). And that’s the only way for the 46 million inhabitants of Spain to visit the 1,100-million-people country.

Well. I finally made it. I was sixth on the line. Then, to the airport to take a plane back to Barcelona. And from the airport to one of Barcelona’s marinas: the Olympic port, built for Barcelona’s Olympics 15 years ago.

From air planes to boats: time to sail. That’s why I am here for. I am to renew my sailing licenses and, following legal requirements, I need several navigation hours with a captain instructor. A good way to ensure that people actually know about boats before granting them the right to sail them. That’s what I am here for.

Time for the final comment. Where is management in all this? Well. Ask it to Captain Marcos Rivera. In a ship, there’s only one captain. Such affirmation is something that we tend to forget. Authority is not a very popular value these days. It is still necessary nonetheless. Someone has to decide. There must be someone in charge, asessing the risks, analysing and drawing conclusions, and then, finally, deciding.

That doesn’t mean that he (or she) is the only one to think. That would be a great loss of value, rationality, thinking capacity, a loss of options. Empowerment is still essential (and compatible), as it is dissent. But there’s a limit to it. And when the captain decides, the others must follow.

Have you ever felt that, in a project or a workgroup, the problem was that the decisions were not actually being made? Or being enforced? Have you ever felt that authority was missing? That indecision and ambiguity was undermining the whole execution? That’s when a good methodology for making decisions is needed.

There’s a time when every task becomes critical: just give it enough wandering time and you’ll see. IT comes a time when further procrastination is no longer possible. That’s when a chieftain is needed.

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):

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.

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.

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.

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.

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

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.

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.

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.

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.