Jul 262011
 

Everything learned from previous projects, whether they were successes or failures can teach a project manager important lessons. And individual project managers usually do learn from their own previous experiences, but are these “lessons learned” shared with others within the project team or within the same organisation? If they are shared, do other project managers apply the lessons to their own projects?

If lessons were genuinely learned from past projects then the same mistakes would not be repeated on different projects. Projects within an organisation would then be more consistently delivered on time, within budget and to the customer’s complete satisfaction. Since this is not always the case, it would be safe to surmise that lessons are not really being learned from past projects.

Project environments are often challenging with multi-functional teams that are both culturally and geographically diverse. Budgets are usually tightly constrained and the business is evolving while the project is in progress so requirements frequently change mid-project. As a result corporations are not very effective at communicating across teams, and different departments are not well-integrated – with the result that similar mistakes are often repeated.

Yet there is a financial saving to be made in organisations from not repeating mistakes and the technological infrastructure is readily available to assist the transfer of knowledge across teams and departments. So why are lessons not being learned from projects in order to change this state of affairs?

 

Many project teams conduct a “lessons learned” review at the end of the project and even store the information in an accessible database. But the problem arises when other people are not encouraged to use this database and when the information is not used to improve project processes. This can be partly because the issues are not well-categorised so difficult to search and typically the database will, over time, include old and irrelevant information creating the view that the whole database is not very useful.

But building a genuinely useful “lessons learned” database that can be used to continually improve project processes involves just a few simple steps:

Recording Lessons Learned

Record both the problem and the solution as well as important project attributes in a single easily accessible database. This makes it easier to identify recurring issues, to update the data and to maintain the accuracy and relevancy of the data.

Categorisation

Ensure that the data are grouped and searchable by key attributes such as project name, type, size, business area, functional area or any other attributes that have meaning for your organisation.

Communication

Inform all project teams whenever the database is updated with new information and, more importantly, raise awareness whenever the data has resulted in a change to the organisation’s project processes.

Encourage use of the database

Allow free and informal access to the pool of knowledge and permit comments and feedback. Invite suggestions for process improvement based on the lessons learned data.

Data Review

Periodically review the data to remove out-of-date or redundant data to maintain a high level of confidence in the database. It should always be current and accurate.

Continually Improve Processes

Search for problems that exhibit similar patterns and instigate appropriate process changes such as introducing additional tasks and checks or changing the sequence of certain activities or changing optional tasks to mandatory ones.

 

 

Organisations of all sizes that regularly embark on complex projects have a huge amount of knowledge that is not being fully utilised. But by building, maintaining and using a “lessons learned” database, this information can be disseminated and used to improve project processes and prevent the repeated occurrence of similar mistakes. This “lessons learned” approach is supported by major project management methodologies such as PMP, PRINCE2 and APMP and will ultimately lead to more successful projects, and the consequent financial advantage, for relatively little effort.

 

 

 

 

Jul 112011
 

A detailed project plan with a realistic schedule and well-defined milestones is vital for project success. Preparing the plan is one thing but it is also necessary to follow the plan – assuming that the plan is a good one.

 

The most effective project managers understand the importance of a robust project plan with reasonable estimates for each activity. So a considerable amount of time and effort usually goes into preparing the project plan. It requires enough detail so that every task can be assigned to the right person or team and they understand what is expected of them and when. It details dependencies between tasks so that risks can be thoroughly assessed and is one of the fundamental building blocks of a successful project.

 

But what happens if the plan is fundamentally flawed? Or if requirements change substantially part way through a project and the plan becomes meaningless? In such circumstances it can actually be detrimental to project success to continue to follow the plan. The project manager and the project team need to be flexible and adaptable in their approach to the project plan. Sticking rigidly to what was first specified is simply failing to grasp the realities of most projects.

 

And if it becomes obvious that the plan is flawed, you need to admit this and modify it to correct the errors. It may be a hard thing to admit but blindly following a plan that you know to be flawed will obviously never lead to a good outcome.

 

New or inexperienced project managers may be unprepared for the amount of flexibility required in real-life project plans and how many changes are required to the plan during the course of the project but experienced project managers will know that this is typical of most, if not all, complex projects.

 

Changes within projects can occur for a variety of reasons: essential staff leave, business priorities change, requirements become clearer as the project progresses, the business objective may simply change due to market forces. Changes can be due to internal factors within the organisation or external factors concerning suppliers or providers of outsourced services but whatever the reasons it is through the experience of managing many complex projects that you will learn that change is a normal part of every business and every project.

 

The best project managers employ project plans as a starting point into which will be built more information and details from team members working on individual tasks, from reassessment of the project’s resources as the project progresses and reviews of the business requirements and ultimate objective. It is, therefore, essential that you know how to monitor the status of projects and resources, and how to obtain meaningful feedback from team members and end-users.

 

Anyone involved in a project who believes that a project plan can be put in place at the outset of the project and simply followed through to a successful outcome is either inexperienced or has only ever worked on very simple projects.

 

So it is important to recognise that a failed project is not one that deviates from the project plan or schedule (or even the budget) but one that fails to deliver what the client needs or wants. Altering a plan to deliver what is required is simply one step on the path to delivering a successful project and should always be viewed as such. It is essential that everyone involved in the project is aware from the start that the plan is likely to change over time but it is just as important that the current plan is adhered to. It is a difficult balancing act to convince the stakeholders of the veracity of the plan at the outset whilst preparing them for the fact that it might change. No wonder so many people try to struggle on with an unsuitable plan rather than admit it needs updating but, nevertheless, this is what you must do to be successful.

 

A project plan will only create a problem if the project manager (or anyone else involved in the project) refuses to alter it to take account of changes that happen during the lifetime of the project. When you consider that many projects have a timeframe of several years it is unrealistic to expect the plan to remain unchanged.

All too often, failing projects become an operation to determine why the project is deviating from the plan and how to get it back on track instead of looking at how the objective could still be reached. This may be difficult to do, particularly when the original plan was part of the justification for the project, but it is not impossible if you concentrate on what the original business objective was. In fact many of the formal project methodologies focus on the business objective as the major factor in successful projects.

 

Project managers can often learn from previous projects and prepare for the next project by recording the differences between the expected schedule, budget etc and the actual data. Applying lessons learned to the next project will assist in managing the expectations of all those involved and improve the results of each successive project, which is why the most successful project managers are often the most experienced. But, for the less-experienced, there are project management courses on recognised methodologies such as PRINCE2, PMP Certification, and APM PQ that will teach many of the techniques that experienced project managers have had to learn the hard way.