Step 1: Prepare

• Have a clear meetings structure for your project^[1] which addresses as a minimum: Meetings structure; Meeting’s aims and objectives; Chairmanship; Frequency; Location; Attendees/participants; Duration; Agendas; and, Minutes/Records.
• Create an agenda. Solicit items of interest from others, if appropriate. Make sure agenda items are specific enough to clarify the issues to be discussed. Add more detail to those that are ambiguous or need background and assign responisbility for preparation where necessary.
• Have the right people attending – if a key person is missing, the meeting objectives will not be achieved, and on the other hand having non-contributors at the meeting (unless it is purely informational/briefing) will be a waste of their time.
• Make sure that the meeting facilities^[2] are satisfactoryily arranged.
• Appoint a meeting ‘secretary’ whose role includes taking the notes during the meeting and preparing the meeting record.

Step 2: Inform

• See that the Agenda is circulated at least 3 days before the meeting to ensure participants have an opportunity to be prepared^[3]

Step 3: Facilitate and Control

The principal role of the Chair of the meeting is to facilitate:

• Set a good example – be on time and turn off^[4] your mobile phone!
• Provide a short introduction at the start of the meeting.
• Keep the discussion on topic.
• Keep the meeting to time. If the meeting is planned to run for longer than an hour, provide comfort breaks.
• Don’t hog the discussion – involve participants and listen.
• Summarise the discussion from time to time and at the end.
• Assign actions and make sure they’re understood.
• Manage conflict.
• Praise in public/criticise in private.
• Take meeting minutes (or see that they’re taken by the meeting secretary) and see that they summarise: discussion items; decisions and actions; action responsibilities; and, agreed action completion deadlines.

Step 4: Summarise and Record

• Distribute minutes to summarise the discussions and confirm decisions and action items within 2 days of the meeting.

Bonus Tip 1

Cancel regularly scheduled meetings if there is nothing to discuss.

Bonus Tip 2

There are many techniques for managing conflict in meetings. Here are a couple I found useful:

• Break up cliques by planning placement of participants and then placing people round the meeting table at allocated seats.
• Silence a trouble maker by seating yourself beside them rather than opposite.

Last Word

Meetings are indispensable when you don’t want to do anything.
John Kenneth Galbraith (1908 – 2006)

1. ^[1] Normally set out in your Project Handbook or Project Execution Plan. ↩
2. ^[2] Venue/catering, audio-visual aids) ↩
3. ^[3] Note that this applies even to regular scheduled meetings. ↩
4. ^[4] or put it on silent ↩

Image Credit:
sixninepixels / FreeDigitalPhotos.net

As George S Patton (1885 – 1945) said:

Take calculated risks. That is quite different from being rash.

Risk and the Management Process

In project management a ‘risk event’ can be defined as ‘an uncertain event or set of circumstances that, should it occur, will have an effect on achievement of one or more project objectives’. Traditionally, risk has been viewed in a negative light, but more recent practice has been to treat a risk event as being either a threat or an opportunity. Both can be managed through a single risk management process with 5 classic steps as shown in the diagram below.

Risk Management Steps

Step 1: Identify Risks

Use creative thinking techniques to identify threats and opportunities. Consider both the internal and external environment and record the results in your project’s risk register.

Working with a group of people with varied backgrounds and experience will tend to widen and improve the range and quality of the risk identification and the subsequent risk management.

The risk profile changes as the project moves forward, so the risk identification and review is an ongoing process throughout the project’s lifetime.

Step 2: Qualitative Risk Analysis

Qualitative analysis identifies the most serious risks and determines where to focus attention and resources.

To determine the seriousness of identified risks the following parameters are normally considered:

• probability
• impact
• proximity

Assessments of probability and impact are subjective with qualitative or numeric criteria most often applied to individual risks.  The level of detail should be appropriate to the project. A five point scale such as that below works well for many projects:

