Browsing Posts published by melbost

Some people are bitten with it an early age.  Some in later life.MH900309173

Some experience it through an event that happened directly to them.  Some experience it by watching someone else impacted by an event.

Some are touched by a revelation about some aspect of life that they either did not understand before or to which they had not previously been exposed.

No matter how it happens to you….BECOME A LIFE-LONG LEARNER.

Embrace what you know, but acknowledge what you don’t know–especially what you know you don’t know.

Choose a “philosophy of life” and let your experiences and relationships guide you to a higher level understanding of what life is all about.

Lou Tice once said “People act according to the truth as they perceive it to be.”  Yes, everyone has a different TRUTH they are living by….one that is based on how and what they perceive about their surroundings and environment.

However, be very wary that you don’t exclude other things from your environment that you need to learn as the world evolves on a day to day basis.  It is so easy to be a life-long learner about those things you want to learn about, but to be oblivious as to other things you need to know.  This is a mistake.

In your Project organization, have you become a life-long learner?  Begin today.

footballLike many football fans last weekend, I watched the gripping championship games this Sunday.

What really hit me about these games was the enormity that they have taken on in recent times.  These are no ordinary football games.  They are duels between two teams fighting to make it to the Super Bowl on February 2….Ground Hog Day.

But even more than the games themselves, I began to watch the attention to detail that each team displayed.

And, the more I watched, the more it became clear that “it’s the little things that count.”  Yes, we all know that is important but all the little things add up to big things and the winner of this game was the team that paid the most attention to the little things.

As a Project Manager, do you pay attention to the little things?  It is truly the stuff that matters….the little things every day that add up to the end results.  Did you talk to that team member who seemed a little reluctant to call the vendor about a problem with the software you were using?  Did you remember to tell your stakeholders that a delay was around the corner because another project would not deliver its information on time?  Did you remember to authorize your team to enlist the help of an experienced resource who had lived through this situation before and delivered?

Think about the myriad of little things you see on your project every day.  You may never play in a Super Bowl, but your reputation as a top notch Project Manager will be assured if you pay attention to the little things.


713c77a096eda382f174d6209a0dcda13In my new book, Lessons Learned:  Taking Project Management to a New Level in a Continuous Process Improvement Framework, I develop a process for project managers at a Project Close phase of their projects to capture, document, and share lessons learned from their projects with the assistance of the project organization.  In the past, many project groups have attempted to document lessons learned, but inevitably they end up on some shelf in the archives of the group, and never really have any impact on the growth and development of the group’s project or business processes going forward. However, I believe that this situation is changing as more and more organizations are embracing the concepts of continuous process improvement.  The framework in my book emphasizes that it isn’t enough to analyze results or outcomes of the project process, and to document lessons learned.  The issue of “actionability” is key here. So what do we really mean when we use the term “actionability?” It means a number of things. First, it means that the organization has an intent to capture, document and share lessons learned. Second, it means that the organization builds in the capability to capture the lessons learned through a facilitated process in which the project manager, his team, and the stakeholders participate “actively” in the process.  There is some debate in organizations today whether the project manager is the best equipped person to do this.  Some organizations are dedicating this activity to a group that is unbiased in its approach, which has the facilitation, framing and reframing, and collaboration skills and competencies to make it work. Third, it means that the organization builds in the capability to actually implement the changes agreed to the in lessons learned statements.  This is not easy in some organizations.  But what I am advocating is that the lessons learned be written in sufficient detail that a knowledgeable person in that group who understands the processes and the complexities of the organizational “structure” can implement the changes.  Ultimately, this is what “actionability” is all about. Fourth, it means that the organization devotes tools and mechanisms of sharing the new changes and incorporating these changes in a way that makes them “the business of the company” and not just a “good thing to consider.” “Actionability” is about intent, capture, documentation, and sharing of project lessons learned in a way that it becomes part of the fabric of the company’s business.  If this is not the case in your organization, ask yourself why not.  Start today to assess where you are with project lessons learned and what path you can take to make all project lessons learned “actionable” in your business context.

How Project Management Relates to Business Continuity Management, Enterprise Risk Management, Vendor Management, IT Management, and Other Related Professions


By Barry Cardoza, CBCP

