Re-thinking the Project Planning Phase

When it comes to planning a project there are well-established collections of project management knowledge based on traditional methodologies such as those from the Association for Project Management (APM) or the Project Management Institute (PMI ). Such a “Body of Knowledge” places substantial emphasis on the importance of the planning phase. The phase includes not only scheduling of tasks but also managing risk, change and quality within a project.
And yet the growth of the Agile method, particularly for IT projects, suggests that rigorous adherence to completing the planning phase before starting on any other project work can be a waste of resources and worse, force the project down a pre-determined path that might prove to be unsuitable once the project is underway and there is a clearer view of how it will progress.
Many stakeholders on projects, IT or otherwise, are keen to see some tangible results early on and yet many weeks, or even months,  into some projects the planning stage remains incomplete. In simple terms on Agile projects some planning is done, then something tangible is produced and delivered, then more planning and further deliverables and so on. Whereas in projects with a more traditional approach the planning phase is performed thoroughly and completely before any work begins on the tasks that will produce a deliverable.
But is there a conflict between the Agile approach to project planning and more traditional methods? Could, in fact, the perfect solution lie in some compromise between the two? And is the best approach more likely to be determined by the type of project and less to a rigid adherence to a defined method?
Experienced project managers have always been able to take the best of any formal approach and combine it with the best working practises and personal experiences to develop a successful approach to managing projects. And whilst they recognise the usefulness of tools and processes they also recognise the importance of the people working on a project. And do not value detailed and complete documentation above anything else or demand a rigorous adherence to the plan. The best project managers are open-minded and flexible in their approach to managing projects and tend, in practise, to take an iterative approach to a project plan rather than a more traditional waterfall or linear method, which assumes that the plan was right at the outset.
Of course, this does not mean that the business requirements should not be detailed and complete and equally so for any technical and design specifications. And the more complex a project, particularly one where different, but dependent, tasks are running in parallel, the more the need for control and well-defined processes. A certain amount of control will be inherent simply because of the existence of requirements and constraints but giving some flexibility to capable individuals in carrying out tasks can lead to a more motivated team. The combination of capable, motivated teams is very often the key to successful delivery of a task or indeed the whole project.
So maybe there is room for controlled flexibility within the constraints of a proven method such as APM or PMP and rather than using formal project management methodologies as a rigid model for planning projects they can be used as an adaptable guide to assist in the successful delivery of a project.
 

Avatar for Paul Naybour

Paul Naybour

Paul Naybour is a seasoned project management consultant with over 15 years of experience in the industry. As the co-founder and managing director of Parallel, Paul has been instrumental in shaping the company's vision and delivering exceptional project management training and consultancy services. With a robust background in power generation and extensive senior-level experience, Paul specializes in the development and implementation of change programs, risk management, earned value management, and bespoke project management training.

2 thoughts on “Re-thinking the Project Planning Phase”

  1. Agile works in IT projects because you’re not building something physical – you can build things in many different ways, and in unusual orders – you can build walls before the foundations, and you can rip the foundations out and replace them even after the whole building is in place.
    It could be useful to take some agile methods from IT into the physical works, but I think you’d have trouble convincing an offshore construction team to just start building it without planning it. When a bridge span turns out too short, the consequences are huge!
    Simon

    1. Thanks for your comment Simon – you might be interested in a blog I posted a couple of days ago using the analogy of building a house compared with an IT project – you can find it on this Project Courses blog.

Leave a Comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Upcoming Courses

Scroll to Top