This must sound like one of driest and dullest blogs possible, but bear with me. I was faced recently with an example where it was suggested someone’s time would be far better spent on designing a project than completing a business case for it. This is, I'm sure, a conversation many people who support robust project management will have had, and I'm sure one I'll have again. I'm certain a quick Google will reveal lots of webpage’s commenting on the validity of such a comment from a pro / con of project management status, so I won't delve deeply into that discussion here. Rather, I'm intrigued as to why this comes up at all.
I doubt you'll find many people who suggest project management is a waste of time, and yet the difference between acceptance that project management should be applied and that formal project management should be applied could hardly be more diverse. Getting people to buy-in to project management documentation is the grown-up equivalent of getting your children to eat their greens. Why’s it so hard?
Formal project management documentation takes time to do, no matter how slim it is. I've used pure PRINCE2 templates and some heavily slimmed down versions, and all of them need thought. That in itself is part of the point: they make you think about some things that might otherwise bite you in the proverbial later. Not spending that time might well cost you an awful lot - in time, money, and reputation - in the long run, but a) it is only "might cost you", and b) you definitely save time from not completing formal documentation in the first place. Even so, it’s not hard to find well-respected books and materials that argue that formal project management is ‘a good thing’ and will deliver a strong ROI on the time spent. There has even been formal research into it at the University of California (which you can buy if you’re really interested: The Benefits of Project Management.) Despite this general acceptance of benefit, though, people still play the lottery that they might get away with it, even on large, complex programmes.
Part of this is how psychologically we operate and rationalise some things. Simply put, if I succeed in my exam it's because I'm smart / brilliant / worked hard. If I fail, it's because I was unlucky with the questions, didn't feel well, or the course concepts were badly taught. We have a tendency to internalise successes and externalise failures. There is nothing abnormal in this; in psychology, this ‘self-serving bias’ is quite well understood and studied.
So how does this relate to project management and documentation? Let's consider a project manager who has been running projects for years without any documentation and a project manager who's also been running projects, but who has applied documentation like business cases and change control. Both project managers are successful. The one using documentation can internalise success here partly because they have used good standards of documentation. As success leads to learned behaviour, they'll continue to use it because it's worked before. In other words, they see that their decision and use of the documentation helps deliver success, so they keep using it. The 'by the seat of the pants' project manager also internalises the success as being due to their actions, but obviously this time it doesn't include documentation, and so the learned behaviour can partly be that they don't need it to succeed.
So far, so good, but what happens when the proverbial hits the fan? Both project managers are equally as likely to externalise the failure as not their fault and due to factors beyond their control. Where things differ with project management documentation is that the document-friendly PM will consider – amongst other things – whether the project documentation was robust. They won’t necessarily question their decision to use the documentation (which is quite correct), but they will consider whether the use and application of the documentation (an external factor) was at fault. This may lead to improvements in their use of project documentation, improving the probability of successful delivery of future project.
What the seat of the pants project manager is unlikely to do, though, is to consider that their approach of not using project management documentation contributed to the failure. This is because that would involve accepting the failure as being caused by them self. Perhaps the project failed because the requirements were not clearly understood. This is something that good documentation could relatively easily address, but the project manager is likely to attribute the project failure to the individual or group that misunderstood or were responsible for communicating the requirements to the project manager. That the manager could have used better (or even any!) project documentation to prevent this problem is unlikely to be high up on the list of considerations.
The problem this presents is in demonstrating the value of formal project management to sceptics, as both positive and negative views on it can be self-reinforcing due to how we mentally deal with successes and failures. Again, as success leads to learned behaviours, the longer a project manager operates ‘informally’, the harder the shift will be to accomplish.
At this point it is important to note that I’m making very broad generalisations; I’m discussing general trends in behaviours and approaches and these will vary quite a lot between people. One thing to note, however, is just because a project manager accepts responsibility for a failure or problem does not mean they are accepting it was their fault. I’ve seen many project managers accept responsibility for problems, but never question their view that it was a factor beyond their control that caused the problem; I know, because I’ve done it myself. Whilst the acceptance of responsibility is always good, the lack of reflection about the problem’s cause and their own part in it is not; unless the issue truly was outside their control, they have an opportunity to learn from a situation that may happen again. Without learning, the failure may happen again too.
So what are the practical ramifications of all this? First, success reinforces behaviour, so if a project manager runs a successful project with documentation they are more likely to use it again. The same holds true for a manager that doesn’t. As formal project management is hardly something people do instinctively, good practice has to be taught, and because people repeat previous behaviours, it needs to be taught as early as possible in a project manager’s career. Good training is vital. Secondly, project managers must be encouraged to produce lessons learnt reports at the end of a project. Lessons learnt are not only there as a cataloguing tool for the file, but also offer a very useful opportunity for the PM to sit down and reflect on the project. This ‘thinking time’ is probably more useful for the project manager to reflect themselves than the resulting lessons learnt document is to the organisation that employs them.
The greatest benefit a company-wide approach and requirement for project management brings is that it compels the use of formal techniques that might otherwise be ignored. Whilst this will help embed good practice in a “catch ‘em young” way for new project managers, the real benefit is to those old hands that are also the most likely to object to and resist a corporate implementation. As we have seen, it can sometimes be these project managers that need such an approach to help them overcome their own way of thinking.