Business Continuation Consultant

(Note:  Barry Cardoza is an internationally recognized consultant in Business Continuation Planning, Emergency Response and Enterprise Risk Management.  He is the author of Building A Business Impact Analysis Process (BIA)The BIA is one of the key processes in Business Continuation Management.)


Project Management is often viewed as a specific profession, and it often is, complete with specific training and certifications. However, functionally, Business Continuity Managers, Enterprise Risk Managers, Vendor Management (often referred to as “Vendor Risk Management”) Managers, and IT Managers are also formally or informally “Project Managers.” Those managers, and managers in other related professions, do “project management” every single day. Additionally, those managers are often working on projects that require them to work together toward an organization’s common goals.

For instance, before retiring from the position of VP/Manager of Business Continuity for Union Bank, N.A. (now doing Business Continuity Consulting for large corporations as Barry Cardoza, LLC), it was not uncommon for me to be managing many projects at any given time. Those included projects to enhance our Enterprise Business Continuity Program, to install and manage new Business Continuity‐related software, to develop an Enterprise Contagion/Pandemic preparedness and response plan.  I could not have managed any of those projects without working with many other areas of the institution.

An example of how my “project management” often related directly to “project management” being done by other managers working toward a common institutional goal was when Union Bank created a project to put into place an enhanced and very comprehensive Vendor Risk Management Program. The overall “Project Manager” was very appropriately someone within the Vendor Management department. However, that person identified and included managers from many related areas of the institution including the Business Continuity Department, Enterprise Risk Department, IT Department, Legal Department and other areas of the institution. Each of those representatives with specific and unique specialties had to manage their own projects to produce results that would contribute to the overall enterprise‐wide Vendor Risk Management Program goals.

Mel Bost’s new and very excellent book  Lessons Learned: Taking Project Management to a New Level in a Continuous Process Improvement Framework is something that I wish I would have been able to read a great many years ago. It definitely would have helped me to avoid “pitfalls” that I frequently encountered.  For instance, just the book’s section on “Accidental Adversaries” covers potential “traps” encountered when multiple departments within an organization believe that they are working toward common goals, but find themselves in a situation where their own “view” of those goals may be in conflict with how other areas of the organization view those goals to be. I ran into that situation frequently, while never thinking of the related departments being “Accidental Adversaries,” or having Mel’s very valuable advice on how to identify, avoid, and/or resolve those situations.

I sincerely believe that will be of great value to managers at every level of an organization, regardless of their own specialties and regardless of whether they are working with the Private or Public Sector. Again, I wish that this book had been available to me many years ago. It would have helped me avoid a great many pitfalls that I encountered throughout my career

MC900294234In the field project management, there are instances of what I term the “accidental” project manager.

This expression can have several connotations, and I would like to give two examples to illustrate the characteristics of the situations.

Once again, “perspective” is important in determining which connotation you tend to conjure up; depending on your personal beliefs about what a competent project manager should look like; i.e., your background, behavior, and performance, you may have a very different idea of what it means to be a project manager.

For example, I have worked with many project organizations who exhibit the full spectrum of beliefs from “Anyone can be a Project Manager” to “Only those officially certified by the Project Management Institute (PMI) can be considered project managers.”

Believe me, there are competent project managers who exist throughout this spectrum.

Typically we define a “project” as having he following characteristics:

1.  Definite Start and Finish Dates;

2.  Defined Resources; and

3.  Schedule, Budget, Scope and Quality Objectives.

Example No. 1:

Recently, our neighborhood’s Homeowners’ Association purchased a used “play” and “gym” set for our neighborhood park area in the subdivision.  When they decided to have it delivered and installed, they were faced with the situation that they had purchased it “as is,” with no guarantees with regard to moving the set or installing it.  So, they decided to look for a “project manager” among the ranks of the neighbors; i.e. someone who could oversee these tasks.

About six months prior to this, a neighbor of mine had orchestrated a backyard wedding for his daughter complete with lighting, music, and the other appropriate support equipment.  The wedding was considered very successful in the neighborhood, and the father of the bride was given many “kudos” for a job well done.  As the Homeowners’ Association prepared to move the play set to the park, they were informed by several residents about the success of the backyard wedding, and the “expertise” of the father in planning and executing the wedding.

