More on Lessons Learned

It is my belief from my years of project management that performing a lessons learned activity is one of the most critical processes for future project success and yet also one of the most overlooked and underutilized. We tend to get to the end of a project and breathe a sigh of relief and move on. Rather, we should hold one or more formal sessions with our team and our customer to identify what worked and what didn’t.

The customer always has a lot to say about any implementation and their opinion and input matters greatly. It’s best for you to hear it in a formal lessons learned process rather than have your customer follow-up with your CEO and give him an earful.

I’ve published some of my thoughts on Lessons Learned previously including an article from February 2009 titled simply “Lessons Learned.” Here, I present some further thoughts on lessons during the project implementation process from Jason Charvat’s book “Project Management Nation.”

Lesson Learned During Project Implementation

“What could be simpler than buying some computers, throwing them on a desktop, plugging them in and turning them on?”

The question is simple: The answer is much more complex. Complexity is almost always underestimated until well after the start of the planning process. Many of the elements of deployment require special coordination and handling due to the lack of direct control over the processes or compounding dependencies. Complexity can come from the technical nature of a project that attempts to take advantage of a new technology not yet tested by the corporation and requires full integration into the existing systems. These factors don’t surface until the project manager demands action or some form of change. Implementing a solution without testing it properly is not acceptable.

I Wish I Had Known That

Look for early warning signs that planned business benefits will not be delivered.

• It is not clear that achieving the business benefits is the top priority of those managing the project.
• Time scales and resources for training, testing, and implementation support have been eroded by project slippage, and there are proposals to cut corners.
• Acceptance testing is being carried out by IS specialists and there is no involvement from the business.
• Other parties, who were not previously identified as part of the project, are now being identified as needing to be involved in acceptance testing and implementation.
• Staff involved in developing and agreeing to the original business objectives have moved on.
• The supplier has not demonstrated that the new system is compatible with existing systems and peripherals.
• The solution needs to be tested and demonstrated within the proposed environment (including links to existing systems). Have the tests for accepting the system from the supplier been planned and agreed upon? Has the process for data conversion been planned and has sufficient time been allowed for it?
• All necessary on-site preparations were not included in the planning (e.g., accommodation, cabling, safety, and security).
• All dependencies, such as slippage on other related projects, have not been taken into account.
• Too little attention is paid to testing the final solution.

Defining Strategic Projects

In his book, “Project Management Nation,” Jason Charvat looks into Strategic Projects, what they are and how we translate corporate “strategy” into the projects for the organization.

What are Strategic Projects?

Where the project is a component of a broader business sense, it should be assessed as an integral part of the strategic program. All the normal financial assessment rules should be applied. The executive team should pay close attention to those parts of the proposed solution that clearly show the benefits of proceeding with the solution. Managers should ensure that detailed plans for achieving the benefits, and specific responsibility for delivering them, are in place.

IT planning must take account of the intended direction of the business, financial constraints and criteria, and human resource (HR) plans and policies. It must also be flexible enough to cope with any likely response from competitors over the whole project life cycle. Project managers should have a clearly communicated policy for the way to collect, use, and store information in support of the business objectives and the way the systems will enable them to harness the value of this information in the future.

Translating Strategy into Projects

Once the strategy has been determined and has been approved by the company executive team, the responsibility of the project success does not fall only at the feet of the project manager. The chief executive officer (CEO), chief information officer (CIO), directors, functional management, and staff all have specific tangible and intangible roles in the project. In this manner, mutual expectations can be met and benefits realized. For a successful transition from strategy to project, the business must have in place:

• Agreement on what needs changing, and why (this should be clearly supported by the project sponsor)
• A common “language” for analyzing and describing requirements, based on a shared understanding of the business processes across “client,” purchasing, and information systems (IS) departments (don’t assume this is the case)
• Agreed processes that involve the users in the selection and design of systems solutions (consider making a “client,” rather than an IS specialist, the program manager responsible for delivering the business benefits)
• The support of a skilled, experienced technology project manager

Each and every project should have some sort of a mission. The mission identifies the client’s requirements and clearly defines the purpose of the project. A project’s mission must be completed for success of the project. Objectives define the success criteria for the project. The objectives relate directly to the completion of the project’s mission. Completing all of the objectives should accomplish the project’s mission. Measurable objectives provide a method of quantifying the results and establishing quality standards to evaluate the success of the project.

