Project Management Basics

Project_Management_Guide

There are many ways to manage a project and when thinking and selecting the right methodology, thought must be given to project complexity and how critical it is to the stakeholders.

For example, the approach adopted when conducting a large civil engineering project such as the Cross-Rail link in London which followed a methodology called Prince2 is quite different to the approach required to manage an upgrade to an office environment.

The key to getting it right is to pick an approach which matches the rigour necessary to fulfil the project demands – too loose and things get dropped; too tight and the project gets suffocated with bureaucracy.

What follows is a set of general principles which will help all of the stakeholders to decide on the right approach for them.

Principle 1 – Clarity of Outcomes

For all projects, there are three key variables

  1. The project deliverables themselves, comprising key activities, tasks, sub-elements, dependencies, standards and verification/testing requirements
  2. The time required to complete the task, whether measured against completion dates, milestones, integration points or elapsed time from another event
  3. The budget available, often a function of the time required but also allowing for other fixed and variable costs which need to be covered along the way

So, the Project Manager (PM) needs absolute clarity about all three variables and is expected to receive/coach/ negotiate all three with their sponsor or client.

Smart PMs get this done, agreed and recorded at the outset and the term project scoping is often used to describe this process. The PM is also mindful of the SMART checklist for defining things thoroughly….

S – Specific

M – Measurable

A – Agreed

R – Realistic

T – Time framed

But PMs also need to avoid the pitfall of fractionalisation – the tendency to over divide a task into a huge number of smaller tasks which will confuse or overwhelm project contributors and/or other stakeholders.

Principle 2 – Project Planning

Knowing the project tasks is not enough if the PM doesn’t understand the task dependencies and build contingencies into the project plan so that if things do go wrong and they will, there is adequate time to bring things back on track.

This involves actively doing risk assessment – identifying potential problem areas, also known as Potential Problem Analysis. This involves building preventative actions into the Project plan to reduce the probability of an event occurring and mitigating actions to reduce the impact should that problem occur anyway.

Inexperienced PMs often treat this part of the process without the necessary rigour and are often surprised when things do happen – ‘I never saw that coming’ or ‘that was unforeseeable’.

Even more sophisticated is a process called Potential Opportunity Analysis, where the PM looks at the plan to identity opportunities to exploit or accelerate.

All of this means that the PM has to understand how to estimate effectively or be able to turn to experts who do. Poor estimating is at the root of many disasters in the project management world.

Whilst completing the project plans, the PM may start to realise that the specification for the project is too ambitious for either the time line or the budget and they then need to ‘reset expectations’ with their sponsor or client – sometimes this may mean reducing the specification or sometimes there is an agreement on a later completion date or budget extension.

This part of the process involves Configuration Management and again the PM should get the changes agreed and recorded along the way.

Where the specification is reduced, it is inevitably because there has been a process of prioritising and there are many options for doing this…

Must/Should/Nice – keeping the essential pieces in place, working to preserve the ‘should do’ items as far as possible and being prepared to dump the ‘nice to have’ elements.

Seriousness/Urgency/Growth – based upon the Kepner Tregoe model. Each deliverable is assessed according to it’s SUG profile and those elements that score highest are retained and those that are scored lowest are dumped – a technique famously promoted by NASA.

Cost/Benefit or Strategic Fit/ Implementation Difficulty Matrices – plotting each deliverable onto either or both of these matrices highlights things to focus on and things to dump.

Whatever the approach adopted, it is ESSENTIAL that all of the stakeholders use the same approach to prioritising – adoption of different frameworks within the same team will be just as problematic as using ‘gut instinct’.

The project plan itself should be graphical rather than verbal as the human brain can better comprehend complexity of activities and their interdependencies when they are presented this way. There are many software packages available to do that. Some tools will produce simple graphical Gantt Charts like this…

Project_Management_Gantt_Chart_Example

Other tools favour PERT Charts which often incorporate Critical Path Analysis like this…..

Project_Management_PERT_Chart_Critical_Path_Analysis

But beware that some software tools available purport to be suitable for project management but are little more than ‘things to do lists’ which are unhelpful for complex projects.

In most circumstances the project plan will in some way need to adjust and adapt to what is actually happening in reality over time – frequent resetting of the project plan usually means that the client is being unreasonable or the PM is incompetent.

Advice on upgrading of the skills of a PM can be found at

Principle 3 – Project Monitoring and Control

A project plan that stands any chance of success has to be carefully monitored so that where there are deviations from the plan, they get quickly identified and remedial actions quickly put into place.

On smaller projects, the PM might be able to keep their eye on everything and are then likely to be able to monitor quite easily. But on larger projects that will mean that the PM will have to focus on some items quite closely whilst remaining at arm’s length with other items.

Where that is the case, best practice is for PMs to adopt the Pareto Principle – they should focus on the smaller number of ‘mission critical’ or ‘high risk’ items and either ‘do (quickly), delegate, delay or dump’ the rest.

Project control is achieved through intervention – telling the project contributors that what they are doing isn’t what was expected or chasing them for completion.

Principle 4 – Project Communication

At the very core of all projects should be a structured and agreed process of communication which is designed to report on the task and build the relationship between the PM and the project client – best done face to face.

Task reporting should be done to an agreed timetable and can follow a number of formats and here are three which are commonly used…

RAG reporting – a written bullet report from the PM to the client using a traffic light system where red issues are current problems, amber issues aren’t yet problems but might become problems and green issues are all OK and therefore only needing minor discussion/consideration.

SWOT analysis – a written breakdown of the project and where it lies on a SWOT grid – Strengths, Weaknesses, Opportunities, Threats. This technique has many other business applications.

Exception Reporting – Often incorporated into Prince 2 methodology, exception reporting is the written process of flagging in advance just those items which are expected to happen outside of the project plan.

The formal Project Review Process should be agreed with the client in advance and only deviated from in exceptional circumstances – if the principal players can not attend for whatever reason, a deputy should be briefed and go in their place.

In addition, these project review sessions should be used as an opportunity to reassure the client and create a sense of trust between the partners. Forums which allow for questioning and probing and challenging by the client should be encouraged by the PM because in dealing calmly and professionally with the issues raised, it is normal human nature for the client to become reassured and progressively impressed by the PM.

Principle 5 – Project Accounting/Administration

Perhaps the least glamourous task for a PM – on bigger projects the PM will normally seek to appoint a Project Administrator to do the work for them.

The work involved typically involves….

  • Managing project finances, booking codes, internal cross-charging, external invoicing, financial queries and reports etc
  • Regulatory work – certificates, test reports, quality compliance documents, security documents, sign-offs, commercial documentation, legal documentation etc
  • Project records – vary according to project type, but essentially a written trail of meetings, decisions, answered queries, configuration changes etc

The general principle of ‘document something and you won’t normally need to rely on it’ is good advice for all PMs and final perceptions of project success can be detrimentally affected if this final component is not satisfactorily completed.

ULTIMATELY PROJECT MANAGERS HAVE TO DECIDE…

ARE THEY WORKING ON THE PROJECT OR IN IT?

Working_On_The_Project_Or_In_It

Copyright: © Clive Weston, The Hartwell Consultancy, 2020


Please contact us if you’d like to find out more, would like support or want to comment on this subject.