The Homeowners’ Association approached the father, and gained his agreement to be the “project manager” for the “play” set move and installation.

This is one example of an “accidental” project manager.  Typically it is a person who appears to have the skills necessary to take on an important task, but who has not been truly evaluated for his fit with the new task.

Example No. 2:

Over the past twenty years, as many organizations began to shift from “operational” and “initiative” work processes to using “projects” as a means of converting strategy into action in modern organizations, many of the “operations managers” were tapped to become “project managers” who to lead the organization into the new era of project planning and execution.  Never mind that many of these “operational managers” had never heard of project management, a project schedule, or dedicated resources for projects, they was appointed to “make it work.”

Most of us who have worked actively in the project management field for many years have many examples of the second scenario, even in highly respected organizations.  The old “chicken” versus “egg” scenario has been implemented many times.  Project managers have been assigned responsibility and roles without having any project management process, standards, or procedures to use.  And their training has been sorely lacking.

Typically, what happens in a situation such as this is that Management asks the question “Does anyone have any standards for project management that we can use?”  And the answer typically comes back “There is a Project Management Institute with a website and Certification for project managers.”

So, how should project managers be matched with upcoming projects?

One method that I have seen successfully implemented was offered by American Express as a Best Practice through its affiliation with the Corporate Executive Council’s PMO Roundtable.  They used a spreadsheet with two major parameters: (a) Competency Level of Project Managers; versus (b) Complexity of Projects.

The project group would rank the skill and competency level of its PMs at one of five levels.  Each project, in turn, would be evaluated versus about 20 complexity factors.  Many of the complexity factors would reflect, for example, the number of marketing regions affected, the number of internal company business units affected, environmental considerations, etc.

Now, this spreadsheet was just a tool that aided Project Group Managers to compare project managers with upcoming projects.  The intent was obviously to reduce the risk of making a bad project manager decision.  But, that is the case in many of these analyses.

If the Homeowners Association Board had such a tool, for example, it still might not help the Association, however, since their pool of available project managers was lacking.  Their problem was just finding available candidates for volunteering.

It is hard to predict the success rate for each project manager in the two scenarios presented.  It depends on a number of factors.

I would like to believe that the maturity an organization exhibits in its work processes would be indicative of the way it chooses competent project managers.

How does your organization handle this?

P.S.        Now, those of you who have seen the movie “Hoosiers” would probably not consider Coach Norman Dale (Gene Hackman) to be a project manager.  No one qualified him as a project manager.  But he had a definite start and finish dates with the basketball season at Hickory High School, he had limited resources in terms of a team and coaches (although Dennis Hopper tuned out to be a great resource) and he had schedule, budget, scope and quality objectives to meet.  Could he have been an “accidental” project manager?

The other day I was listening to a speaker on TV talking about his experience with a waiter in a restaurant recently.  He was focusing on the expression or phrase “No problem,” which the waiter continually used during the process of waiting on the customer.  The TV speaker indicated that he was very thirsty when he sat down at the table, and initially said to the waiter “Please bring me a glass of ice water with lemon.”  The waiter’s response was “No problem.”

Now, the expectation of the customer was that the waiter would bring the water immediately since the customer was very thirsty.  The waiter’s interpretation of the request was that he could bring the ice water with lemon when he was free from his other IMMEDIATE duties of taking lunch orders, serving customers their food and circulating among the customers to make sure the lunch went smoothly.

When the customer failed to get his ice water with lemon the next time the waiter appeared at the table, the customer said “Where is my water.  I am extremely thirsty today.  I need water.”

Woman Drinking Glass of Water

Now, what is happening here?  A difference in expectations, along with lack of clarification of just what each person needed is at play.

How many times have you as a project manager thought to yourself “No problem” when a stakeholder asked for an additional report clarifying how something in the project process was to be handled for that customer?  Is there mismatch in expectations, or are you very clear about when and how the stakeholders’ needs will be met?  Do you clarify what you expect from the stakeholders as a project manager, because keep in mind that this road runs in both directions.

Think about this.  It may mean the difference in everyone being kept current with project plans, results, and expectations.  You will be surprised how often this very situation happens in modern PMOs.