Closing Out the Project – Part 3

In Part 1 and Part 2, we covered the first six critical questions listed below that should be addressed when closing out any project. In the finale, Part 3, we’ll cover items seven through nine highlighted in bold letters below:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?
• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?
• Do you feel the solution was cost effective?
• When would it be applicable to enhance or update the delivered solution?
• What is your executive leaderships view of the project outcome?

Do you feel the solution was cost effective?

Here’s your chance to analyze the solution in words in financial terms. And we’re not really talking about budget here, but that’s a big part of it. In hindsight, did the engagement:

• Utilize the best level of resource skills and thus use resources in the most cost effective-way possible.
• Should Phase A really have been implemented first as the customer required, or would it have been a more sound business decision, in your opinion, to implement Phase B first?
• Is the final solution meeting the customer’s needs in the most cost effective manner possible? Would certain enhancements or different requirements have resulted in a more cost effective solution?

The list could be long, but I think you get the picture. Ask yourself the tough questions and imagine this isn’t for the customer to see. In fact, imagine you ARE the customer on this one but also have your additional insight.

I’m not saying you can’t involve the customer on this one – you certainly can – or you can perform it separately with your team and then with the customer and compare results.

When would it be applicable to enhance or update the delivered solution?

You’ve probably had an eye to the future all along and you’ve probably already discussed some key points along the way with the customer – especially if the project was a successful one and the customer satisfaction seems high. That’s what a good project manager does.

Think about ways you can provide new and future services to this customer and certainly keep in contact with them post-implementation on future product capabilities that you feel they will want or can benefit from.

What is your executive leaderships view of the project outcome?

This one is important to your career. No question about it. How does your leadership feel about the project? This likely will come more from leadership’s discussions with the customer than from your discussions with the leadership. And it should.

If it was a visible, critical project, you know that they’ve been in communication with the client along the way and if anything has gone wrong, they’ve heard about it. They’re not as likely to hear about the successes, but if you think the project has gone well, encourage your CEO or other leadership to follow-up with the client and discuss the outcome with them.

Summary

We’ve covered what I consider to be nine key questions to review once your project has been implemented. Most are for you and your team, some should also include the customer. But be sure to perform some sort of post-implementation checklist like this. You’ll benefit from it as a project manager, your team will benefit from it in learning what went right and what went wrong, and your organization will benefit from it – especially if you can share the successes and the lessons learned with others in the organization.

If you have other key points or questions to add, please comment.

The Misconception of PMP Certification

I can’t get in to the PM Tips site at the moment due to a server issue in order to post comments, so I’m just going to write an article on the subject…since I think I can post an article through the login.

There have been great comments and discussions on the article I wrote entitled “Project Management: Is PMP Certification Worth It?” In fact, there have been nearly 100 comments posted on this article – by far the most of any on the site. I appreciate everyone’s comments and I think it’s been an incredible discussion – and it’s probably convinced many non-certified PMs to just go ahead and get certification.

The Premise

Remember, the premise of the article is that HR departments and hiring managers are becoming lazy in this job market by requiring PMs to have certification to even be considered for a position – it is happening on many jobs that are up for grabs out there. However, the overall perception is, it’s a game…if you want to play you probably should get certified. I agree.

Direction of Recent Comments

The comments are still coming through, but now they’re only trickling in. And what’s coming through now is equating PMP certification to an MD, or a CPA, or a certified CPR. I’d like to get my two cents in on these comparisons. I think they’re crazy.  (The comparisons, I mean…not the people making them.)

While all of those are important, they don’t equate to what a PM does. First, it’s not illegal for a PM to practice project management without certification. No one’s life is at stake. It is, however, very illegal to practice medicine without the degree. And sure, a person can administer CPR without being certified and a person can do taxes or manage your finances without being a CPA, but you’re probably more comfortable with a CPA doing your taxes. And as one comment suggested, if two people are standing over you when you’re choking and one is certified in CPR and the other isn’t but just knows it, you’d probably choose the certified CPR person if you’re given the choice. I would too.

Applicable to PMP?

