The Canadian economist, John Kenneth Galbraith is credited with coining the phrase “The Conventional Wisdom”. This means concepts that are assumed to be true because so many people believe them. In general, we spend most of our lives happily conforming to a set of conventions that we rarely, if ever, question.
Here on the seafront, Velopi likes to ensure that the material it provides in courses, such as its Project Management Professional Exam Preparation offering, are based on sound principles. Because of this, every so often someone in the office asks what seems like a blindingly obvious question – but one that often fails to find an obvious answer. Today, as we welcome in 2016, we ponder over another of these philosophical questions: why do we plan projects?
Trained project managers will, at this point, roar with laughter – planning has become second nature. But is this just Conventional Wisdom, or have we genuinely good reasons for spending so much time on this activity? Well the Project Management Institute seems to think so: In its Guide to the Project Management Body of Knowledge (PMBOK© Guide), it lists no fewer than twenty-four planning processes.
But, given that all projects have some unique aspect and often projects have a research element, making accurate planning difficult, would we not be better off just getting stuck in and working things out as we go along? Certainly, this has been standard practice in many software development companies, where prototypes are often wrestled into commercial products after much debugging. They argue that the pace of change is so fast they just do not have time for planning. Interestingly, they seem to have all the time in the world for fixing these products when they do appear.
For project managers, what is lacking here is evidence. While the ad-hoc approach has led to amazing scientific discoveries, the results of such projects often are not what were expected. Without plans, we are unable to determine if we achieved what we set out to achieve. Another issue relates to expectations. If the boss sets a team off to develop a new product, are we supposed to come up with a prototype or proof of concept? Or do we need to go further and optimize the product for manufacture and easy maintenance? A clear scope statement, where the exact deliverables to be provided are explicitly listed can save a lot of argument at the end of the day.
Some customers are adept at exploiting vague requirements. They sign off on a set of requirements that are neither testable nor measureable and then, when the project is near completion, they look at what they are getting with surprise and disappointment: “But I assumed that this would include …” How many companies have seen their profit margin wiped out because they did not state clearly what was in and what was out of scope? The problem here is: if no one said something was out of scope, then we cannot argue the case at the end of the project – we have to meet the customer’s expectations. However, if we state at the outset – during the scope planning work – that something is not included, the customer has to ask for it explicitly. This gives us the opportunity to charge for the extra work – a much happier outcome.
The schedule is another area where we might question the need for planning. This is especially true when an inexperienced team embarks on a series of tasks that it has not attempted before. Realistically, how can they estimate how long this work will take? Again, project management shows how Project Time Management can help, even if we do not estimate. Our work breakdown structure has divided the project into more manageable work packages. Now we need to break these down further into schedule activities or tasks. This effort alone – determining exactly what needs to be done – can show up serious gaps in our thinking. However, the next step in the process – sequencing the activities – allows us to include mandatory and discretionary dependencies. A network diagram with no estimates can show the amount of parallelism in the project and where extra staff can help accelerate the work.
Relating the requirements to the work breakdown structure and then tracing them through the schedule, allows us to show how requirements were met. And this is really the crucial element of planning: providing evidence. If there are any complaints at the end of the project – a customer reluctant to accept the product, service or result for instance, or a project sponsor who regards the project as a failure – a sound set of plans will allow the project manager prove that the work was actually done. Even in a project where uncertainty is high, planning helps. Setting up an effective change control regime will facilitate change while still remaining in control.
Even without exploring all twenty-four planning processes, the case for project planning can be made. So it is safe to say that project planning does not come under the heading of conventional wisdom; it is wisdom, full stop!