Jack Roth was a project manager who had been managing a major project for a large PMO for about nine months. The project had a two year duration, and was slated to provide new functionality and systems for a major revenue component of the company.

One morning Jack arrived at the office to hear the news that a Program Manager who had been managing a major effort that linked three projects into a program was leaving the company to join a major competitor.

Jack had often thought “What would I do if offered an opportunity to take over a major program in this company? I am not sure I am ready, but there may be little time to think about it if the offer comes.”

Jack called his wife Susan to tell her of the news, and to discus the ideas he had considered in making such a move. Of course, someone else might get the opportunity so he decided not to get too excited about it. Susan and Jack had often talked about such a “break” and what he might do in case it came. But they had never really done much planning because things always seemed so stable in Jack’s company.

Susan told Jack about a story she was familiar with regarding Leonard Bernstein, the great conductor of the New York Philharmonic Orchestra. She emailed him a link to the story from “America’s Story,” a collection of stories about the lives of great Americans.

That story is set forth below:


Leonard Bernstein’s Debut

Many people’s careers begin after they get a “break.” On November 14, 1943, Leonard Bernstein made his debut as a conductor for the New York Philharmonic at Carnegie Hall in New York City. This was Bernstein’s “big break,” and a major turning point in his career. He got this break because he was substituting for another conductor, Bruno Walter, who had fallen ill.

Bernstein had been appointed Assistant Conductor for the New York Philharmonic only a few months before that night. Just 25 years old, he was relatively inexperienced. At the last minute, Bernstein was told he was to take Walter’s place, so he did not have any time to rehearse. The music he was going to conduct was very difficult. Plus, the concert was going to be broadcast nationally on the radio. Despite all these pressures, Bernstein rose to the occasion and received a standing ovation at the end of the concert. The event made national headlines, and Bernstein became famous overnight.

Some people feel they do their best under the most stressful of circumstances. Have you ever been asked to do something you weren’t prepared to do? How well were you able to perform? What was it about Leonard Bernstein that made him do so well in such a difficult situation?

Perhaps Leonard Bernstein did so well because music was his passion. The son of a man who supplied hairdressing products, Bernstein became interested in music at the age of 10. By the time he was a teenager, he was performing in public. He became a soloist with the Boston Public School Orchestra, and for 13 weeks in 1934, played classics on the radio.


As they finished their conversation and Jack had put away his cell phone, he thought to himself “Do I have the passion for project management that Bernstein had for music?” He reflected back over some of the crises he had handled in his project assignments and his desire to excel in this field.

Suddenly the office phone rang. Jack picked it up. “Hello, Jack Roth here.”

“Jack, it’s Peter Stevens.”

Peter was the Vice President, Program Management and Strategy Office for the company.

Peter continued “Jack, could you see me at 2 PM this afternoon to talk about a new assignment?”

“Yes, Peter, I will see you in your office at 2 PM. Thanks so much for calling.”


I have introduced a new term in this blog….LLearning.

“LLearning” means “learning from lessons of projects or operations in a group.”

This is to be distinguished from Learning, which means “formal learning or programs introducing new skills or competencies.”


Both are important to our discussion in this blog.

As project managers and PMO practitioners, we all recognize the importance of PROCESS, PROCESS DEVELOPMENT, and PROCESS IMPROVEMENT to the success of our organizational initiatives.

A PROCESS is a set of activities or tasks that, when performed in a specific sequence, yields an outcome or result versus an initial objective.  PROCESS insures consistency and repeatability of delivery of results and outcomes.


PROCESS IMPROVEMENT is essential to incorporate new lessons learned into the PROCESS.

Based on my experience working with project managers and PMOs, I believe that several major, essential ingredients of PROCESS DEVELOPMENT are “Learning,” “Sharing,” and “LLearning.”

continue reading…

Many readers of my blog will know that I have discussed Best Practices in project management practices and processes a number of times.  Basically, a Best Practice is a process that an organization or group has utilized a number of times and achieved success with many times in regard to the objectives and outcomes of the process many.  Best Practices are usually defined within a group by examining the practices of the group, reviewing and monitoring the results of the process, and then recording the outcomes for future use in other applications.MP900385968