Note the use of a ‘doubling’ or ‘weighted’ numeric scale for impact – this avoids a low probability and high impact risk being viewed as much more severe than a risk of high probability with low impact.

Risks are ranked by the value of the product of the probability and impact scales:

Proximity is an important factor, but often ignored. By focusing on immediate risks, where it is often too late to take any effective action, we operate in a ‘fire-fighting’ mode.  By thinking ahead, we can often have a wider range of options for risk responses and can manage the risks for a fraction of the potential impact cost.

Risk may be categorised as (see example in the risk register template available at the end of this article):

• Unacceptable – there is need to spend time, money and resources on responses at the individual risk level.
• Acceptable – this doesn’t mean that they are ignored, but rather that contingencies (time and/or cost) are created for the group as a whole.

Step 3: Quantitative Risk Assessment

Most managers will be comfortable and familiar with the qualitative analysis of risk described above. However, it’s all a bit meaningless unless the manager puts some thresholds to the qualitative definitions.

What is meant by medium impact? Where does a delay of 4 weeks and additional cost of $50,000 sit in terms of the ‘very low’ to ‘very high’ impact scale for a particular project? To assess risks in a meaningful way it is necessary to define the impacts in relation to a particular project.  The following table shows a general measure of impact:

There are many variations on this table with percentage scales often being used for the cost and time components (see the template available at the end of this article for an example).

Step 4: Plan Risk Responses

Having established the unacceptable risks it is then necessary to consider responses on an individual basis. The standard response types can be summed up as follows:

Note that all the risk responses have a cost.

Step 5: Monitor and Control Risk

The best risk planning in the world is useless without a clear picture of how the situation in the project is developing in reality. It is essential to keep track of the identified risks, monitor the effectiveness of risk responses and identify new or changed risks. This means having:

• a regular review and updating process;
• effective reporting mechanisms ensuring that risk is covered in all key reports and reviews;
• openness and transparency in the project – where ‘shooting the messenger’ is the normal approach, problems will be hidden until the last possible minute by which time response options may be very narrow indeed;
• effective communication with stakeholders to ensure that they are prepared if an anticipated risk occurs; and,
• release of contingency when the time for individual risk passes without them occurring.

Risk Register Template Download

The Risk Register or Risk Log is the key document in this classic 5 step approach to risk management.  By submitting your details in the form below (privacy policy) you’ll be taken to a page where you can download a template containing:

• a blank risk register template with numeric scales and an adjustable threshold and conditional formatting for highlighting ‘unacceptable’ and ‘acceptable’ risks;
• Quantitative criteria for probability and impact set out as percentages; and,
• an example of completion of the risk register.

*(denotes required field)

First Name: *

Last Name: *

E-Mail Address: *

E-Mail Address again: *

Please enter your E-mail Address a second time.

Please inform me of new posts at Project Management Insight

If you subscribe to be informed of new posts you'll receive an email notification approximately weekly.

CAPTCHA Code: *

Powered by Fast Secure Contact Form

Performance measurement is increasingly in vogue, has application across all industries and processes, and can be applied to delivery of projects and programmes. Successful introduction of performance measurement helps organisations and teams to: evaluate their current and past performance; learn and improve; and, achieve their strategic objectives.

Benefits of Performance Management

Eight reasons for measuring performance in the public and non-profit sector are set out in a paper by Robert Behn (2003).  The reasons seem to me to be equally applicable to organisations delivering projects:

• Evaluate
  How is my [organisation] performing?
• Control
  How can I ensure that my subordinates are doing the right thing?
• Budget
  On what programs, people, or projects should my [organisation] spend the [public’s/shareholders'/owner's] money?
• Motivate
  How can I motivate line staff, middle managers, … collaborators, [and] stakeholders, … to do the things necessary to improve performance?
• Promote
  How can I convince … superiors, … [and] stakeholders … that my [organisation] is doing a good job?
  
• Celebrate
  What accomplishments are worthy of the important organizational ritual of celebrating success?
