The art of getting control in the multi-project chaos

Almost all modern organizations have ended up in a multi-project chaos at some time or other. This is not so strange actually, considering that the trend is to run more and more of the business in projects.

Projects are, after all, such a good way of working. Many think it is an easy way to delegate responsibility and some authority down to the organization. So a number of projects are started without thinking of what the consequences can be and how difficult it is to manage a business with many projects going on simultaneously, in other words a multi-project environment.

A multi-project environment has many characteristics. What one first notices is how stressed-out everyone gets, how unstructured the work is, and how overbooked all of the resources are. Then the organization begins on a journey to project maturity:

1. Several advantages are seen in starting to work in projects in a unified manner with the help of a project management model.

2. Excel files with all on-going projects start to turn up because of the insight that all the resources are overbooked and a need has arisen to coordinate the projects.

3. Are we working with the right things? – is the next question. In other words, are these the right projects to invest in, maybe a few projects should be discontinued that do not agree with the business’ goals anyway?

4. We have to learn from all of our experiences! This insight is usually made when the project situation is finally under control. Then there is a desire to make use of previous documentation and follow-ups to be able to learn from past mistakes.

Many companies are in the midst of this little journey. They are either just getting started or getting close to the goal, where a multi-project environment can actually be managed effectively, once I worked with a west vancouver realtor who was really organize in his projects so they were easier. It is an exciting journey in any case, where it might be good to listen to tips and advice so it is made both faster and easier.

The following is a little tale from real life, where a CEO one day realized that it was this particular journey that should be taken:

The Paradise of decisions

“You got investment approval on your project. The management understood the problem with the deadline and gave you the highest priority.”
“Great! Thanks!”

Ohhh, this is wonderful, I thought as I
rushed off to the next meeting. It was Monday and, as usual, ‘the big meeting day’.

My big worry of late had been how I would manage to carry out my project in the timeframe set by the company. There was a lot to be done and the delivery date could not be moved for anything. The smallest delay on the part of the project would entail a minor catastrophe for the company. In several other projects that I had run we had had this little leeway, but not here. The problem for me had been to get the management to understand the problem. And I had clearly succeeded. Finally I would be able to sleep through the night without lying awake, worrying.

I was working as a project manager for a large telecom company. I was actually a consultant, but was commissioned as the project manager for ‘the important project’. It dealt with making a major change to a cell phone network, which had to be finished before a new service was launched. Marketing of service had already begun and the launch was to be made with drums and balloons. Everyone was just waiting for the day of the big launch when usage of the cool service could start, money could start pouring in, and the company could pull ahead of the competition in terms of technology and create an image as the cool telecom company.

I liked the management of the company where I worked as a consultant, but I knew that they were technology freaks and therefore had a tendency to start many new technical projects. We who worked in the technical projects of course realized what all of these decisions meant in terms of lacking resources and delayed timetables, but the management had somehow not understood the consequences of their decisions. Sometimes it felt like they believed we could do magic.

Sure it is great with a management that is not afraid of making decisions, but in our multi-project environment it brought with it the big problem. The large workload brought the resources to their knees; we had constant conflicts between the line management and the project, and between projects. Everyone was fighting for resources (both personnel and technology), everyone felt that their project was the most important and we spent more energy handling conflicts than creating new products. Do you recognize this? Anyway, I have experienced the problem at more than one company.

In this case, I got started with my project full of enthusiasm, having the necessary resources available. The first week we did wonders. We succeeded in preparing a detailed activity plan that everyone believed in. The feeling that we would manage our tough deadline began to spread through the group and we were looking forwards to the work of the coming weeks.

Then came yet another Monday with all of its meetings, including the management meeting. I rushed from one meeting to the next, and at the end of the day we had our project meeting. In a happy mood, I came to the meeting. I was looking forwards to hearing about the project’s progress since the indications of the previous week had been very positive. The meeting started really well and I got the positive reports I had been hoping for. Then came the punch. Another project had been started the same morning. The project would use several of my project’s key people and they had heard that the new project would have the SAME priority as my project, although it was implied that the new project was more important. The argument for the other project had been that it was VERY important for the company to market just such a service quickly (it was simply a brilliant idea, that I could not deny). I did not understand a thing. Last week my project had been the most important, since the launch of the already marketed service was so reliant on my project. Was this suddenly not important? Should I now just ignore the deadline? There was no way I could get my project done now that most of my key people would be working in another project. Simply put, I got mad!

With determined steps I walked up to the management’s floor (why is the management always on the top floor?). I was all too irritated and confused to wonder if the management had time to meet me. I had decided to get an answer to the question: What should I do with my project?

A somewhat surprised CEO looked up at my red face when I rushed into his office after just a brief knock. I was lucky that he was not busy with anything other than his own computer. (He was probably reading email.) In that instant I did not really care what he was doing – I was just so angry. I knew that I probably reacted a little beyond the scope of the problem, but that is what often happens when you are passionate about your work. The CEO knew me from before and had several times said some appreciated words about my strong sense of commitment, so maybe it was about time that he got to see the negative side of it too. With a surprised look he listened to my explanation of the problem. When I was done, he sat quiet a while and then calmly, but with some surprise said
“So both projects use essentially the same key people? That was not mentioned at the approval meeting. We obviously have a problem when it comes to coordination between the projects,” said the CEO.
I just stood there with my mouth open from surprise. Obviously the management had not been aware of the problem that all of us in the technology department constantly complained about – all of the projects fighting for the same resources. It was simply an informational miss in the organization. Fortunately the boss was a man of action, so we sat down together to see how we could solve the problem. We decided we needed to do the following.

1. Conduct an inventory of resources in projects. How many projects can we handle?
2. Create a list of all on-going projects.
3. Get information on and the status of all projects with regards to time, cost, project targets, estimated profitability, and impact targets.
4. Identify all projects that are in line with the business’ goals.
5. Group the projects by, for example requirements of authorities, technical requirements, market requirements, organization etc.
6. Develop guidelines for how to prioritize projects in each grouping.
7. Prioritize all projects according to the new guidelines.
8. Select as many projects in each grouping as could be handled.
9. Do not start any new projects, without them coming up on our project list, with all the necessary information to make a correct priority assessment.

How did it all end up? The boss talked with the rest of the management, used the new lists and set new prioritizations on all of the projects, including mine. The reaction from all of the project managers, even those that got their projects down-prioritized, was unexpectedly good, as everyone got to see the list with comments as to why the prioritizations were set as they were. It was easier to understand the decisions when one got the overall picture. I myself was of course satisfied and happy with my prioritization (even if I did not get the highest) and also succeeded in getting the project done within the timeframe (even if we had to work some overtime at the end).

Was the change completely painless? No, but it in any case improved the situation, since all of the projects got to play by the same rules. Previously the prioritization was set more depending on how the project manager made his or her presentation than according to any given criteria. Which is also why projects were often wrongly prioritized. As mentioned, it is easier to understand and accept decisions when one sees the overall picture and this creates a working climate with fewer conflicts and a greater chance of actually succeeding in the projects.

The resources that were already popular to use in all of the projects continued to have a tough time, but they had in any case a tough, but controlled time, and this meant that all of the project managers had more control of what could cause delays and thereby more easily work around the problems. Getting an overview simply gave everyone a greater chance of fending off the problems.

So in hindsight, I am quite happy that I got so annoyed over the situation and got the boss to understand the problem. Even if my project did not go perfectly, I in any case succeeded in drawing attention to a more serious problem. So who is complaining? And the concept as such is what I am now days trying to work in to several companies. Because I know that it works 🙂