What I described above is, of course, an ideal situation.  In my experience working with a number of PMOs and project groups, they often understand the intellectual nature of Best Practices, and they utilize processes time and again that yield good results, but they fall short of actually defining these processes as Best Practices and, therefore, they lose out on leveraging, capitalizing, and finessing Best Practices to their advantage.  That is the theme and message of this post.  How can project groups and project managers take full advantage of internal Best Practices?

continue reading…

Many of the followers of my blog will recall my references to the principles and work of Lou Tice of The Pacific Institute.  Lou Tice was a teacher and a leader who guided the development of many managers in large and small organizations.  His “Achieving Your Potential” and “Investment in Excellence” Programs have been a mainstay for internal development of key personnel for many years.Boy in Swimming Pool

One of the key messages I remember from his programs dealt with making plans and then acquiring the resources and capabilities to carry out those plans.  Lou Tice’s teaching and principle was that managers do not have to have all the resources at their command to make bold plans.  Indeed, it would be rare for them to do so.  But many managers act just the opposite.  They think they cannot make a move with any plans until they have all the resources at their command.

Lou’s theme was to make those bold plans and then find the resources and capabilities needed through the generation of internal energy that the mind provides in seeking a “solution” for the problem.  The “reticular activating” system of the brain and mind would take over and uncover all types of resources and solutions.

continue reading…

Avid readers of my PMO blog will know that one of my favorite topics is the activity and behavior and resulting performance of project managers in a Program Management Office (PMO) setting. I have written numerous “essays” on this subject based on my observation of project manager behavior in the past twenty years or so.

Although to this point, I have not reviewed a book on PMO or project manager behavior, I have always left open the possibility that there might be a candidate book in the PMO universe that would be worthy of review and comment. Such a book has surfaced and I want to provide my many project manager colleagues with a straightforward and very objective review of its contents.

This June, AMACOM Press released a book entitled Emotional Intelligence for Project Managers by Anthony Mersino.

I believe the objective of this book was to provide project management practitioners with concrete actions that they could take to enhance their project performance by incorporating research findings from the Emotional Intelligence (EI) discipline into their everyday project lives.

At first glance, the topics of Emotional Intelligence and Project Manager Behavior seem like two unlikely topics to try to bring together.

Mersino appears to be someone well-versed in EI, and trying to apply it to the discipline of project management could admittedly be difficult to do.  So that gives me some reason to question why the author tried to associate these two disciplines.  What was the underlying motivation?  If such a cross-disciplinary approach was handled skillfully, it could be a winning proposition; but, if not, it might be a flop.

My sense is that this book is very heavy in explaining EI, and a little short on really making a case for linking it to real everyday project manager behavior ,which leads to good and bad performance on the part of the project manager.

This insight is from someone who has worked in PMO and Project Office groups for a long time, and who studies these behaviors from the results they achieve.

Let me give you an analogous example. I am currently reading the book The Doctors Mayo by Helen Clapesattle in order to understand how the education and development of William and Charles Mayo contributed to the processes and practices that they instilled in the Mayo Clinic. I am reading this book to provide background on the influence of “learning” and “sharing” on process development for a future blog post for project managers.

If the book The Doctor’s Mayo had been titled, for example, Pathology and The Doctors Mayo, in which a thorough explanation of how “pathology” impacts medicine was provided, and then how the Mayos used pathology in their process development, I might have questioned the appropriateness of a book devoted to the linking of pathology as a scientific discipline to the development of the Mayos. Certainly other factors than pathology produced a total makeup of activity and behavior of doctors of the stature of the Mayos.

So, I really question whether Emotional Intelligence as a standalone topic and its impact on project manager behavior and team behavior can be a standalone linkage. Project environment, organization structure, and attitudes toward the PMO role in organizations, for example, can all play a part in ultimate project manager behavior and performance.

I am in no way questioning Anthony Mersino’s talents as a student of EI, and his intent to provide project managers with new insights they can use to enhance their performance, but in my opinion, his focus on EI as applied to project management is too broad to achieve his overarching goal of teaching more effective management of and by project managers.  That said, if you are interested in learning more about EI, this book may be useful to you.  You may also want to read some of Daniel Goleman’s powerful work in this area.

Some of my readers may have already encountered the book Emotional Intelligence for Project Managers. Those of you who have, I would be interested in your comments.

