Skip to content
Our website will be unavailable from 17:00 GMT Wednesday 20 November until 9:00 GMT Monday 25 November while we carry out important upgrades.

If you plan to update your membership, book an event or access APM Learning, APM Community or use other resources, please do this outside of these dates.

The 15 November Chartered Project Professional submission date is unaffected.

Thank you for your patience.

Formal vs informal project management

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

When I work with those new to project management a popular topic of discussion is why we need formal project management methods at all when we have spreadsheets and so many handy little apps to help us keep on top of our task lists. Those types of questions, themselves, indicate that those people have probably never had to manage a complex project with a spreadsheet and an app. Even a very well-organised project manager with the best of intentions could quickly get into trouble on larger or more complex projects without following some well-defined processes.

After all you may have your neat task list with deadlines and milestones marked up on a spreadsheet, you may have an online tool for communication and everyone is fired up and enthusiastic to get started. But that is at the beginning of a project when all seems rosy. 

The problems with not having a formal project management method start when the real problems start, and we all know that projects always have problems. This is not a reflection on the people doing the work it is merely an inherent part of what projects are. They are doing something new and different, and breaking new ground will never be easy.

That is exactly why formal project management methods require you to clarify roles and responsibilities, establish a risk and issue plan, define the project scope. 

  • The accumulated knowledge of experience on large and complex projects shows that there will be situations when no one is taking clear responsibility for an issue, where progress stalls because critical decisions are not being taken because there is a disagreement and it is not clear who has the authority to make the required decision.
  • Risks will always be present in projects and they will occur, to a lesser or greater extent, on all projects so some planning in advance on how the risks can be mitigated and formal management of those risks will minimise their impact. And, similarly issues will arise, for instance a particular task has over-run the time allocated to it to the point where it is having a detrimental effect on the success of the whole project. In situations like this being prepared will ensure a better decision is made on how or if to move forward. 
  • Project scope will always be hard to define completely and accurately at the outset yet it still needs to be defined in terms of the business case and reviewed and modified in terms of the business case to avoid scope creep. To do this you need the formal process of change control.

And when you have these situations a bunch of emails or app communications and a few spreadsheets will not help you to make the best decision and progress your project in the most effective way.

That said, there are situations where "informal" project management can be what is required but by informal project management I do not mean the abandonment of formal processes and procedures but instead informal communications and discussions outside the formal procedures and some flexibility about which formal procedures to use. Because sometimes flexibility and a dynamic approach are necessary to get over a hurdle and it is the project manager's job to know when some flexibility is required and when it can have a positive effect on the project outcome. Equally it is their job to know when sticking rigidly to procedures can have a negative effect of the project.

Formal methods give us the accumulated knowledge and tried and tested processes we need to manage and control a project but also enable us to have some flexibility when necessary. So the clear advantage of formal project management is the clarity it provides of what, how and by whom work will be done but it should not be viewed as a rigid strait jacket imposing processes where none are required but instead as the perfect combination of formal and informal approaches.


This is a project management fundamentals blog written and sponsored by Parallel Project Training

5 comments

Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Uriel Lopez
    Uriel Lopez 14 September 2016, 01:35 AM

    Very good points, but to define the method that should be used, we must analyze the type of project, some need to be rigid so it is more effective to use the formal method because it is better to follow the different rules and established methods to avoid problems in the project and have perfect control. But in general, clearly the formal and informal methods need a complete balance as it must have both flexibility to solve problems, as control using established techniques and methods.

  2. Boyko Boev
    Boyko Boev 01 August 2016, 02:11 PM

    The article expands my PM vocabulary. If I understand correctly the difference between formal and informal project management is in the manner of controlling the project environment.  In the formal type we apply formal processes and techniques, while in the informal, we do what we feel we should do. I wonder if we can speak of project management at all when the processes and techniques are not formal. Is it the same as medicine and law? Why do we think that medicine and law must not be informal but project management could be?

  3. Paul Naybour
    Paul Naybour 01 August 2016, 06:14 PM

    BonkoI wouldn't go that far some simple projects do quite well with informal project management. It's a matter of matching the level of formality to the risk.

  4. Michael Groves
    Michael Groves 28 July 2016, 02:25 PM

    Paul - thanks. I found that a timely and interesting article.  It would be good to be able to quantify the difference that applying a formal method makes. Can you direct me to any appropriate data?You're right, there is a judgement call we need to make as PMs about when to apply process. We'd need to think about the risks to consistency but I'd also argue any application of new process should be weighed up against the risks of stifling innovation opportunities and increasing bureaucracy. But as you say, that's what we get paid for!

  5. Paul Naybour
    Paul Naybour 01 August 2016, 06:11 PM

    Some data comparing formal and informal methods would be good in theory but really hard to collect in practice. The best we have in anecdotal evidence from projects that go well, typically these follow a simple but effective project management method.