• Learn
  Why is what working or not working?
• Improve
  What exactly should who do differently to improve performance?

Introducing Performance Measurement to your Organisation

Strategy Map Example

In introducing performance measurement to your organisation you need to have:

• Clear and Understandable Strategic Objectives
  Why is performance measurement being introduced and what are the expected benefits? The rationale for introducing performance measurement will vary according to the organisation’s strategic objectives (see example set out in the form of a strategy map).  The performance measurement system should be designed to suit the organisation’s goals.
• Management Commitment
  Not only do you need senior management commitment preferably with a champion at the highest level of the organisation, but also the buy-in of the project delivery team, who will gather much of the data. In order to gain the commitment of the project delivery team, the rationale for performance measurement needs to be understood and the benefits clear for the organisation and the individuals.
  
• Integration of performance measurement in the project processes and procedures
  Performance measurement should be viewed as a routine, integral part of the project management process rather than a separate function. Measurement and benchmarking should emphasize the continuous and consistent application of the system and the resultant identification and implementation of improved project management procedures through lessons learned and feedback systems.
• Meaningful KPI’s (Key Performance Indicators) and Targets
  Select ‘SMART’ KPI’s to suit your business objectives: Specific; Measurable; Achievable; Realistic; and, Time based.
• Objective KPI’s
  Metrics should so far as possible be capable of objective rather than subjective measurement in order to be able to consistently apply measurement across projects and programmes.
• Targets
  For a performance measurement system to achieve benefits it is necessary to agree performance targets which are achievable and realistic and which can be applied to projects individually and to the organisation’s portfolio of projects as a whole.  As improvement feeds into the project management processes then the organisation should raise the performance bar and always strive to achieve the highest practicable performance.
• Honesty
  Improvement can only be achieved if the organisation is honest about its current performance and is culturally ready to aim for improvement.
  

Choosing your Key Performance Indicators (KPI)

If you’ve decided to introduce performance measurement to your organisation we now come to the difficult part – choosing a suitable set of KPI’s. Unfortunately it’s generally not possible to trawl the Internet and come up with a ready list of KPI’s and targets to suit your specific requirements, although you may find many good ideas for adaptation to your specific needs.

One source of ideas with hundreds of KPI’s is the KPI Library. Although they may have something to suit your needs, I didn’t find them to be particularly strong in my personal areas of interest, real estate and construction projects, and the KPI’s were not always described in enough detail to enable them to be reliably computed.  They offer additionally a number of paid services such as ‘KPI Benchmark’. However, as users are able to submit guesses to KPI surveys it’s not clear that paid up users will always be benchmarking against real measured data.

In the construction and real estate sector, the “KPI Report for the Minister for Construction” (2000) provides a fairly comprehensive set of KPI’s and descriptions of how they are measured with worked examples, covering:

• Time;
• Cost;
• Quality;
• Client Satisfaction;
• Change Orders;
• Business Performance; and,
• Health and Safety.

I found these KPI’s to be a suitable basis for developing a project and programme based performance measurement system for my business with some adjustments and additions (Employee satisfaction and the Environment) to suit our particular requirements.  If your interests are in the construction sector, you too may find them to be a useful starting point.

If you participate in a benchmarking scheme (see below), then your KPI’s are likely to be chosen from a list provided by the benchmarking organisation.

Setting Targets

Just as it’s difficult to find ready-made KPI’s, it is also difficult to find suitable targets for your chosen KPI’s.  If you’re not able to find suitable published data, you’ll need to set some targets based on previous personal or corporate experience with initial targets being largely subjective unless you’ve a good set of documentation from previous projects and the time and inclination to go through the documentation and evaluate the projects.

Remember that targets must be realistic and achievable. Targets for each individual project may differ from the targets for the programme as a whole. As performance improves, you can raise the bar.

Benchmarking

Where an organisation has a programme of projects, then benchmarking of projects within the organisation is clearly useful.