Disclosure—I received a free review copy of this book, but all opinions expressed herein are my own!

I really enjoyed watching the Open Championship last weekend. It is the oldest golf championship in the world, dating back several hundred years. The Open Championship, which is known more completely as the British Open Championship, draws the best golfers from all over the world to courses in England and Scotland in mid-summer every year to compete for the Championship.

MH900399966Those of us who live in the United States are very accustomed to watching the PGA Tour golf matches in the U.S.  And the golfers who compete on the PGA Tour also come from all over the world. It has become a very international sporting event in the last few years because golf is so popular in many places in the world. But sometimes, I really get the impression that American golfers think they invented the game of golf. Why do I have that feeling?  Because when they recall the great matches they have played over the years, they inevitably draw on simply their experiences in telling their stories of how the matches played out. When a golfer tried a new approach, or changed the way he putted or stroked the ball, he always says what it meant to him to be able to play at such a high level of expertise. There are even some golfers in America who are idolized by their fellow golfers for the number of championships they have won or how they played the game. This is great to listen to on TV because it really makes a good storytelling event.

But I can’t help but feel when I listen to these golfers in the U.S. that they inevitably feel that they invented the game. There can be no other.

continue reading…

I once worked for a Manager in a Project Office for a major corporation who assigned various responsibilities to his project staff members so that our group objectives of being the benchmark organization for both project management and process management could be assured on an ongoing basis.

As an organization, we had just moved into a new building. At that time, conference rooms were not installed with modern video and acoustic equipment to facilitate conferences or presentations. The audio visual equipment was maintained by the HR Administration Group, and every time we needed to hold a meeting, a staff member would need to call HR Administration and reserve the appropriate equipment for the conference room. On the date and time for the meeting, the staff member was responsible for securing the equipment from HR, and setting it up in the conference room. At the conclusion, the reverse order was followed. Ultimately, what this meant was that a staff member could never be sure whether the equipment were, in fact, on hand when needed, and often last minute changes occurred to accommodate missing equipment.

As you might have guessed, my Manager assigned me as the AV Coordinator for our group. My first reaction upon hearing about this assignment was to be “miffed” that I would have to handle this assignment, along with my usual roles as Project Manager, Standards Developer, Benchmark Specialist, and Process Authority. What did I do to deserve this lowly assignment?

If you are familiar with Herb Cohen’s screenstories about negotiations, you will recall a story he told once about his wife actually buying a home on the North Shore in Chicago by getting all the stakeholders around her to agree that it was a good idea. Herb described himself as the “technical titular leader” of the household in making such decisions, and in negotiating the terms, but his wife had actually taken a lesson from his book, and surrounded him with the ultimate stakeholders who would ratify the decision. He was rendered no longer the “technical titular leader.” Such is the way I felt about my new AV Coordinator assignment.

As I agonized with this assignment for the group for about a year, I began to develop some insights about what good AV equipment and installation should really be. I became an expert on “bulb” change-out, electrical failures, projection screen mishaps, and general “where to get it done in an emergency.”

To make a long story short, I actually began to appreciate the role. As our group’s needs expanded to be able to connect remotely with AV sources, and to enhance the effectiveness of our presentations, I began to realize that this AV competency was just as important as the project management methodology I had been wrestling with as I interfaced with our major corporate consulting organization.

Over time, I began to realize what an important role the AV Coordinator role was to the Project Office, and to the corporation. It was the “entranceway for knowledge to flow into our groups and into our heads.” Well, maybe not exactly, but you know what I mean.

The message here ought to be very clear indeed—it’s the little things that make up the larger competencies and capabilities that are so important to overall success of a role or a career. Often the messages that dominate the little things are the same messages that dominate the actions and decisions of an individual or of a group. But it’s often hard to see for yourself by looking at it through your own eyes. Getting out of your own body, it would be so easy to see how every little thing you learn contributes to your being able to do almost anything in life. Keep this in mind the next time someone asks you take on an assignment that you think is beneath your standing, or is not worthy of what you aspire to be. You may learn just what you don’t know that will lead you and others around you to success.

