Examples of Poor Project Management - Not Seeing the Woods for the Trees

In this article I explore one of the most common reasons for poor project management. Writing the article was prompted by a short piece of consultancy I recently did. I was asked to help a client sort out some trouble with one of their projects. We all know that projects can go wrong for many reasons. In this case it did not take long to work out the cause of their difficulties. The objectives and the scope of the project were unclear. Without clear objectives and with an ambiguously defined scope, trouble is bound to occur. Let’s look at why this can happen.

The trees and the wood

In theory, having unclear objectives and scope is a very basic mistake for a project manager. Yet I am often surprised by how commonly project managers, project sponsors and team members cannot, convincingly, tell me the objectives of the project they are working on. If I am honest, when I reflect on the projects I have been involved in over the last few years, there are some that I was not completely certain what the objectives were.

Why is this? There are a number of reasons, but they are best summarised by the English expression “not seeing the wood for the trees”. For those who are unfamiliar with this expression, it simply means that you become so focused on the details that you lose sight of the big picture.

Projects are full of details, and one of the skills of a good project manager is to be aware of sufficient detail. But understanding detail should never be done at the expense of losing sight of the overall rationale for and direction of the project.

The big picture logic of projects

There is a simple piece of logic for me in any delivery related activity. This logic says that the order of thinking must be to answer certain questions in the following order:

  1. Why are we doing the project? Answering this question enables you to define objectives.
  2. What are the boundaries of the project? Answering this enables you to define scope.
  3. What do we need to develop to achieve the objectives whilst remaining within scope? Answering this enables you to define the deliverables.
  4. What actions need to be taken to develop the deliverables? From this you can get on into resourcing and planning.

In reality, these simple questions hide a lot of complexity. Each question can spin off much more detailed analysis. Understanding the objectives and scope of a complex programme can be a project in its own right. It is also not a simply linear process of answering the questions. There are feedback loops making trade-offs balancing, for example, the resources available and the scope of the project. But nevertheless this high level logic still holds.

We often become so focused on the complexity and details that we lose sight of this simple logical flow: Objectives -> scope -> deliverables -> activity -> resources -> plan.

We try to keep control of many individual activities in the plan, and forget to keep our eyes on the objectives.

Identifying flawed projects

No matter how well you understand your plan, unless you can trace what is in the plan back to your original objectives then the plan is flawed.

When I am asked to review a project I always start by enquiring: what are the project’s objectives? And please explain the scope of the project? If a project manager cannot, meaningfully, answer these questions then I know the project either is in trouble or will be soon. Additionally, if key project team members cannot also answer these questions, consistently with the project manager’s answers, then I also think the project is likely to be in trouble.

The reality is that it often takes an outsider, (not necessarily a consultant - it could be a project manager from another project), to see that a project does not have clear objectives or scope. This is a problem I see time and time again and is one that all project managers understand. So why do we fall into this trap?

Falling into the trap

In the urgency to make progress, and probably as important, to be seen to be making progress, we often jump into the project without being clear about objectives. We are all familiar with the reality of working in a business. Budgets are set and commitments made long before a project is planned. It can therefore seem that we just need to get on delivering as soon as the project is really started.

This is always a mistake. Unless you are clear about the objectives and have a complete and unambiguous scope it is unlikely that the project will be a success.

You don’t have to just know the objectives at the start of the project, you must keep them in mind as you deliver. There is a tendency for projects to slowly veer away from original intentions. We have all seen a project completing a year or two after it started, apparently a success but not delivering the outcome that was expected at the start.

Of course, there are situations in which the objectives or scope are not easy to determine. The solution is not to progress the project in spite of this, but to see clarification of the objectives and scope as the first phase of the project. It is not until these are understood, that a plan and budget can truly be finalised.

If there are issues with objectives and scope that cannot be resolved, assumptions can be made. But it is critically important that these assumptions are managed as risks upon the project. Additionally, the objectives and scope are key parts of the project you must maintain and keep under change control.

Defining objectives and scope

In my experience, the best way to determine objectives and scope are by structured questions - documenting the result and getting it reviewed by the project sponsor and key project customers. There are examples of the sort of questions you can ask in two of my books The Project Manager, Mastering the Art of Delivery (chapter 3) and Brilliant Checklists for Project Managers (chapter 5). I’d happily put an example of such a list of questions on this site if there is sufficient interest from our readers. Let me know if you would value this.

I’d be really interested in hearing your views on how common you think projects are being undertaken without a full understanding of objectives, why you think this happens and any tips you have for clarifying the objectives and scope of a project

Related content:

Examples of Poor Project Management - Introducing an Intermediary between the Project Manager and the Client
Examples of Poor Project Management - How Not to Involve Your Project Board & Stakeholders
Six Symptoms of Poor Prioritisation
Bridging the divide: project and change managers in business


This reminds me of a quotation I head on the radio this week http://www.bbc.co.uk/programmes/b00x9xjb about project complexity. They were talking about the Kolmogorov complexity for sires of numbers. This states that the more words you need to describe a series of number the more complex it is. So 101010 is simply "zero and one repeated three times". Whereas 1001001000 is "one one and two zeros, repeated twice followed by three zeros".

It occurred to me that the true is same for projects, the more words that are needed to completely describe the project the more complex the objective. Take the 2012 Olympic in London. Open the stadium by August 2011 is a very simple objective. However try to describe the forms of economic legacy in less than a paragraph shows how complex the legacy objective is.

