We don’t need Project Management, do we?

Oh no! Not another project manager harping on about the virtues of Prince2 or PMP trying to justify their own existence…

Well no, and yes – a bit, maybe. This article is not really about the nuances of why tracking issues is key or that your project is doomed if you don’t stick to change control (yawn). Although all that stuff is important (and I might, reluctantly, touch on some of the subjects in future articles) this piece is about the various ways companies I have been lucky enough to work for or consult in have put an effective, repeatable structure and process in place so they can consistently repeat effective results with different types and sizes of project.

Example One

With the advantage of experience one employer benefited from putting in place a system that allowed everyone in the team to consistently deliver projects, enhancements and fixes quickly, effectively and smoothly. I can’t and won’t lay claim to being solely responsible, we had a fantastic team, many experts in their own right, a good ‘can do’ attitude and strong leadership. But are things better now we have a repeatable way of doing things? Undoubtedly. Are they perfect and can they be improved. No and yes.

First things first, if you don’t have good people no amount of project management is gonna help. So when you find good developers, testers, designers, product people or whoever delivers your ‘stuff’ keep hold of them as long as you can and make sure their skills are shared with the team (just in case they are offered a job in Mountain View, California in which case a decent pay rise is unlikely to sway their decision!)

Secondly, what is the group trying to achieve? It may sound simple but unless everyone is very clear on what the objectives are, they are likely to have similar but not exactly the same idea of the end goal. Achieving this normally requires writing it on a wall where everyone can see it, so they are constantly reminded. Spelling it out at the beginning of the project and repeating it all the way through is a must. Even though we do this, I often hear myself in meetings saying things like “hang on a minute, this is obviously a great idea and we will undoubtedly have to do this but let’s remember the primary objective is X which suggests that we need to add this to the next stage requirement” or something equally manageresse …

Also, you should note that it’s very easy for developers to get distracted when they are engulfed in the detail (as they most often are) so they shouldn’t be blamed for not seeing the big picture. After all they are being paid to get the detail right! It is up to the project manager/leader to remind everyone of the mission now and then and keep everyone on track.

So what changes did we need to make? Specs were good, dev was good and testing was good. Communication was not so hot so we started getting everyone together regularly and sending out regular updates. That way everyone knew what was happening and when. Documentation wasn’t great but this is easy to sort out if you have a central place to put it, make sure everyone knows who is responsible for what doc and provide templates. There doesn’t have to be loads of docs just the ones that are appropriate to the thing you are working on.

One very specific change we made was to introduce Change Control. Yes I know I said I wasn’t going to get into the nuances of project management and I am not. I am just pointing out that in this particular situation it was necessary. This was because significant changes were coming through and yet the customers still expected the project to be delivered at the same time and to the same budget.

If you ask a builder to put up a lean-to on the side of your house and then after the budget and deadline is agreed decide to make the walls brick, and then later add double glazed windows, oh and while we are at it, it won’t be that much more effort to make it two stories and then you might as well add a pitched roof… Well you can see where I am going, your builder is likely to scarper leaving once the money has run out. (Note: I know there are lots of good builders out there so please don’t waste your valuable time letting me know. This is just an example; I could have just as easily used a solicitor writing up a contract, or a dentist putting in a filling – you get the picture).

Of course changes are allowed but only if the costs (time, money, scope, resources) are acceptable. Anyway we are getting far too involved in the murky depths of managing projects, time to get back on track.

So the point is that this particular company were doing ok and by formalising a few key aspects and repeating and refining their techniques and processes we managed to put together a repeatable framework that made successful delivery more likely for every project now and in the future.

Example Two

A different, much larger company were also having delivery issues. However, this company had oodles of documentation very efficiently stored. Everyone contributed and all their deliverables were fully documented down to the last piece of code. There were regular meeting that everyone attended, notes were taken and actions recorded extremely efficiently. In short everyone’s work was fully planned out.

Moral was quite low though and good people were leaving. The general attitude was that “it takes ages to do anything”. What was being delivered was of extremely high quality but the company were never able to get their new ideas to market before their competitors and senior management were starting to notice.

To cut a long story short what was happening (as you can guess) was that project team members were spending so long documenting what they were doing and going to meetings to discuss what to do and how to document what they had done and what they were going to do next –they had very little time for the actual doing!

It seems obvious I suppose but if you are very close to a project and the current way of working these issues can be hard to spot and even harder to change. The solution in this case was to cut back all the unnecessary gumf and identify what was actually necessary to deliver the deliverables. After many meetings and lots of documentation it turned out that what had happened was that a previous project that had been a tremendous success had been used as a template. Unfortunately, the people, deliverables, timescales – just about every aspect of the current projects were different!

To make sure that this didn’t happen again, or that a future (huge) project didn’t try and deliver with the new cut-down process and documentation a “Delivery Framework” was created. One of the first steps in any new project would then be to assess which processes, documents, roles and techniques would be appropriate for this piece of work.

Conculsion

So what’s the point I am trying to make? Well in both examples, significant improvements were made to a delivery process that ‘almost’ worked. It would have been tricky for someone without project management experience to understand what the issues in the first example actually were. The second example was almost the opposite problem, there was far too much process and control needed to be scaled back at the same time as introducing the concept of flexibility!

In both examples the key was to make changes to the delivery processes that were appropriate to what was being delivered. This is where the skill in project management lies; in knowing which processes are important and which should be shelved for another time. Oh no, almost fell in to the trap of harping on about the virtues of project management again, better go for a beer quick!