Benchmarking against other businesses can provide a helpful comparison of performance and potential. The challenge here is finding external data for comparisons.  However, there is a growing body of  suppliers of benchmarking services – for example, in the UK:

• the Association for Consulting and Engineering (ACE) in the UK has established a benchmarking programme for its members.
• Annual Construction Industry Performance Reports with a wide range of KPI’s have been published by Constructing Excellence Ltd. since 2007.

While the ACE benchmarking programme seems generally more concerned with overall business performance, the Annual Construction Industry Performance Reports may be useful to benchmark projects and programmes for organisations operating in the construction sector. Internet searches may reveal other benchmarking schemes which will meet your requirements.

The Last Word

Performance measurement has application to project and programme management. To apply it successfully:

1. Have a clear understanding of the rationale for and benefits in introducing performance measurement to your organisation;
2. Create the conditions necessary to introduce it to the organisation;
3. Design performance measurement systems to achieve defined strategic goals;
4. Select or design suitable objective and measurable KPI’s;
5. Set realistic and achievable time based targets; and,
6. Ensure that lessons learned are translated into continuous improvement.

Finally, the last word in this post goes to management writer Peter Drucker (1909 – 2005):

‘Management’ means, in the last analysis, the substitution of thought for brawn and muscle, of knowledge for folklore and superstition, and of cooperation for force. . .
(from “People and Performance”)

References

• “Why Measure Performance? Different Purposes Require Different Measures”, Robert D Behn, 2003
• Stacey Barr – ‘the Performance Measure Specialist’
• “Measure Performance and Set Targets”, Business Link
• KPI Library
• “KPI Report for the Minister for Construction” by the KPI Working Group, January 2000
• ACE Benchmarking
• ‘Construction Industry Performance Reports’, Constructing Excellence in the Built Environment

As recent articles in PM Insight have covered project failures and lessons learned, readers might be interested in this research which covered 1,471 IT change projects with costs averaging $167 million with the projects’ budgets and estimated performance benefits being compared with the actual outcomes.

The authors found that the average project’s cost over-run was 27%, but this average hid a ‘fat tail’ of one sixth of projects, which they dub ‘black swans’, where the cost averaged 200% above budget and the time over-run was 70%.

The article details a number of cases including: Levi Strauss; Hong Kong Airport; Hershey; Kmart; Auto Windscreens; and, Toll Collect.

The authors suggest that companies contemplating large scale technology projects should take stress tests to confirm their readiness to survive a ‘black swan’ project by asking themselves if the company can absorb the impact of: its biggest technology project going over budget by 400% or more and realising only 25% to 50% of the projected benefits; and, 15% of its medium-sized tech projects exceeding cost estimates by 200?

They also suggest that managers: break big projects down into more manageable units of limited size, complexity, and duration;  recognize and make contingency plans to deal with unavoidable risks; and, make use of the best possible forecasting techniques.

More information can be found in the article by Bent Flyvbjerg and Alexander Budzier published in the Harvard Business Review Magazine, September 2011.

The Last Word

The last word in this post goes to Martina Horner (1939 – ):

“What is important is to keep learning, to enjoy challenge, and to tolerate ambiguity. In the end there are no certain answers.”

Causes of Project Failures – Case Studies

The previous post argued that there’s no clear definition of ‘project failure’, but a continuity between total failure and total success.  Our two case study projects – a hotel development and the Scottish Parliament – were successful in that they were completed and brought into operation, while exhibiting failures in:

• delivering to budget
• delivering to schedule
• achieving anticipated benefits
• achieving customer satisfaction
• enhancing the reputations of the project team, and
• enhancing the rewards and careers of individuals in the project team

What were the causes of those failures?

Hotel Project

Following completion of this 5* hotel development, I was called in by the Owner to investigate the causes of time and cost over-runs.  The following short-comings were identified in my report:

1. Brief:
   - While a brief had been agreed, it failed to reconcile scope/quality of the completed development and the approved budget (which was much too low).
