Tag Archives: Lessons Learned

Lessons Learned Archive

Intro to Value Stream Mapping

– February 28, 2011Posted in: Agile, Project Management

I’m in the process of doing a Current State Value Stream Mapping (VSM) for the PMO. The big questions are, based on the current state, are there areas we can improve? Can we eliminate any waste (or increase efficiencies) from our current processes? The answer to both questions is YES. Everyone should be reviewing there processes on a regular basis, giving themselves opportunities to become more profitable. Though I’m advising a Federal Government project, the American people still deserve the most bangs for their bucks.

Today is the last day for one of my projects. It is done. Now is the time to see what worked and what did not. We now need to do a retrospective and see if we learned any lessons from the last go-around. I will give the vendor credit on this particular project. This small cross-functional team did a better job than others, in part, because we had a daily 15 minute status meeting. (otNay allowedway otay entionmay Agileway). One of the other program teams wastes so much time because they only communicate once a week in a 3 hour meeting. I hope my VSM will change that.

For those new to Value Stream Mapping, I included a 5 minute video that does a pretty good job of explaining its value. See how a process that took 140+ days to complete was shortened down to just 30 days.

If you don’t have your current process documented, you need to do it! As the saying goes, “What cannot be measured cannot be improved”. Don’t be complacent and accept the waste. Times are tough and we need to think lean!

Like the drawing? Get it free at Pictofigo

Popularity: 1%

Tags: Agile, Lean, Lessons Learned, retrospective, Video, VSM

Project Management Theater

Derek Huether

– December 29, 2010Posted in: Project Management

After hearing public outcry over all of the “junk” grabbing going on at Transportation Security Agency (TSA) checkpoints, I heard the resurfacing of the term “Security Theater”. I’m not certain if TSA “gets it”. If you are going to take true action to help fix issues, you need to treat the cause and not a symptom. Have a shoe bomber? Make everyone take off their shoes. Have someone wearing baggy clothes wear a bomb onto a plane, spend millions of dollars to see beyond the baggy clothes. Without telling you what I did, I bypassed both the new full-body scanners and the TSA pat down in two major airports within the last few weeks. Certainly, I didn’t want to deal with either so I was happy. The problem I have, as a stakeholder, is a lot of money has been spent and the issue still exists.

Imagine if that happened on your project?

I see Lessons Learned meetings or a Retrospectives as opportunities to help you refine your processes. You see what works and doesn’t work. You find out the root causes and then you make changes. You refine.

Today I witnessed what I call Project Management Theater. The vendor loves to use Gantt charts. On a program level, both the customer and vendor follow a more traditional waterfall process. At last count (5 minutes ago) the “integrated” schedule had 5,954 lines. (Internally, I use a backlog and Kanban) Within seconds of reviewing this monster schedule, I could point out improper work decomposition, improper work package mapping, description inconsistencies, improper use of preprocessors or successors and the list goes on. If your customer prefers the use of Gantt charts over Burndown charts, I’m not going to argue with them. Whatever the culture will demand, you have to work with it. But, the problem here is these are just charts. They are only as good as the data driving them. When the customer asked me today what I thought of the split view the vendor provided (WBS/Gantt chart), I was blunt. I hate it. I added, everything that needed to be reviewed at the meeting could have been presented either as a milestone report or backlog. Instead, we spent most of our time trying to locate activities and get statuses on each. On top of that, the schedule provided had not been updated in two weeks. Therefore, we had to ask over and over again if certain activities had been completed.

If you’re going to commit time and money for a support activity, please make sure the resulting “thing” has some value. At the next meeting, I expect the Gantt chart to go the way of the dinosaur. I’m advising the customer to request a milestone report from the vendor (instead of the WBS/Gantt Chart). In the end, I want to ensure the vendor is reaching agreed upon milestones. Currently, the customer is so distracted by all of the inaccurate details of the schedule, they forget to ask the hard questions about the milestones.

Eliminating the Gantt chart is not going to solve the problem. Next week, I’m going to show the executive team a Kanban of the milestones. Let’s see if they find more value in that.

Like the image? Find it at Pictofigo

Popularity: 1%

Tags: Backlog, Gantt, Lessons Learned, retrospective, WBS

We didn’t learn our lesson

Derek Huether

– July 20, 2010Posted in: Project Management

As the project I support enters a new period of performance, I reviewed the lessons learned documented a year ago and compared them to the documented lessons learned from a few weeks ago.

To be identified at any point of a project lifecycle (PMBOK page 437), all project managers should collect and document lessons learned. In reality, everyone on the project should be collecting and documenting lessons learned. But, as many will attest, you need to be able to implement approved process improvement activities (PMBOK page 83) or you will just continue to revisit history at the end of each cycle or project. If that is the case, you really didn’t learn your lessons.

Do you learn from your mistakes? You should be able to at least be aware of them. Document your mistakes and revisit them at the beginning of the next project or cycle. Group them into three categories: Correct Actions, Preventive Actions, and Defect Repair.

Corrective Action: Document your direction for executing future project work. Bring expected performance of the project work in line with the project management plan.

Preventive Action: Document your direction to reduce the probability of negative outcomes associated with project risks.

Defect Repair: Document a defect in a project component with the recommendation to either repair it or completely replace the component.

Though the process of documenting, reviewing, and implementing lessons learned may differ between Waterfall and Agile projects, the process still needs to happen.

Again, don’t just document lessons learned. Act on them!

Graphic: Flickr: sopheava

Did you learn your lesson?

Derek Huether

– May 5, 2009Posted in: Project Management

I’m going to be facilitating a second lessons learned session later today.

As part of the project closing processes, all project managers should collect and document lessons learned. But, as many will attest, you need to be able to implement approved process improvement activities or you will just continue to revisit history at the end of each cycle or project.

Do you learn from your mistakes? You should be able to at least be aware of them if you document them at the end of each cycle or project. Revisit them at the beginning of the next project or cycle.

Corrective Action: Document your direction for executing future project work. Bring expected performance of the project work in line with the project management plan.

Preventive Action: Document your direction to reduce the probability of negative outcomes associated with project risks.

Defect Repair: Document a defect in a project component with the recommendation to either repair it or completely replace the component.

Responsibility Assignment Matrix

Derek Huether

– April 23, 2009Posted in: General

As a graphical depiction of a more detailed perspective of responsibilities, the responsibility assignment matrix should reflect assigned responsibility by functional role for key project deliverables. An example of roles detailed below could include (1) Project Manager, (2) Project Sponsor, (3) Implementation Manager, (N) Team Lead

Project Deliverables	Role 1	Role 2	Role 3	Role N
WBS 1.15.10.1300 – Project Charter	E	A	C	I
WBS 1.15.10.1301 – Project Schedule	E	A,C	A	I
WBS 1.15.10.1302 – Project Budget	E	A,C	E	I
WBS 1.15.10.1303 – Status Reports	C	C	A	E
Legend E = responsible for execution (may be shared) A = final approval for authority C = must be consulted I = must be informed