Tag: lessons learned

More Project Management Tips from the DOE

Last week, we looked at part of a study released by the DOE in conjunction with the National Academy of Sciences. It’s quite a comprehensive report, and it might make you feel a little inadequate about the state of your project management. However, you’ll be glad to know that even the big boys don’t start out getting things right. In fact, this study was prompted by what the Academy called the DOE’s lack of “a uniform set of objective measures for assessing the quality of project management…(this absence) prevents the identification of best practices and impedes widespread improvement in project management throughout the agency”. If an organization as cumbersome and set in its ways as the typical government institution can recognize this and begin making positive changes, there’s nothing holding your company back from doing the same!

9 Critical Benchmarking Activities

According to the NAS report, there are 9 basic aspects of benchmarking. These activities apply to benchmarking done at any phase of a project (planning, execution, review). For best results, this benchmarking should be integrated into the project management culture rather than being viewed as somehow separate. This encourages openness to new ideas and a willingness to make changes as needed to improve project and program processes. Here are the 9 activities:

  1. Deciding what to benchmark
  2. Defining the metrics to be used
  3. Developing a reliable method of data collection
  4. Actually collecting the required data
  5. Analyzing the data to highlight deficiencies in performance and areas where best practices are not being followed
  6. Identifying the root causes of these PM process and outcome shortcomings
  7. Developing a plan of action to reduce or eliminate known deficiencies
  8. Integrating new best practices into the project delivery process
  9. Making benchmarking a recognized and valued part of the process of continuous improvement

The Input/Process/Output/Outcome Cycle

Because benchmarking is designed for use at each stage of a project, it’s helpful to clearly define the cycle of a standard project. The DOE uses assessments that cover four basic stages. Input is the first stage and benchmarking is done by measuring resources that will be provided for the project. The next stage involves process metrics. The manner in which activities are carried out is compared to PM standards for how things should be done if all policies and procedures are followed. Output focuses on benchmarking the quantity and quality of the end product. The outcome is measured by how well the end product actually serves the purpose for which it was intended and whether it supports larger program objectives. External factors may influence the project at any stage. These influences must be taken into account as issues that should be planned or adjusted for even if they cannot be entirely controlled.

What Makes a Performance Metric Useful?

As you go through the process of actually deciding what data to use, there are some characteristics that have particular value. Data collected for benchmarking should be:

  • Measurable (objectively or subjectively)
  • Reliable, consistent, and verifiable
  • Simple, clear, and easy to understand
  • Timely and cost effective
  • Minimally affected by external influences
  • Meaningful to users at all levels
  • Related to mission outcome
  • Useful for driving effective decisions and process improvement

The more criteria on this list you can match in your performance measures, the better!

Filed under: UncategorizedTagged with: , , ,

Agile Techniques That Mesh With Traditional Project Management

Agile project management is an iterative approach that focuses on achieving project objectives in distinct stages. It is typically used in the software development industry but has some applications in other fields as well. When the overall scope and specific deliverables are likely to change throughout the lifecycle of a project, an agile approach can make it easier to keep moving forward. This methodology is often best suited for use with small to mid-sized projects. For large scale projects with well-defined deliverables and a high degree of complexity, the agile approach tends to be less useful. However, this doesn’t mean certain features from the agile “toolbox” can’t still be used.

Learn as You Go

You might consider a blended approach that involves traditional waterfall and agile methods. For example, regular meetings that include a review of all lessons learned in the previous week are a core feature of agile project management that can be incorporated into many projects. Since stakeholder feedback is a key factor in compiling lessons learned, the project’s communication management plan must include a way to collect this feedback on an ongoing basis. So, this is an ideal option for projects that involve a client who likes a very “hands on” role.

Quality Takes Center Stage

The agile method also relies heavily on quality control at each stage (since software must be tested and debugged). This is another area where PMs in traditional industries would do well to pay attention. Project quality management should be designed to monitor project deliverables at crucial junctures. Let’s say component B’s performance is predicated on the quality of component A. To avoid delays and increased costs, a quality check should be performed during or immediately after the schedule activity that results in the completion of component A. This type of quality assurance plan can be developed based on an activity sequencing diagram.

Adaptation Requires Flexibility

No matter how thoroughly you plan, there will always be issues that require change requests. With an agile attitude, your team doesn’t have to view these as setbacks. Instead, each modification to the project plan can be seen as an opportunity for brainstorming and problem solving. A project management team that learns to collaborate is more likely to increase the value of a project through creative solutions rather than simply suggesting stop-gap measure to keep the whole thing from falling apart. To make this work, a leadership style that focuses on developing team members rather than simply issuing instructions is essential. In the long run, companies that feature a collaborative environment are almost certain to outperform their competition. So, this is one aspect of the agile method that should be adopted by all businesses that want to remain viable in today’s marketplace.

Filed under: UncategorizedTagged with: , , , ,

