Formal vs informal project management

Save for later

Favourite

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

default

Posted by .pnaybour on 22nd Jul 2016

About the Author
Paul Naybour is Business Development Director for Parallel Project Training. He is a well known speaker in the APM Branch Network, a Project Management Training and Consultant, working for Parallel Project Training. He also runs the PM news site Project Accelerator.

Comments on this site are moderated. Please allow up to 24 hours for your comment to be published on this site. Thank you for adding your comment.
{{comments.length}}CommentComments
{{item.AuthorName}}

{{item.AuthorName}} {{item.AuthorName}} says on {{item.DateFormattedString}}:

Share this page

Login or Register to leave a comment:

Recommended events

Open Exam - Risk 2

6 November 2017

Recommended blogs

Agility to succeed

4 October 2016

Agile refuses to analyse requirements beforehand – and thus declines to provide an initial certainty. This will probably always scare any stakeholder trying to understand whether or not they can show results to the board with the budget that they are granted.

Save for later

Favourite

Are you banging the wall rather than beating the drum?

4 October 2016

You have a choice. You can either muddle on, stand firm and fix it – or look elsewhere.

Save for later

Favourite

Recommended news

Save for later

Favourite

Save for later

Favourite

Join APM

Sign up to the APM Newsletter.