2. Strategy
   - Adoption of a high risk contracting strategy to overcome programme drift and incomplete design.
3. Project Life Cycle/Gateways
   – Lack of clear phases and gateways.
4. Organisation, Roles and Responsibilities
   - Lack of clarity of roles and responsibilities. Conflicts of interest.
5. Communications
   - Infrequent, low quality and at times imprudent reporting.
6. Procedures and Processes
   - Lack of documented management processes and procedures.
   – Lack of any systematic change control during design and construction phases.
7. Design
   - Lack of design co-ordination (between disciplines)
8. Procurement
   - Incomplete tender documents, incomplete design at time of tender, and no contingency provisions.
   – Unusually long bid lists.

The report concluded with a number of recommendations for improvement on future projects with examples of good practice.

The Scottish Parliament

The following is a summary of the conclusions from Lord Fraser’s report of the public enquiry:

1. Brief
   - The initial budget was insufficient given the scope and quality desired.
   - During a critical 18 months of the design period sight was lost of the brief and design proceeded without a clearly formulated set of client or user requirements.
   - Priorities not clearly resolved: whenever there was a conflict between cost and quality, quality was preferred; and, whenever there was a conflict between cost and early completion, early completion was preferred (without actually achieving and significant acceleration!)
2. Strategy
   - Adoption of a relatively high risk contracting strategy to achieve fast construction without full evaluation and appreciation and without consultation with Ministers.
3. Project Life Cycle/Gateways:
   - Incomplete at a critical RIBA Stage D gateway
4. Organisation, Roles and Responsibilities
   - Blurred lines of communication.
   - Inexperienced Project Sponsor (wrong skill set)
   - Conflict of interest
5. Communications
   - Reporting weaknesses: late reporting of budget increases to Ministers and resignation of project manager; elements of cost information was withheld or altered in reports to Ministers; not informing Ministers and stakeholders of risks; and, unjustified optimism in reports
   - Extremely poor levels of communication between key players at times.
6. Procedures and Processes
   - Failure to finalise a Project Execution Plan
7. Procurement
   - Insufficient enquiries made into the organisation of the design competition winning architectural joint venture. The joint-venture was a misnomer – two teams separated by geography working in quite different ways. Overall performance of the architect below reasonable expectations.
8. Design
   - Complexity (and cost) of the evolving design was not appreciated until it was too late to change.
9. Programme
   - Unrealistic programme given the complexities of the design

Common Causes of Project Failures

There are many common features when comparing our two case study projects:

• Wishful thinking – both projects started with a budget which did not recognise the briefed aspiration for scope and quality. Optimistic reporting of cost and time as the projects went forward in the (mistaken) belief that cost could be managed out and deadlines achieved.
• Adoption of high risk contracting strategies
• Organisational weaknesses
• Poor communications, particularly in reporting to owners and stakeholders
• Lack of documented project management procedures and processes
• Failures in areas such as change control and risk management

From experience, the failures exhibited in delivering the case study projects are fairly common.

However, two case studies is a very limited sample.  The UK Government, which has a fairly mixed record as a major purchaser of capital projects, established the Office of Government Commerce (OGC) to help the Government deliver best value from its spending.  OGC have published a booklet “Common Causes of Project Failures” where they place the common causes of failure in the following 8 general categories:

1. Lack of clear links between the project and the organisation’s key strategic priorities, including agreed measures of success.
2. Lack of clear senior management and Ministerial ownership and leadership.
3. Lack of effective engagement with stakeholders.
4. Lack of skills and proven approach to project management and risk management.
5. Too little attention to breaking development and implementation into manageable steps.
6. Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).
7. Lack of understanding of, and contact with the supply industry at senior levels in the organisation.
8. Lack of effective project team integration between clients, the supplier team and the supply chain.

The booklet goes on to provide detailed questions that OGC suggest are addressed by those managing or involved in delivery of government projects.

