Formal vs informal project management
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.