A Poor ‘Lessons Learned’ Approach Can Impact Actual Learning

Once a project is completed, it can be tempting to simply wash your hands and move on. Looking forward to the next thing down the line is usually much more exciting than reviewing what’s in the past. Sure, basking in the glow of a job well done feels good. But scrutinizing the things that didn’t go so well isn’t enjoyable. Nevertheless, documenting lessons learned and implementing them is a critical part of project management. How can you ensure that this task is done in a way that promotes learning rather than discouraging your team?

Build Good Capturing Habits

If your team hasn’t been collecting data throughout the project, you won’t have much to put in your lessons learned knowledge base at the end. By that time, much of the wisdom that was actually gained about successful and unsuccessful strategies has been lost. Trying to recapture all this information at the end of the project is a time consuming and flawed approach. It will make everyone feel overwhelmed and exhausted.

The initial project management planning stage is when a process for gathering lessons learned along the way should be determined. For simple projects, this may be as straightforward as instructing each team member to keep a journal documenting insights throughout the life cycle of the project. For more complex projects, this documentation responsibility may be bundled into another process such as Quality Management.

Be Careful With Phrasing

Remember that the next team you work with will be reviewing the lessons learned by the previous group. Plus, the current team will also need to go over these materials. This means the documentation should be carefully written to avoid placing blame on specific people if things went wrong during the project. That way, the process of review is less intimidating and uncomfortable for everyone. Any necessary discussions about individual errors should be done in private rather than being made a permanent record in the lessons learned database.

Here’s an example of the wrong way to write a lessons learned report:

“Project management assistant Gary Ross failed to coordinate with HR on a simple scheduling task. This created a serious delay of 2 weeks and probably cost the company a lot of money. This employee has been reprimanded and received remedial training on how to do his job properly next time.”

Here’s an example of a much better approach:

“An initial decision was reached regarding scheduling based on partial information that resulted in a delay of 10 working days. Further investigation revealed that pertinent information readily available from Human Resources was unintentionally overlooked in the decision making process. Future schedule planning will include a consultation with HR to ensure more accurate results.”

As you can see, using a passive voice in writing makes it easier to achieve the objective of teaching in this situation. It is possible to outline the known facts about a mistake and how it will be avoided in the future – which is really the important information – without publicly shaming anyone. This is key if you want your team to be forthcoming about their mistakes in the future.

On the other hand, you can mention specific team members who contributed lessons learned about highly successful strategies. It’s a great way to recognize individuals who have done an outstanding job. Team members are more likely to participate eagerly in the review process when they know that this is where their achievements will be recorded for the purpose of improving future projects. In effect, they get to be the teachers!

Filed under: UncategorizedTagged with: , , ,

Lessons Learned in Project Management

One critical type of documentation in project management is the development of a lessons learned knowledge base. Of course, to take full advantage of the learning opportunities provided by mistakes and poor judgment calls, it is necessary to identify and acknowledge them. This means you and your team members need to be comfortable admitting to errors rather than trying to ignore them or “sweep them under the rug”. Placing an emphasis on solving the issue rather than placing blame is a good way to encourage transparency in this area.

It is also important to remember that lessons are also learned from perceptive choices and beneficial actions. These are patterns you will want to repeat in the future, so it is important to make note of them as well. Addressing lessons learned in a meeting format is an excellent exercise in constructive criticism if you lead by example. Just make sure to balance the positive with the negative and never berate a team member (especially in front of others) for a poor decision that resulted in a sub-optimal result. However, accountability should be emphasized. Stakeholders deserve to receive information about when, why, and how improvements can be made to ensure better outcomes in the future.

Types of Lessons Learned

Any aspect of the project management process can yield valuable lessons. For example, an unexpected problem may arise that demonstrates a serious oversight in the risk analysis phase. This will add an important data point for consideration in future projects.

Some other lessons you might learn include:

  • That a project’s scope, time, and costs were woefully underestimated
  • Which vendors to use and which to avoid in the future – and why
  • Which members of your project team need extra supervision to get things done
  • Which members of your project team can be given additional responsibilities and opportunities for leadership development
  • That certain instructions and communication are unclear leading to confusion
  • That your current tools/equipment/technology aren’t up to the task at hand
  • That some corporate policies are outdated and decrease the efficiency of project processes

Current Project Improvement

Lessons learned don’t have to be reserved for use in your next project. In some cases, you can use these lessons to help you take immediate corrective action. This actually adds even more value to your knowledge base since you can document not only the cause of an issue but the steps taken to correct it (and the reasoning behind those steps).

The resulting library of knowledge will be invaluable not just for future project management improvement but also as instructional material for other departments in your organization. Seeing documentation of how continual learning works in practice may prompt them to make much needed changes to fix processes in their day to day functioning that are “broken”.

Filed under: UncategorizedTagged with: , ,