When the failures in the case studies are mapped against the OGC common causes of project failures we see the results tabulated below.

It appears from the above mapping that the OGC list is fairly comprehensive and can usefully inform the private sector as well as the public.

How and where to learn from the mistakes of others

Failures are often swept under the carpet rather than aired in public. There are exceptions: projects which end up in the courts; and, public projects which are subjected to detailed scrutiny through public enquiries/investigations.  To learn from the mistakes of others you could consider the following:

• published materials such as the OGC’s “Common Causes of Project Failures“;
• taking an interest in those ‘failed’ projects which come into the public domain such as the Scottish Parliament;
• participating in professional bodies such as APM and PMI, and networking with peers; and,
• ensuring that your organisation has robust processes for learning from its projects and absorbing the lessons learned for the future.

Accepting that few of us will actually attain the perfectly successful project, I’ll leave the last word to Winston Churchill (1874 – 1965):

Success is the ability to go from one failure to another with no loss of enthusiasm.

Don’t be discouraged by a failure. It can be a positive experience. Failure is, in a sense, the highway to success, inasmuch as every discovery of what is false leads us to seek earnestly after what is true, and every fresh experience points out some form of error which we shall afterwards carefully avoid.

Definition of Project Failure

A little searching of the Web shows a multitude of articles on the topic of ‘project failure’.  Some  articles are written from a limited perspective while others are written with the objective of selling you some ‘magic bullet‘ which will ensure the success of your project.

There’s no clear definition of project failure.  Many commentators suggest that failure occurs when: project cost exceeds budget; and/or, time to deliver exceeds the plan; and/or, the agreed scope is not fully delivered. It’s not really so clear cut – for example, while a short delay and small cost over-run on a project which is otherwise fully delivered and generally realises the expected benefits may be regarded as ‘failure’, it is certainly not catastrophic failure.

We might alternatively consider a project as failed if it is not delivered or is cancelled or if it fails to deliver the benefits expected by the promoter.  From a purely project management perspective there are a number of issues with this approach:

• a project might be cancelled for reasons such as changed market conditions e.g. as happened to many real estate developments following the marked downturn in the market in 2008.
• a promoter might realise a profit of 25% rather than the expected benefit of 30% – depending on your point of view, this might be considered a partial success or a partial failure!  The partial failure might not necessarily be a failure in the delivery of the project, but could result from changed market conditions.

In reality there’s no clear cut line between success and failure, but rather a range of possible outcomes from total failure to total success.  Where our projects sit in this range is partly a matter of perspective – for example, a delay may not have a major impact on the outcome or success of some projects, but where time to market is critical the same delay might be regarded as a major failure.

From experience, there is almost always room for performance improvement on projects. A few years ago I was involved in periodically auditing a major shopping centre development which was a huge success on opening and remains highly successful – yet, from my perspective I observed many failures or poor practices in the project delivery processes and strategies which detracted from the commercial outcomes and which might, in different market conditions at the time of opening, have led to losses for the promoter.  So our aim must be to push our projects up the scale towards total success.  The principal criteria where we can judge success (or failure) of our projects include:

1. Actual time vs. projected time.
2. Actual cost vs projected cost
3. Project deployed/introduced, or cancelled?
4. Revenue, profit, or productivity gains realized, vs projected
5. Customer/user satisfaction
6. Affect on reputation of company/department/project team
7. Were project staff rewarded (promoted, given bonuses), punished (sacked, demoted, given pay-cuts), or neither?

Case Studies – Real World ‘Failed’ Projects

What can we learn from real world ‘failed’ projects? I’ll look at  a couple of projects which might be considered failed, but which fell short of total failure while having significant shortfalls in delivery and many lessons to be learned. One project is from my own recent experience, while the other is in the public domain.

Hotel Development

A few years back I was called in by a project’s promoter to audit a 5* hotel re-development. The promoter was an experienced developer and operator of hotels.  The property had recently opened, but had suffered costs considerably over budget and delay in completion.