Really great points - building on, but going beyond the essential point of my article. Thanks. I have some comments in return.

Your hypothesis about length of objectives is interesting. I suspect you are essentially right, although I don't think length of words can be straightforwardly compared to length of a numerical value. I would agree though, that the more words that are needed to describe the objective the more the project will tend to be complex. But the important word in this sentence is "needed". I often find people describe objectives that are unecessarily complex - and when you really challenge a lot of the stuff they add in is not necessary. My general view is that when an objective has the word "and" in it several times, it is not one objective but several - and quite often this is best achieved not in one project but several.

Your example of the Olympics is brilliant. Most business projects are much less complex than the Olympics - but its a good analogy. Often the project manager is working towards an objective in the form of "open the stadium by August 2011", whilst the sponsor is thinking of "leave a lasting legacy". The result is that no matter how well the project manager achieves the first objective, the sponsor is unlikely to be satisfied. It also, in my mind, dramatically changes the nature of the project.

An equivalent in business is when a project manager is working towards creating some deliverables - whilst the project sponsor and customers are thinking more in terms of a business outcome.

Dear Richard,

I have recently joined a new project. I am currently reading your book, "The Project Manager, Mastering the Art of Delivery" and used one of your checklists, the one concerning scoping a project, in order to explain to my superiors why I need more time to deliver a plan and schedule I could commit to. Maybe you will be suprised to find that...it did not work :). My request went unnoticed.
I would be quite interested in receiving more pieces of advice on how to push back in such situations, moreover when the pressure to have a clear schedule asap is coming form multiple, relevant sources :).

Many thanks!

I am not surprised, but a little disappointed. There are no perfect approaches that work in absolutely every situation, only approaches which tend to work in most situations. It’s very difficult to comment helpfully on your situation without knowing you, your style of interaction, your customer, your relationship with your customer and the nature of your project. All of these factors play into whether an approach will work or not. But let me at least give some thoughts.

Why might this not work? Well it might not work because your request was unreasonable, or because you asked in the wrong way. When we have to make a request, which a project customer is not going to like, there are better and worse ways to make it. One thing I would always try to avoid is positioning a decision as an ultimatum. I always try to give the customer choices, saying something like: "this project can be run in two ways – way A, which has these implications ... or way B which has these implications ....". Giving choices, even if all the choices are suboptimal from the customer’s viewpoint, makes the customer feel as if he/she is still in control.

But let’s assume for now that your request was reasonable, you asked in an appropriate fashion, and the issue lies with your customer.

Customers refuse change requests from project managers to time, cost, quality etc for a number of reasons. One reason is a macho style of management, which tends to act as if any agreement to change a project is the start of a continuous slide to disaster and a sign of weakness. If this is the case then you need to develop trust with your customer, such that he/she understands that one request does not mean you will come back every week and ask for further changes. I’m afraid though, there is no foolproof answer for the unreasonable customer.

Another reason is that the customer actually disagrees with you. Then all you can do is try to understand the logic of his/her argument and try to slowly convince them that you are right.

A third reason is that the customer has made a promise to someone else, based on an assumption that you will deliver your project. The customer does not now want to back out of that commitment. In this case, try to find out if there is some way of meeting his/her promise without delivering the full project.

Finally, some customers accept what you say – but will not tell you this, simply because they want to keep the pressure up on you.

There are probably lots of other scenarios that can be built up. The point I am making is that any technique works based on an understanding of your customer. Building a relationship with a customer such that they trust what you say, listen to your advice, and you know where they are coming from, can take time. Building such a relationship happens across the project – or possibly across multiple projects. It is always important to bear in mind, that a customer asking for the impossible does not make the impossible happen. A good project manager makes a significant increase in the probability of successful delivery, but is not a magician. In the end it is the customer who suffers if he/she does not listen to the project manager.

I often use these sorts of words with my customers. I set out a bargain of the form: "I can really help you to deliver your project, but it is a partnership and you must play your part. I’m not a magician, and sometimes I will have to come to you with hard decisions. All I can do is give you some choices with implications, and then use my full skills to deliver what we mutually agree to."

I know this is probably not a full answer, but I hope it is helpful.

Dear Richard,

Actually, it was extremely helpful and I think I now know where I was going wrong.
In the first part of my experience as a project manager I was playing also, without realizing it and without paying too much attention to it, the role of business analyst. Because the domain I was in did not really have a clear split between responsibilities, being a very new and unknown domain, I always tried to impose my position as also the "expert" let's say. Because my knowledge on the subject was the most extensive in the project team, the decisions ultimately stayed with me, so I disregarded the fact that I am only the project manager and I should give the client alternatives. I did what you advised, I presented options to the client and now I am at least a step forward in the process and working to document both options available, in order for the client to make the best decision. I am confident that the test cases I am building will help the client make the best decision and I now know "my place". It is yet an exercise to me, I have remind myself that I am not the expert and that I am only "the facilitator", but I think I am on the right track :), so THANK YOU VERY MUCH!

Best regards,

Hi Ana

I'm glad it was helpful. I think you have picked up on some really great points for all project managers. We all like to experts as it is a comfortable place to be, but as project manager we are often acting more as a facilitator. We don't own the requirement, we don't own the solution - we own the process of getting from one to the other. It's helpful to have business analysis skills, but the role of a project manager is not to be a business analyst.

A different way to consider it is that we may not be the subject matter expect (although it does really help to have domain knowledge) - we are the experts in managing projects.

- nice2 - sales1