Did you learn your lesson?

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.

From the desk of VP Enterprise Solutions

I just received a recommendation from someone I've worked with in the past. I have to admit, it's really nice to hear good things from time to time. I'm a strong believer that you should tell people when they are screwing up. I'm an even stronger believer that you should tell people when they are doing something right. Here is what he wrote about me.

“Derek is one of the most dynamic, creative, and detailed people I know! His "can do" perspective and dedication to mission success provides one with the confidence that Derek will do what he says he can in the time he says he will do it! Promises made, promises kept! He learns any and everything needed to make the mission successful. I have truly enjoyed working and collaborating with Derek on several opportunities and recommend him for any job or task. He makes good things happen!”

Rick Gonzalez, Vice-President Enterprise Solutions, Chenega Technology Services Corporation

Thanks Rick! It was a pleasure doing business with you.

Kobayashi Maru for Projects

Without trying to appear to be too much of a geek, I sometimes code-name a project as Kobayashi Maru. For those out there who are not Star Trek geeks, Kobayashi Maru is a test in which command division cadets at Starfleet Academy are presented with a no-win scenario as a test of character. I use the term for a project in which management gets involved and I'm presented with a no-win scenario.  I doubt they are trying to test character. Rather, it's an example of their lack of understanding project management. I'm sure there are PMs out there who have had management redirect resources from your project to others, only to refuse to narrow scope or push out a delivery date. That is a Kobayashi Maru.  Just because I have a PMP®, don't expect me to pull a rabbit out of a hat.  On a previous program, I've looked management in the eye and reminded them that something will have to give.  Narrow scope, extend the deadline, lower quality expectation, or increase the budget.  Do something or this will be a no-win scenario.

Image from : drexfiles.wordpress.com

What is missing from a Cost Performance Report

I recall a very positive meeting where we exposed several non project management team members to a Cost Performance Report (CPR) for the first time. A CPR addresses project performance through a defined period of time in relation to contractual requirements.  The CPR details budgeted work scheduled and performed, actual cost work performed, and the variance in both schedule and cost.  All of this is itemized per Work Breakdown Structure (WBS) element for both the current period and the cumulative to date.  The last values you see are the budgeted, estimated, and variance at completion of the contract. There were a lot of questions as to why one WBS element has a positive or negative cost variance and why it may have a positive or negative schedule variance.  Trying to explain this to those without a project management background can be a challenge.

I was having a sidebar conversation with one team member who could not understand how the element that pertained to him could be both ahead of schedule and below budgeted cost. The answer came from across the room in the form of a question.

"Is there any way this report captures quality?" The answer was no.

That my friends is called Triple Constraint.  We know the Scope, Time, and Cost within this report.  What we don't know is Quality, Risk, or Customer Satisfaction.  That's ok.  This is the CPR, not a Total Project Status (TPS) Report.

By not committing the scheduled time and budgeted dollars to complete the task to a level of quality that meets the customer's expectations, the contractor looks good only on paper.

Using Project Management Templates

At my last engagement, there was a lack of matured documented process.  I'm all about process. If you have good process, quality results will follow.   People sometimes don't understand that if a documented process does not provide value to the project, you should not do it.  Consistently use proven templates, processes, and methodologies to refine your project management approach. Templates are mere tools in a toolbox.  Again, only use the ones that provide value to the project.  I once had a Product Manager voice her frustration because she was told to complete ALL of the project templates in the repository, after the project was in a later phase.  My response was to weigh the cost (time) of completing the templates against the benefits gained by them.  The benefits are traditionally lower risk or higher customer satisfaction.  In this case, it was neither.  If anything, there should have been Lessons Learned or Postmortem document that would have identified the gaps or overlaps of the documentation.

To assist readers of my blog, I'm going to start uploading templates I've used at previous engagements.  They are free of change and will fall under public domain.  You'll find them by selecting Free PM Templates or locating the link in the right navigation menu.

Triple Constraint

Triple Constraint

With Project Management, you must understand that EVERY project has constraints.  Unfortunately, project managers tend to ignore this and it will come back to haunt them time and time again.  Constraints include time, scope, cost, quality, risk, or any other factors that will limit what your options are when managing a project or deliverable. "Triple Constraint" is a term that originally included time, scope, and cost.  Newer definitions include customer satisfaction, risk, and quality.  If you're preparing to take the PMP® exam, include both the original and newer definitions.  Sextuple constraint just doesn't quite role off the tongue. I try to stress to stakeholders every time they try to expand scope that it will directly impact the other constraints.  If you expand the scope, you will either have to expand cost or time.  If you don't expand either of these two constraints, you're going to increase risk and lower quality.

You'll first read about constraints in section 1.3 of the PMBOK®.  PMI will only refer to them as constraints at that time.  Y0u'll find them referenced at other locations within the PMBOK as project constraints.  What you will not find in the PMBOK 4th edition is an actual definition in the glossary.

Gold Plating

I once had a customer became highly incensed when told the deliverables he wanted were not going to be completed on time, due to a lack of resources.  He said he didn't understand why his highest priorities didn't get completed but extra features not asked for were.  When told additional features had recently become priorities he strongly disagreed.  His response was the person requesting or making the changes thought the changes were important but they were NOT.  If the changes were important, they would have been requested directly by the President of the company. (It sounds dramatic but it was true) Though there were certainly issues, at the time, as to who had authority to authorize a change, what happened was an example of gold plating.  Gold plating refers to providing the customer more then they ask for. (e.g expanded scope, functionality, higher quality)  Though this practice is based on what someone thinks the customer would like, it doesn't necessarily add any real value.  Both risk and cost will increase on the project because the requirements must still be met in the allotted time and budget.  As tempting as it might be, it is strongly recommended not to gold plate.  Try to make your customer happy by keeping your project within scope, on time, and on budget.

If your customer (or person authorized to approve a change) does indicate the change will add value, inform them of the impacts to the schedule and budget (and potentially quality and risk) and get their formal agreement to do the work.  Though it's easy to say you should not agree to make the change, the reality is you need to make the customer happy and they will make the final call.  Negotiate with them, to ensure the requested change will have a minimal impact to the current scope being completed.  In a perfect project management world, free of zombies and runaway stakeholders, there would be a separate funding vehicle and it would not impact the baseline.