The redevelopment was of an existing historic hotel property with extensive demolition, but retaining the principal building facade.  The promoter’s project management subsidiary was appointed as client’s representative and, in addition, took over the project manageer and cost manager/quantity surveyor roles for the construction period.

The promoter’s objective for the audit was to establish grounds for suing his architect for the cost and time over-runs. The reality was somewhat more complex and my report suggested a number of lessons learned to be implemented in the promoter’s future projects.

The table below shows how the project fared against  the success/failure criteria described above:

Scottish Parliament

The new Scottish Parliament opened in 2004 some 3 years late and at a cost almost 9x greater than the original budget. A public enquiry was launched to establish the reasons for the project’s failures with the report being in the public domain. Having worked in Edinburgh for a number of years, a large number of the parties involved were known to me personally and I followed reports of the progress of the public enquiry with a great deal of interest.

The table below shows how the project fared against the success/failure criteria described above:

Survey

Part 2

The second post in this series looks at:

• how/where our case study projects failed;
• common causes of project failure in general;
• lessons that can be learned from project failures; and,
• how and where to learn from others’ mistakes.

Meantime to wrap up Part 1, I’ll give the last word to the American actor Mickey Rooney (1920 – ):

 You always pass failure on the way to success.

Learn from Project ‘Failures’ – Part 2 →

“The only man who never makes mistakes is the man who never does anything” – Theodore Roosevelt
(1858 – 1919)

During the course of our projects and at the end we should review our successes and failures, take the lessons on board and apply them in future.

“We learn wisdom from failure much more than from success. We often discover what will do by finding out what will not do; and probably he who never made a mistake never made a discovery.” – Samuel Smiles (1812 – 1904)

Project Reviews

During the course of the project, plan disciplined project reviews where the Project Manager and the team reflect on the project and objectively review their work. As a minimum, project reviews against the project management plan should take place at gateways and consider:

• the effectiveness of the project management processes used;
• lessons learned and follow up actions required;
• any concerns raised and agreed corrective actions;
• the likely technical success of the project;
• any impacts on the business case and corrective action required;
• overall progress against the plan: schedule, budget, resources, quality;
• stakeholder relationships and perceptions.

Internal Reviews

If you’re part of a project management business, you might also consider periodic internal project reviews with some additional topics:

• business performance (primarily financial performance);
• resources.

Project Closeout

At project close out, conduct a full review and prepare a ‘Lessons Learned Report’.

‘Lessons Learned’ Techniques

Break the project down into the key topics of: scope and function; time; cost; etc.

For each topic consider (using simple language which a novice could understand):

• What worked well and recommendations;
• What didn’t work well and recommendations including:
  - person/party responsible for making the change;
  - details of the required modification;
  - steps for follow through;
  - due date for the change implementation.

Finally

“An expert is someone who knows some of the worst mistakes that can be made in his subject and how to avoid them” – Werner Heisenberg (1901 – 1976)

This post was inspired by Alan Norton’s article 10 immutable laws of mistakes – it’s worth a read!

This post describes common faults I often see in reports, gives some tips for writing a good report and points readers to some other report writing resources.

Common Report Faults

Here are some common faults (in no particular order) I’ve observed in Monthly Project Reports which are best avoided:

• No effective summary for the busy executive or other reader receiving the report
• Too technical for the target reader
• Too much detail in the report body which should have been placed in appendices
• Looking backwards only with no planning for the coming period
• Report doesn’t provide comprehensive coverage of the project
• The implications of the current status for the project out-turn aren’t clear i.e. lack of forecasts
• Misleading statements made in reports hiding the true picture in the hope that the problems can be corrected later
• Reports assembled to a formula without being given any thought

