Guest Post by

Chaos and Confusion or Clarity and Orientation in Projects

Big, complex projects sometimes remind me of a forest. Big trees tower next to small ones, old beside young. Branches become weak, break off and fall to the ground. Moss begins to build as suddenly something new starts to grow. Bushes obscure our view and we lose our orientation. The wind blows from the North and soon enough we are caught in a violent storm from the West. We look for refuge behind a thick tree. A mist settles and visibility diminishes. Will we ever find out way out the forest?

How will we get our orientation, how will we find navigable paths? Whether in the forest or in our projects, there are a few ways to avoid chaos in projects. I would like to give you three simple but very effective methods. A new perspective on goals, paths and circumstances.

Orientation by way of goals

Without vision the people perish, as the saying goes. But what is the vision? What is the goal of the project? I often encounter projects that have been started, in which everyone has “more or less” discussed the project’s goal. Everyone was already “on their way” to getting there–the task allocation seemed clear. When people joined the team later on however, no-one could really speak with any authority on what the actual goal of the project was. New team mates were just dumped in the middle of this process – left to fend for themselves. The assumption was that they would go along with everyone else and would naturally get everything done that needs to happen and that they would simply “arrive”. But where? Where exactly are they meant to arrive at?

Clarity is attainable if project goals are written down and defined during the planning phase already. The description of the goals can appear in the project plan or wherever else you would like to document them.

The goals should be realistic and as specific and as measurable as possible. The following questions are helpful in getting them to meet these criteria:

  • What exactly is the goal?
  • How can we actually ascertain that we have achieved the goal?

Avoid phrasing like this: “We hope to form a customer friendly, large parking lot close to the supermarket.”
Instead try: “We are building a parking lot for 1500 cars by 31.12.2016 on the super market’s property.”It also helps to provide orientation by detailing what the goals are not. For example: “In this project it will not be our priority to maintain our neighbor’s hedges.”
The more precisely goals are described:

  • the more a uniform collective understanding of the goal can develop
  • the clearer the task allocation will become for each department
  • the better we can see the results of the project
  • the more simply we can integrate new teammates into the group
  • the more conclusively we will be able to prove the achievement of the goals

Clearly described and measurable goals offer orientation in the complex project landscape.

Chaos or orientation in projects

Chaos or orientation in projects

Orientation through process descriptions

Processes are part of every organization and every project. A colleague once told me that there are many processes at his company. He said they placed value on introducing these processes well. Generally they were successful but for some reason he found that his process was constantly being changed. He works in strategic development, which means that his processes are often strongly influenced by his boss’s decisions. With much groveling and many excuses he has to apologize to the other departments for processes that have changed yet again, asking them to fall in line with the new process. That causes frustration and anger for everyone. It is his responsibility to make sure that the process goals are achieved. It frustrates him that his process causes so much consternation and that it costs him so much time, effort and stress.

It turns out that management’s decisions are the cause for all the chopping and changing. His management is responding to short term changes on the market though. Strategic decisions and adjustments to the market are vital to the company’s survival.

We have had long discussions about the counter-arguments to describing a separate process that takes these short term strategic adjustments into consideration – a process that describes the actual course of events as they happen. A process that one could name, for example: “Changes resulting from strategic adjustments to the market.”

Weeks later my colleague writes me an email reporting that he can finally work in peace. He is happy because he has described a process that accounts for these kinds of fluctuations. The process has been inspected by quality management and has been active for a while now. Everyone has instructions on what to do. Communication and the general working environment have become markedly more relaxed.

  • Processes are important. But when the actual course of events in the company deviates from the process description it does not make sense to doggedly maintain the “old” processes.
  • It makes sense then to describe the actual processes in an up-to-date process description and to declare it a valid process.

The results: a firm orientation, clarity, and decisiveness within the project.

Orientation by way of understanding roles