How does this compare or apply to PMP certification? It doesn’t at all. PMP certification indicates you have a minimum amount of experience and passed a test so you know the fundamentals of PM and the PMI methodologies. What it doesn’t indicate are the soft skills that a PM must have to be very successful. A CPA or a person who is CPR-certified really doesn’t have to have the same interpersonal skills. They wife of a choking victim doesn’t care if the CPR responder can negotiate with someone or interact with the crowd of bystanders. They have one job to do and that’s it. The person having their taxes done by a CPA doesn’t care if that individual knows how to massage a customer and smooth over bad news. Or lead a team of project resources every day to accomplish all of the behind the scenes tasks. Not at all. They only care if their taxes are done correctly. And the CPA is pretty much a one-man show and he does the taxes correctly and that’s it. No song and dance.

For the PM, things are different. The work is not more critical or more important, just different. The PM must be able to inspire a team, bring confidence to a customer, manage a multi-million dollar project, answer to executive management, keep the CEO happy and do this on several projects at once. Again, not more important, just very different. And lots of soft skills that no test can ever validate. You either have it or you don’t. Some of these things you can’t get no matter how much experience you have, but experience usually can help you get there on most of them. Pass a test and getting certified won’t get you there.

I’ve been called in to fix projects where the customer was dissatisfied with the way the project was going so many times that I’ve lost count. A test doesn’t validate leadership, confidence, and that kind of experience.

Final Thought

So, yes, we all probably should be certified because that’s just the nature of how things are going. But, in my opinion, it’s very short-sighted to equate the PMP to an MD, a CPA, or CPR certification. It’s apples and oranges.

Work Risks to Your Advantage

I literally came up with this one in the shower last night. Not the concept…I’ve knowingly or unknowingly been doing this for years. But the idea for the article. I was thinking of the article entitled “When Project Management is Fun” and the concept of how keeping things edgy keeps people focused, energized, etc. That’s when it hit me. Risk is challenging. Risk is energizing. Fighting risk keeps a team cohesive. And it keeps a customer and vendor working in unison. Work it to your advantage.

It’s Never Easy

Everybody likes an easy, successful project and nobody likes and easy, successful project. No huge, visible, challenging project is every going to be easy and perfectly, swimmingly successful. Ever. If someone tells you their big project is running smoothly and perfectly then they are lying. When you tie together a group of opinionated, highly skilled individuals who also have other responsibilities than the ones you give them AND you add a customer with high expectations and large expenditures AND you sprinkle in an enterprise-wide solution with somewhat vague requirements (because requirements ALWAYS have some degree of vagueness to them), there’s no way it’s going to go perfectly or smoothly.

It may be successful….highly successful, but it will always take a good deal of effort to get there and you’ll have to fight your share of adversity along the way. And make your management know it…because you and your team might as well get the recognition for it at the end of the engagement. Let them know it wasn’t easy…let them know it was tough. Tell the CEO if you can.

Work the Risks

So, knowing that your large project is not going to go through the motions without risks and issues coming into the picture, focus a decent amount of effort on identifying and managing those issues and risks and make the entire project team own them…both the delivery side and the customer side. Ownership breeds caring…which breeds focus…which breeds productivity and responsibility and accountability. Your delivery team needs to be more than the resources who act on the tasks their assigned from the schedule.

You know how your workday seems more satisfying and goes faster when there is some degree of non-monotonous activities going on? Things that are out of the norm. Wrenches thrown in here and there…fires to fight. The same goes for the project. Don’t get me wrong, if I have 5 or 6 projects I’m leading at once, I’d prefer to not have multiple fires to fight on each project at the same time. I wouldn’t even mind if 3-4 of those projects were easy ones. But having fires around – and unmitigated risks can become huge fires – then things can never get boring. Let me clarify…I’m not saying one should let those risks and issues become big fires. But the challenge of identifying, assigning, managing and mitigating those risks and issues breeds creativity and brings a team together like nothing else. You don’t have to actually face the adversity…but knowing it’s out there if you don’t work together and do something about it brings a team together on a common goal and can make for a very enjoyable…and successful project.

Summary

The idea is to stay a step or 10 ahead of the risks and issues on the project. Identify them early with your team and with the customer. Assign them to individuals or groups of individuals. Come up with strategies to mitigate those risks if they should actually occur. And keep managing them and holding people accountable to them throughout the engagement. Those risks and issues hold the highest likelihood of derailing your project and making you unsuccessful. So manage them well and manage them carefully. And delegate….delegate often and well.