Smashing the Rules of Project Management – Part 2

Part 1 of ‘Smashing the Rules of Project Management’ introduced the idea that many tongue-in-cheek touches of sarcasm and analogies of project management might actually contain an element of truth, maybe even wisdom. Three rules in, this certainly seems to be the case. So here we are with part 2.

Rule 4: ‘Nothing is impossible for the person who doesn’t have to do it’.

There is a famous Pink Floyd lyric that talks about how army generals lead from the back (it’s on Dark Side of the Moon if anyone is interested) and it’s very true of both project managers and managers in general. You should not expect your team to do something that you are unwilling to do yourself. This may include working weekends or even saying ‘no’.

It also highlights the importance of the project manager understanding the subject matter at hand. It’s no good to be an expert in a project management methodology and know nothing about the project and content that you have signed up to deliver.  

Rule 5: ‘The sooner you begin coding the later you finish’.

While this rule has a taste of software development to it, it is applicable across a number of industries and project types. When kicking off a project the temptation is always rife to get ‘hands-on’ as quickly as possible, whether it’s developing a new website or building the new garden shed. This can be a fatal mistake. The project team needs to properly understand the deliverables as well as carefully plan and understand the approach to create those deliverables.

Although it sounds obvious, understanding the sequence of events and project dependencies is also key. I am still perplexed by the amount of software development projects that start building things before any user requirements are gathered or the amount of restructuring projects that kick-off with no impact analysis or change management in place. The point is that time invested up front does have a good payback later on in the project lifecycle.

Rule 6: ‘A user will tell you anything you ask about, but nothing more’.

The previous rule spoke briefly about gathering user requirements as a predecessor to developing any solutions. As a task in itself, business analysis may not be directly applicable to a project manager’s responsibilities, but will, however, play a large role in determining the overall success of a project. Poor or non-existent business analysis has been the cause of many project failures and continues to be something that many projects consider an optional extra.

Even projects that do incorporate an element of business analysis are still at risk, often because business analysts don’t understand the subject matter (e.g. ERP, process optimisation, business intelligence, organisational design) or have little or no knowledge of the industry vertical. It is therefore critical when asking the customer questions that a business analyst discovers and elicits as much as possible – not only what the customer tells them. A business analyst needs to be so much more than a scribe for a wish list.

As we progress, it does seem that many things said in jest, do have an element of truth. Let’s see what part 3 brings.