Albert has been a department manager for a year. He is a tester by training, he has worked for many years in test management and has now taken on a role with more responsibility. He would like his job if there weren’t so many debates happening constantly with his project leader Peter. There are often disagreements between the two. Peter complains about not being able to speak to Albert properly and about how Albert sticks his nose in everything in order to get ahead. Not only is it important to Albert that he works well with colleagues on his team but he would  also like to do so with his “internal clients”–his project leaders. Albert got some advice from my project workshop.

Firstly we illuminated Albert’s resume and his position in the company. He has been in the company for ten years, he has worked as a tester, he got additional training and has been a leader in the test department for a year. His 25 staff members are available for the individual client projects. They create test cases and carry many of them out in their own lab. According to Albert, things are going well, everything is just as he likes it–except for Peter of course.

He has found out that Albert is also working directly in Peter’s project. He is not operating within his function as a department manager, instead as a “normal” project team member. When Albert was tasked with this client project, he was supposed to develop test scenarios and to write the test cases that result. That is his field of expertise—that is what his years of experience and his knowledge have prepared him for.

By the way, as head of department he has access to resource planning information among all the projects. That is why he controls the resource allocation for Peter’s project. But Peter rejects Albert’s resource allocation immediately and requests testers and labs at different times. That is the point at which Peter lays a complaint and when a conflict erupts.

Orientation through functional Roles

Let’s investigate if he has a job description, an outline of his role as head of department. Yes, there is one. In it his tasks are described exactly and his competencies and responsibilities are listed. One of his many responsibilities is arranging staff and lab resource allocation for the client project at hand.

He has an assignment description for the work to be done in the project. That includes the development of test scenarios and the creation of comprehensive test cases. The description of thetask content and his areas of responsibility soon follow.

  • Job description = description of functional roles are of first importance in order to bring about clarity and decisiveness for the person carrying out the role.

Orientation by way of situational roles

We had both functional descriptions and still there is a problem between the two of them. Clearly it was necessary to look at the issue in greater detail. We put the focus on the working situation and consequently on the situational roles that Albert assumes in the project.
In Peter’s project Albert is not just “Albert the head of department”, but also “Albert the test case creator”. His project leader expects him to create test scenarios and to create the corresponding test cases for them. That is why “Albert the test case creator” was commissioned in the first place and that is just what his project leader expects from him. Completing this task fulfills Peter’s expectations.

Then, “Albert the test case creator” immediately creates the test plan and the resource allocation for the project. But this is not part of his responsibility as “Albert the test case creator”. He shouldn’t have to make a test plan. In all other projects these generally get made by project leaders and fall under the responsibility of “Albert the head of department”.

This is the where Albert unconsciously crosses the line of his role as “Albert the test case creator”. Albert has tacitly taken on parts of Peter’s job. You might be tempted to think Peter should count himself lucky that someone is taking on a bit of his load. Peter, on the other hand, perceives Albert’s behavior to be petty interventionism, causing him to resist it.

Upon further analysis we see that Peter also has other good reasons for his behavior. Lots of tests actually happen on location, in front of clients. There is a contractual agreement with clients allowing them to participate in internal tests in Albert’s lab. That means that Peter has to go through much more consultation. These appointments can only be taken into consideration in Peter’s test planning. That is another reason for Peter’s rejection.

So it would seem Albert has two functional descriptions for his activities in the company and two different roles. He experiences an “aha” moment when he realizes that he had been conflating the two roles. That was the cause for the problems and bickering with Peter. Now he takes more conscious note of his roles and considers carefully which roles he will accept in every project situation.

That means in future he will:

  • focus on the project scenario at hand
  • pay attention to his situational role
  • compare this role with functional descriptions
  • respect the boundaries of the role he is currently performing
  • behave and communicate according to the demands of the role.

This understanding of situational roles ensures orientation and decisiveness within the project.


We cannot control forces of nature like storms and mist. But we can change things that are in our working environment. Often it is the small things that make change possible. Clearly defined and well described project goals, simple and realistic processes as well as an understanding of roles help us to find our way in the large forest. We are capable of ensuring clarity, safety and orientation.


Annette Berger is a project manager and systemic coach. She provides clarity and orientation through her project workshop. She places particular value on creating an understanding of situational roles.

EN Subscribe to our newsletter
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *