Managing the project
In order to create some form of standardisation in the ways in which projects are managed, many organisations formerly developed their own in-house project management methodology. In more recent times, a methodology called PRINCE2 has become a de facto standard in the UK and is increasingly being adopted around the world. PRINCE2 was originally developed by the UK government for its own use, but now has very many users in the private, public and not-for-profit sectors.
It is a guide to best practice in project management and is a structured approach to organising, managing and controlling projects. It is a generic approach for the management of all types and sizes of projects and has a reputation as a highly effective, process-based approach.
Other guides to managing projects and its processes and competences include the PMI’s PMBOK®, The APM’s Body of Knowledge, and IPMA’s ICB. See What else do I need to know about.
Monitor against the business case
Because the business case is the fundamental justification for undertaking the project, it is a document that should be reviewed regularly to ensure that nothing critical has changed. This should be done at least at the end of every stage in the project, but may be done more often – certainly if any significant forecast (duration, cost, quality) changes.
The business plan is not cast in stone and should be updated with any new information. What the project manager and, more importantly, the project sponsor, need to watch is whether any significant change alters the viability of the whole project. If it looks as if this is the case, then the whole matter should be taken up with the project board, who will have to decide whether the cost-benefit balance has altered and therefore what action to take. This could include
- Continuing the project with adjusted costs/benefits/quality/timescales
- Cancelling the project
- Changing the project’s objectives
- Reducing its scope
- Reducing its costs
- Suspending it to allow for more investigation time.
How do I prioritise what I/we do?
The obvious focus for prioritisation is the Critical path, because that is the determinant for meeting the deadline, so shifting resources from non-critical paths to the critical path is a way of keeping things on track. Care should be taken, however, not to disrupt other activities so much that they end up on the critical path and rapidly become the tasks in danger of being incomplete in time.
Watching the budget is another priority-setting focus. If activities/tasks or products/services start coming in over budget during a stage, then making savings elsewhere may become a priority. In the same way, quality may become a priority. In fact, a project manager has to keep his eye on many things and make judgements about what to prioritise, because each project is different.
An extremely important part of managing any project is to focus on the remainder of the project. The time used and cost spent to date are ‘sunk’ and can no longer be changed. The only thing that can be managed is the work yet to be done. Continuously re-forecasting final cost and time and making decisions to bring variances to plan back on track is the priority for good project managers.
How do I control costs?
Control the costs by watching the more expensive items in the budget. In particular, negotiate with suppliers to gain budget leeway on expensive items, and ideally all items. This is easily done in a buyers’ economy, but more difficult when the suppliers rule the economic sector. This means making sure that initial budgets are realistic and have been ‘market tested’ before work starts. Once the project is underway, it is clearly harder to control costs, as commitments are made through orders placed and so on. The nearer you are to the end of the project, the harder it will be to gain on the budget. The monitoring of commitments made is therefore much more important than the monitoring of actual cash flow.
How do I keep managing stakeholders?
By sticking to – or amending as needed – the Communications plan. Skipping or skimping on items in the plan – tempting as it might be under time pressure – usually leads to more problems than expected. Stakeholders can have a seriously negative affect on the success of a project.
This encompasses ‘politics’ with a lower case ‘p’ to signify internal, organisational politics and also ‘Politics’ with a capital ‘P’ to include external (usually governmental) politics.
Time spent on stakeholder analysis can help to avoid running into internal politics. But in some organisations they are endemic and often vicious. Good relations with the project sponsor can prove invaluable when you are picking your way through the minefield. But it pays well to remain alert at all times for signs of political activity in any areas that are critical to the project. Remember, this may occur within the project team, inside an external contractor’s organisation, or among your organisation’s management team. Keep your eyes peeled and your ears open. See also the topic on Political Intelligence.
In terms of ‘Politics’ with a capital ‘P’, projects don’t happen in a vacuum – they are often buffeted by external events. Such is the ever-increasing complexity of our world that what used to be called simply a PEST analysis has now become a PESTLIED analysis. Originally, a PEST analysis was the opening stage of a strategic review, based on the Harvard Business School model of strategy development, dating back to the 1950s and 1960s. Its purpose was to identify forces in an organisation’s external environment that could impinge on the development and deployment of a successful strategy. The key influences were seen as political (P), economic (E), sociological (S) and technological (T) – hence the acronym. This research and analysis was then followed by a SWOT analysis (strengths, weaknesses, opportunities and threats), which analysed the organisation itself and its ability to cope with its changing environment.
Both forms of analysis are still in widespread use today, but the intervening years have added four new factors that play a big role in the external context in which organisations operate – the legal framework (L), internationalism (I), environmental issues (E) and demographic factors (D). Hence, PEST or PESTLIED. A PEST analysis can highlight potential problems ahead of time.
While organisations may make use of this tool, it still seems relatively rare for programme or project sponsors or managers to find the necessary time to use it for their own specific initiatives. Yet the environment in which a programme or project is to be managed has a great deal of influence on the likelihood of success. While doing a stakeholder analysis, or trying to tie down user requirements, are important parts of managing a project, casting an even wider eye on external influences can be vitally important.
Applying a PEST analysis is a simple and convenient way to do this. What works for the strategic management of an organisation should work just as well for the effective management of a programme or project. And it doesn’t take much imagination to convert the broad concept into a programme or project-specific tool.
How do I review progress?
Reviewing progress is a key part of the project manager’s role. It should be done regularly and reported at regular, agreed intervals to the project sponsor and board. Progress measurement takes two forms:
- How are you doing on time?
- How are you doing on money?
This involves ascertaining where you are relative to where you budgeted to be at this time. Good progress reviewing processes report on both: have we carried out the volume of work we forecast at this time (in other words, are we behind or in front of the programme), and has the work done to date cost us more or less than we budgeted for (in other words, are we under or over budget)?
Progress is ascertained by asking work package managers, team leaders and other project management team members about their progress, but also through MBWA – management by walking about – to see if the feel of progress matches the actual numbers being reported!
Remember that progress reporting to date is a passive form of control, as the time and money spent to date is a sunk item and cannot be changed! We therefore need to re-plan the rest of the project, looking to see if the trends to date will continue and whether there are new opportunities to gain time and save cost between now and the end of the project. We then report on the likely new end date and final budget for the project, with recommendations, if major changes are necessary. It is the decision-making around this forecasting information that is the active project control.
How do I ensure the benefits will flow?
You can ensure that the benefits flow by meeting the project’s objectives in full – ensuring that the output is ‘fit for purpose’. But since benefits usually flow after a project is complete, it will be others who are responsible for actually making sure that they are gained. Working with the customer/users and any ‘change agents’ through the project’s lifecycle will help this process.
Don’t forget that anyone who wins a reputation for running projects that reap their expected benefits will prosper. So, while time spent working with these stakeholders may not directly help the project’s delivery, it should be rewarding in other ways.
What decisions will be necessary?
Decision-making is an integral part of project management and making the right, or good, decisions can make all the difference between success and failure. ‘Business as usual’ is normally conducted along lines and within policies that are established procedures within the organisation. Projects, by definition, are one-off activities that are ‘out of the ordinary’. This is why so many decisions are necessary.
There are too many to list here, but decision-making covers everything from the composition of the team to the choice of external contractor, and from what priorities should be set to the tolerances that are acceptable on time/cost and quality. Decisions are involved in the business case, the budget, estimating, fixing the quality standards necessary and so on.
The most critical factor for project managers about decision making is its timeliness. Waiting for decisions, particularly by others, can be a frustrating cause of delay for a project.
Who takes what decisions?
The board or its delegated authority makes the decision as to whether to invest in the project – or not. They also, ultimately, should make the decision to continue or not in cases where the business case no longer justifies the project and/or overrun or overspend on the project cannot be recovered from forecast benefits.
Decisions on the scope and quality of deliverables usually rest with the sponsor or project board or, in extreme cases, the organisation’s main board. These usually come into play when forecast project overruns mean that the project has to be de-scoped or that the quality of deliverables has to be reduced in some way.
Decisions on the project plan rest with the project manager up to the point where changes would put the end date, the final cost, the project’s scope or quality that could be achieved outside agreed tolerances. At which point, decisions revert to the sponsor and/or project board.
In a matrix style of project organisation, the split in decision-making between the project manager and the line manager (lending his/her resource to the project) is usually that the project manager decides what, when and how much for each task, while the line manager decides how we do things around here and the level of quality in terms of the resources used.
What sorts of reports are necessary?
Unfortunately, for those who don’t enjoy writing them, reports are also an integral part of project management. They are essential, but should always be used within reason or everything becomes simply too bureaucratic.
Generally speaking, they come in two forms:
These help decision-making. For example:
- Feasibility reports help determine whether the project’s objectives are viable
- A Project Initiation Document (PID) brings together the business case, the budget(s) and the project plans before the project begins
- Exception reports inform the project board that the project is about to exceed its agreed tolerances
- End Stage reports confirm the stage has been completed successfully and lay out the plans and budgets for the next stage.
These keep stakeholders up to date. For example:
- Progress Reports (or Highlight Reports in PRINCE2) report on the current status of the project and forecast completion
- A Lessons Learned report records what lessons have been learned during the course of the project so that other projects can take account of them
- The Project Closure report reports on whether the project has achieved its objectives and recommends any follow-ups after the project is closed.
Who do I report to?
This very much depends on the role you are fulfilling and the type of organisation you work for. If it operates matrix management, then you may have two separate people to report to – your usual line manager and someone connected to the project. If you are a team member, then you report to the team manager (who may, or may not, be the project manager). If you are a team manager, you report to the project manager. If you are the project manager, you report to the project sponsor and the project board.
Who should report to me?
For the duration of the project, all full-time project team members report to the project manager, who is responsible for allocating their work to them, watching over their progress and helping them to develop their project skills. The project manager usually assists the line manager by helping with individual appraisals, either by attending or carrying them out or by providing data to the line manager about their performance. Usually, except on major projects, the project manager is not responsible for their pay and conditions of employment.
In the case of part-time team members, the member has two reporting lines, as described in the section on decision-making, above. In the case of these members, the project manager provides data to their line manager on their project performance for their formal appraisal.
What do I do if things start to go wrong?
First, and critically, understand why they are going wrong. Don’t rush off to the project sponsor or the project board with a tale of woe. They will likely say ‘Don’t bring me a problem, bring me a solution’. It is an easy error to make – you find something has gone (or is going) wrong and you feel an overwhelming desire either to hide it (usually a fatal error) or to quickly tell others so that you can share the burden.
However uncomfortable it may be, you have to find out why things have started to go wrong. Unless you work in an organisation with a Class 1 Blame Culture (and there are plenty of those), you should pull your team together and hold a free and frank discussion to identify how and where error crept in, bearing in mind that you may need to take your fair share of responsibility. In a blame culture background, you may need to talk to your team members (or others) individually and use your own filtering mechanisms to discern how and why things have gone awry.
Once you have identified the problem area and its cause, then you should try to establish what corrective action can be taken. Again, this could be a team activity – from brainstorming, to generating a cause-and-effect diagram.
If you can identify some solutions, then you should rank them on a number of relevant criteria. Once this is done, you can then ‘face the music’, but now you are offering alternatives and possibilities rather than dumping a problem in someone else’s lap. Engage them in deciding which option to pick, rather than who is to blame!
To manage your project, you are going to need to keep a firm grip on which are the latest versions of whatever the project produces as well as the documents that are generated in the process. Depending on the complexity of the project, this may a simple version of a numbering and filing system or a really quite elaborate control and management system. If it is the latter, your organisation is likely to have its own configuration management systems which you should follow; if it is the former, then common sense, a good system of version numbering (for example Version 2.1.3), together with well-kept filing, is probably all that is needed. What you have to avoid is releasing some new software that is not the latest version, or getting an out-of-date copy of the marketing brochure reprinted.