As most readers of my blog already know, in summer 2011 I traveled to Panama to facilitate two courses in Project Closeout and Lessons Learned for the Panama Canal Construction Division. The Panama Canal Authority is engaged in a Canal Expansion Program which is scheduled to complete in August 2014 which happens to be the Centennial of the opening of the original Panama Canal in 1914. This Expansion Program will not only allow larger ships to navigate the Canal using a third set of locks but will make infrastructure improvements in water usage and environmental usage of land.

As far back as 1850, many countries around the world talked about the desirability of connecting the Atlantic and Pacific Oceans for transportation and navigation purposes. It was assumed that the most likely spot would be in the Isthmus of Panama which represents the narrowest land area bordering both the Atlantic and Pacific Oceans. That was probably the first of many “assumptions” which would be made about the “Panama Canal” and how it might be constructed. As most of you project managers know, “assumptions” can be the downfall of good projects and of those not planned or executed so well.

Little did I know in 2011 when I spent ten days in Panama that it would launch a new understanding of the advancement of both project management and project risk management practices. The history of the Panama Canal development since 1850 mirrors the birth, development and improvement in project/risk management practices. And, as they say “the proof is in the pudding.”

For those of you who like to understand the background behind the development of a process or an invention or even a methodology, this is a real opportunity. I would recommend that you read Tom Kendrick’s book Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your ProjectsMH900183518. Each chapter of this book contains a section on some aspect of project/risk management as it applies in the case of the Panama Canal development. From the first unsuccessful project to the second successful project to the interim improvement projects that have led now to the Panama Canal Expansion Program, this book gives a good view of how good and bad or nonexistent project and risk management practices can create project outcomes that are long lasting and very tangible.

For example, the first Panama Canal project by the French made gross assumptions about canal construction in Panama based on the French experience in completing the Suez Canal in 1869. The project was a commercial venture with many investors. However, the leader of the project was not technically trained and he failed to scope out the Panama Canal Situation and to define the many “risks” that Panama would present. As a result, the cost estimates were updated almost weekly as the project team learned more and more about what they did not know in the beginning.

The story of the French project is almost the same story as some of the nuclear power plant projects in the United States during the last 50 years. Cost escalation was astronomical and eventually the project was shut down, a failure to really define and carry out a realistic project plan for a Canal. The failed project had such far reaching percussions that some have said that it led to a new French government in 1892.

The second project was an American sponsored project by Teddy Roosevelt and the United States Army Corps of Engineers. Several chief engineers were employed on this project which did a better job of assessing “risks” and scope than did the French project. Nevertheless, the successful American project was a story in new technology development of dam building and electricity systems and controls.

Today’s Panama Canal Expansion Program is a $5 billion program with megaproject management and extraordinary risk management techniques being applied. It will be interesting to see the program completion in 2014 to ascertain how far project and risk management practices have advanced.

I encourage you to continue to read this blog for the latest thoughts and insights into project, risk and knowledge management subjects for project managers and PMOs. Thank you.

POST NOTE: In the 1850’s, the desire was so great to create a transportation link across Panama from the Atlantic to Pacific Oceans that a Panama Canal Railroad was completed in 1855. Based on well known railroad technology that had been utilized in many countries to that point in time, it set in motion a logistics and transportation evolution in Panama that has made that country a center for “supply chain and logistics” practices. There are many sea ports in Panama on both Atlantic and Pacific sides and the railroad links to all these ports have furthered this logistics development. When I was in Panama in 2011, my taxi ride from the hotel to the Panama Canal Education Center where I facilitated my courses took me by many railroads and supply centers. It was really impressive. You may want to read more about Panama’s Supply Chain and Logistics hub activities.

In my work with Program Management Offices (PMOs) for the past few years, I have developed some observations about PMO maturity, and the capabilities and competencies that PMOs have incorporated into their overall organizational makeup. Typically, PMOs are formed in organizations to ensure that the project groups can consistently and repeatedly deliver excellence in their project outcomes. Or, in the case of strict IT PMOs, they are usually formed to provide project strategy and execution of IT projects for the organization. They are also often formed at mergers between two large firms to insure that systems integration and application rationalization are handled in a systematic manner in order to achieve the expected synergies of the merger.