Of course, it’s not uncommon to find projects with no reporting at all.  I recall one particular case where I had the task of auditing after the event – a hotel developer received misleading reports pre-construction and no reports during construction. He learned 3 months before the scheduled handover that the project was going to be delayed by 6 months and the final cost was going to be 50% above his authorised funding!  Imagine the developer’s reaction….  My audit was commissioned to identify the guilty and for the developer to obtain recompense from them.

Writing an Effective Monthly Report

General Approach

My Report Writing Flowchart

The approach I take to writing all reports is outlined in the flow chart to the right.  Go through this process fully at the start of the project.  At later stages you can abbreviate this process.

In the course of following my process, you’ll outline a template for your reports.  However, remember that as the project passes through different phases your template is likely to require review and updating.

Consider your readers

Always think about your reports from your readers’ perspective.  They may not be specialists in your field.  In my case, the real estate and construction sector, report readers may be from diverse backgrounds – real estate surveyors, bankers, and others.  Therefore avoid:

• overly technical language
• acronyms without explaining them on their first occurrence in the report
• trade jargon

Remember that your readers are generally busy people.  Providing a concise executive summary of the principal sections of your report will save them digging through the body of the report, or even worse, the appendices, to get at information and will earn you credit.

Draw attention to the critical issues

Draw the reader’s attention to the critical issues facing the project, particularly in the executive summary.  I use a traffic light system, but there are many other viable approaches using colour codings, usually on a red, orange/yellow, and green basis to quickly show the degree of concern about an issue.

Use your report to plan ahead and avoid fire fighting

A monthly report should not only look backwards to the achievements during the reporting period, but should also identify the tasks and objectives to be achieved in the next reporting period.  I generally create 2 columns under a heading – firstly, “Achievements in the Last Period” and, secondly, “Plans for the Next Period”.

A little time spent planning will help you avoid the future problems which will have you fire fighting leaving little time for planning and reporting.

Provide forecasts

It’s not sufficient to just state the current status.  An effective project manager interprets the data and advises his project sponsor and other readers.  Let your readers understand the implications of the current status by providing forecasts e.g. forecast completion date, forecast final cost, etc.

Be factual and truthful

It’s very tempting to hide problems in the hope that you can solve them later.  Unfortunately, hidden problems only tend to get larger and by hiding them you lose an opportunity to enlist help and support in finding solutions.  If it is not possible to overcome a problem, at least being truthful allows others to prepare and adopt contingency plans to minimise impact.

Use appendices

The body of your report should be sharp and concise. Don’t clog it up with supporting material which could easily be summarised in the report body and the detailed data placed in an appendix.

Be concise

Always be concise and direct in your reporting.  Use diagrams, graphs and figures where possible.  They can illustrate a relationship, trend, process or issue much better than many words.

Appearance matters

Proof read your report before issue to ensure that there are no glaring errors.

Don’t just grab the ‘jazziest’ template for your word processor.  Use or develop a template which gives your reports a consistent professional appearance.

Professional looking reports and documents gain credibility for your message and impress your clients, managers and colleagues.

Benefits

A well written and presented monthly report will:

• plan the tasks and objectives to be achieved in the coming period, reducing risk and giving you time to manage rather than fire fight
• focus attention on any problems and win support in finding solutions
• give your career a boost!

Report Writing Resources

There are many useful web resources which will help you to write more effective reports.  Our Link Directory provides links to selected effective report writing resources.

The web also offers many report writing templates.  However, don’t slavishly follow the templates – give some thought to the specific needs of your project and at least customise the templates to suit your precise requirements.  Again we’ve included some links to templates in our Link Directory.  If you’d like to widen your search, many other resources can be found on a Google search on the terms project monthly report template.

Improve this Article

You can improve this article by using the comments area to give tips and advice from your personal experience.

• an experienced project manager in any sector; and,
• have something to say to your fellow project managers which will be informative and interesting

then you’d be welcome as a Guest Contributor.

If you’d like to be a Contributor, please use the email contact form to confirm your interest.

While we welcome guest contributions we nevertheless reserve the right to edit or reject any post, which will be subject to approval prior to publication.