As Program Management Offices (PMOs) mature in their capabilities and delivery, they receive much feedback from the stakeholders that they serve concerning what they did right, and in what areas they need to bolster their capabilities. This feedback comes from auditors, from business functional areas that are served by the PMO, or from systems/applications/infrastructure delivery in the case of an IT PMO. How well the PMO meets overall organizational objectives and goals is very important to the future of the PMO and its growth.

In my experience, two capability areas that most PMOs almost always improve are Vendor Management and Risk Management. Although these two areas might have been given simple methodology tasks at the outset of the PMO, it is the feedback from stakeholders and the organization, as well as PMO benchmarking outside the organization, that determines to what extent Vendor Management and Risk Management are improved in both competencies and capabilities.

Technology development is a third area that normally receives much PMO attention during growth and maturity because more and more projects have a technology development component that cannot be addressed on a “one off” project basis for long if the PMO is to ensure consistency and repeatability of delivery.

At some point in the development of every PMO, the topic of Knowledge Management is raised as an additional capability area that must be addressed. This happens in several ways. First, the larger organization in which the PMO resides may already have a Knowledge Management system that captures, defines, classifies, and documents data and information for the larger organization. The second way in which Knowledge Management systems are often introduced in PMOs  is as a result of recurring problems in projects that are not detected until they have hindered the delivery in three or four of the projects. Then, PMOs get interested in capturing these problems, their solutions, and what can be done to prevent them in the future. They may start with a simple Project Lessons Learned initiative to get the ball rolling. Lessons learned are one of the principal pathways for data and information to be capture, stored, and analyzed in a knowledge management system.

Michael Koenig, in his paper “What is KM? Knowledge Management Explained,” from KM World, May 4, 2012, explains the difficulty that most organization have in implementing effective lessons learned processes.

“The implementation of a lessons learned system is complex both politically and operationally. Many of the questions surrounding such a system are difficult to answer. Who is to decide what constitutes a worthwhile lesson learned? Are employees free to submit to the system un-vetted? Most successful lessons learned implementations have concluded that such a system needs to be monitored and that there needs to be a vetting and approval mechanism before items are mounted as lessons learned. How long do items stay in the system? Who decides when an item is no longer salient and timely? Most successful lessons learned systems have an active weeding or stratification process. Without a clearly designed process for weeding, the proportion of new and crisp items inevitably declines, the system begins to look stale and usage and utility falls. Deletion, of course, is not necessarily loss and destruction. Using stratification principles, items removed from the foreground can be archived and moved to the background but still made available.

All these questions need to be carefully thought out and resolved, and the mechanisms designed and put in place before a lessons-learned system is launched. Inattention can easily lead to failure and the tarring of subsequent efforts.”

I have witnessed this difficulty in implementing project lessons learned processes in several PMOs. Typically “project lessons learned” are perceived by the project managers and teams as a means of “assigning blame” for things that went wrong in projects. Politically, the project managers, and even management, shied away from attempts to identify lessons learned. Certainly they did not want them documented for others to read and remember.

However, there may actually be an alternative pathway to Knowledge Management systems that most organizations have not leveraged to this point. It’s called “Project Risk Management.” If your organization has a robust project risk management process in place that identifies risks, monitors risks if they triggered in projects, and then facilitates an effective mitigation program for them, then focusing on project risks is a natural pathway to Knowledge Management that the PMO should explore.

I have depicted the relationships between Knowledge Management, Lessons Learned, and Risk Management in the triangle diagram below.


In a particular organization where the path between Lessons Learned and Knowledge Management seems torturous, then the path between Risk Management and Knowledge Management may present a clearer pathway. Of course, in a fully mature organization, the legs of the triangle would represent flows in both directions meaning Knowledge and Risk Management would feed and sustain the other as would Risk Management and Lessons Learned.

Program Management Offices (PMOs) will continue to seek ways to capture, document, classify, share, and use knowledge management. What I have provided here is food for thought about the origin of the data and information that they may wish to preserve in their KM systems. Some very mature project organizations have employed what is termed as “knowledge-based risk” whereby they define risk manager roles, and feed those roles with knowledge so that they make informed decisions for future project efforts. NASA, for example, has some of these groups.  You may want to consider such a structure for your PMO.

Copy Protected by Tech Tips's CopyProtect Wordpress Blogs.