Everyone is talking about “Lessons Learned.”  With the wrath of hurricane Irene being felt up and down the east coast this week, David Gregory asked the FEMA Director on “Meet the Press” Sunday what lessons had been learned from Katrina that positively impacted the response to Irene.  Governor Christie of New Jersey declared that there would be an after action (review) of the response in his State to Irene.  “”Lessons Learned” became a buzzword in the press again.

What is my definition of a “Lesson Learned?” 

A “Lesson Learned” is an EXPERIENCE or EVENT that can be used to improve a process.  Lessons Learned arise from many different activities in life.  They can arise from car accidents, military conflicts, weather related events or just about any activity in which an ACTION leads to a RESULT or OUTCOME.  “Lessons Learned,” if captured and shared can lead to an improvement in the way these ACTION processes are handled in the future.

My experience lies in the area of Project Lessons Learned.

I have written extensively over the past two years in this blog and also through the podcasts with Wayne Thompson of “Project Management War Stories” that Lessons Learned are here to stay.  Companies and clients of many companies are demanding better mechanisms to guide their continuous improvement activities.

So, get with it!!!!    Lessons Learned for many daily processes and activities are here to stay.

Do you think that you can snap your fingers whenever you need some vital information? 

Do you think that your LinkedIn connections or your Facebook or Twitter friends will come running to your aid whenever you need help?

If it was late at night, and you were sitting in front of your laptop, in a foreign country, several thousand miles from most of your network, with a useless cell phone because you provider had no network, and you needed help, what would you do?

When this happened to me just a few weeks ago, I was thrilled by the responsiveness of my network, and I just had to share this fantastic networking experience with my readers.

Most of you know that I was in Panama recently facilitating two three-day courses on Project Lessons Learned for the Panama Canal Authority’s Construction Division. 

At the end of the second day of the second session, the division’s manager requested that, the next day, I speak to the class about some specific project lessons learned success factors and barriers experienced by other organizations.  He also wanted to know how these success factors and barriers fit into a cohesive project lessons learned system.  He requested this information because he wanted to impress upon the class that Project (and Contract) Lessons Learned would (and should) be an ongoing part of their daily activity.

I left the building that day worried because, while I had many examples, anecdotes, and ideas about project lessons learned success factors and barriers, I was not aware of any single document or study that would address his request.  Since I unfortunately hadn’t anticipated his request, after dinner that evening, I sat myself down in front of my laptop, and began to brainstorm about who in my network might be able to efficiently guide me in the right direction–time was of the essence since I had to be back in the classroom about eight hours later!

During my brainstorming, I remembered that Michael Guidry’s Northwest Arkansas PMI Chapter recently featured Deborah Grassi, a Senior Manager in SAP Change, Training, and Communication at WalMart.  Deborah spoke about lessons learned from a significant WalMart project.  So, I dashed off a quick email to Michael explaining my conundrum.

I sent another quick email to Dan Ranta, a Director of Knowledge Sharing with whom I had worked at ConocoPhillips. 

I also wrote to Wayne Thompson, my frequent collaborator on podcasts for his popular blog “Project Management War Stories.” 

I also recalled that Lisa Austin , a manager of Knowledge Management at Williams Midstream, had recently spoken to the PMI Tulsa Chapter about Knowledge Management at Williams.  While I had unfortunately missed her presentation, I thought contacting her was worth a shot since she and I are connected on LinkedIn.  Lisa quickly replied that, if I had not already seen the website and blog on Knowledge Management in the United Kingdom operated by Nick Milton, Director of Knoco, Ltd., I should check it out. 

Nick Milton was formerly a knowledge management executive with BP.  Now, is a knowledge management consultant who consults with corporations worldwide on knowledge management issues.

I quickly accessed Nick’s website, and found a section on Lessons Learned that included a survey that he had conducted in 2009 of companies in many different industries.  The survey discussed these companies’ varying Lessons Learned practices, which factors had been barriers in establishing Lessons Learned, and which factors had led to success in Lessons Learned and lasting change within the organization.


I immediately messaged Nick on LinkedIn and introduced myself.  I explained that we had common interests in Project Lessons Learned, that I was in the midst of teaching a course on the subject, that I had been referred to his website, and that I was very impressed by survey.  I requested that we connect on LinkedIn.  Almost immediately, Nick approved by connection request and explained that he was with a client in China, but that he would love to talk about our common interests in Project Lessons Learned. 

Nick and I emailed a few more times that evening, and Nick was kind enough to permit me to present his survey and discuss its findings with the course participants.

The survey had 74 responses from individuals in such varied industries as oil and gas, engineering and construction, consulting, mining, industrial products and services, etc.  It mainly focused on project groups, and it covered success factors, barriers, key systems components, and other enabling factors. 

As I read through the survey, I was pleased that it supported many of my recommendations, including the use of the After Action Review (AAR) as the preferred basis for a project lessons learned framework, as well as the inclusion of Risk Management when identifying candidates for lessons learned.

The next day, I distributed the survey to the course participants, and we discussed its findings within the context of the Construction Division’s business and project/contract environment. 

Throughout the day, similarly helpful information flooded in from my network.  In fact, nearly one hundred percent of the people that I contacted responded with useful information.

I learned two valuable lessons from this experience: (1) when training, listen—and be responsive to—your audience, as it often provides valuable insight as to how you can develop and improve your materials; and (2) believe in the power of your network!

Remember–the responsiveness of your network is entirely up to you.

As Robert Cialdini has stated in his work on INFLUENCE,  RECIPROCITY is a powerful motivator.   Always do what you can for others before asking a significant favor in return. 

Your network will only be as responsive to you, as you have been in fulfilling its needs.

Why is “Success” magazine so successful? 

Is it because the articles are so skillfully written that readers feel compelled to read the magazine cover to cover? 

Is it because the insights are so insightful that no reader can resist the articles?

Is it because John C. Maxwell always seems to grace their pages with his deep insights into Leadership?


It’s because everybody, no matter what their chosen field, or discipline, or career path, wants to “get better” and to “improve” their performance and their happiness in their chosen field.  People are searching every day for that bit of wisdom that will give them a clue about their own lives and their own happiness.

And you as a reader of this blog are no exception. 

It’s why you have accessed this website.  If you are a seasoned project manager, an aspiring young project manager, or a practitioner from another discipline or field, the idea that something “learned” may contribute to your achievement and happiness is important. 

And “project lessons learned” is even more important because everyone takes on “projects” large and small, formal and informal, approved and unapproved, budgeted and unbudgeted, every single day.

I have been studying and writing about project lessons learned for a number of years.  I helped a major Fortune 500 company develop a robust project lessons learned process and framework for their PMO organization.  I have contributed to several podcasts on the subject that have been well received by the project community.

Dan Pink’s work on “drive” is also very relevant here.  In studying groups that are engaged in highly complex work with significant intellectual content, he has found that three major motivators are at work:

1.  Autonomy:  This is the need for self-direction, the need to determine what and when a person will pursue in order to reach his own goals and objectives.

2.  Mastery:  People want to master their chosen “discipline” or field.  In the case of project managers, mastery means project managers want to pursue project lessons learned as the culmination of a successful project, as the pinnacle of sharing experiences and insights with the project community.

3.  Purpose:  People engaged in highly complex and intellectual work seek a higher purpose than just the profit motive for their efforts.  They want to know that the larger community of which they are a part will benefit from their efforts.  In the case of project lessons learned, they want to know that the project community will benefit long-term from the capture, documentation, and sharing of lessons learned.

Early in 2011, I predicted that we would see more Program Management Offices (PMOs) focusing on Project Lessons Learned as a primary rather than a secondary focus (as has been the case in the recent past). 

My interactions with many PMOs have revealed that this prediction is becoming true–more organizations are seeking to close-out projects in a more formal, systematic, and documented manner.  Project Lessons Learned is an excellent framework to follow when closing-out projects.  

There is no doubt that those organizations who successfully “convert” Project Lessons Learned into process improvements will gain a competitive advantage.

I just got back from working with the Construction Division of the Panama Canal Authority.  They hired me to train them on a Framework for developing Project Lessons Learned.  I facilitated two, three-day Project Lessons Learned courses. 

The Construction Division Management was fully supportive of introducing a Framework that would add to the “capabilities” of its staff to identify and document Project Lessons Learned.  They were committed to creating a continuous improvement project management environment that would close-out projects and contracts with an “actionable” Framework.

This Project Lessons Learned Framework will help the Construction Division successfully complete the major projects that make up the Panama Canal Expansion Program.

Their commitment was indicative of what I am finding as I talk to more and more PMO groups.   They all want to “get better” at closing out projects and contracts in a manner which creates “actionable” results within a continuous process improvement context.

If you are interested in making that next step toward full commitment to capture, document, and share Project Lessons Learned with a simple but effective Framework that focuses on Risk Management and continuous process improvement, please contact me to schedule a similar course for your organization.

You will be glad that you followed through–as a Benchmark group within the wider context of your organization, you can set the example for others to follow.

I have always thought that summer was a time for “renewal.”

After all, isn’t that why there was no school in the summer, and why your parents sent you to those summer camp “enrichment” programs?  It was so you could relax and enjoy some subjects and activities that you were not exposed to during the remainder of the year.  And as you got older, perhaps you had a chance to attend a special summer program in a college or university setting, where other students like yourself could engage in debates and cultural activities that were “enriching.”

At some point in your life, you may have noticed that there was a transition away from those “renewal” activities that were planned by others, to renewal activities that you planned by yourself.  Maybe you didn’t notice this transition since you were caught up in the fast pace of growing up, but, as John C. Maxwell has said, “man has choices and the choices a man makes in turn make him.”

So–Summer is a time for renewal.  It’s up to you to grasp those opportunities for renewal wherever they might be in your life.

And, if you are part of a larger project community, or a member of a Program Management Office (PMO), it might be time for you to seek out some activities to renew your PMO as well.

What better time than the summer to pursue such renewal?

Give this some thought.  How can I as a project or PMO practitioner provide some renewal activities for my PMO?

Show some leadership and initiative to make this renewal something that lasts year-round in your PMO.

For example, look at some liason opportunities with a local PMI Chapter, or some special training that could be brought on-site to enrich your colleagues in the Best Practices of a PMO.

Renewal is up to you.  No one will plan for it any longer.  Summer is a great time to pursue it.  Get started today.

Readers of this blog will know that I talk about behaviors of PMO project managers, team members, stakeholders, and others in the project community.  These are real behaviors that I have seen in my experiences working in and setting up several PMOs.

Much has been written in recent years about strategic partnerships in project management.  The idea is for parties to collaborate to ensure success of an organization such as a PMO long-term as projects are executed in support of strategic directions.

Consider the following scenario.  A PMO initiates a systems project in support of a major business/functional group in the organization known as the Commercial Group.  The Commercial Group is engaged in activities ancillary to the firm’s core businesses, and in order to achieve its returns, it operates in markets focusing on short-term, day-to-day operations.  The PMO systems project is designed to use a vendor-developed application, and its supporting systems, to provide the Commercial Group’s day-to-day operational and transactional focus.   The Commercial Group identifies a number of potential vendors and evaluates which vendor could supply the systems requirements on an on ongoing basis.  It then selects a vendor and development work proceeds until the system is in production.

Over the next several years the Commercial Group’s activities and returns flourish, and the vendor makes a  number of requested improvements.  Every time a new and updated system and application requirement was identified by the Commercial Group in response to the market, the vendor delivered.  

Switch gears for a moment….

A number of years ago while working for Atlantic Richfield Company (ARCO) in California, I had the opportunity to serve on the Board of Advisors for the University of California–Irvine Science Education Advisory Board.   The Board advised the professors and administrators in the School of Physical Sciences on their K-12 development programs for students and teachers.  Funding for the work was provided through contributions from local corporations to the Board.  Each year the professors and administrators solicited the corporations for funding based on the premise that the K-12 programs would remain the same quality and scope as in previous years.  After a few years, it was almost a foregone conclusion that the budget would be the same or perhaps increased slightly from the previous year because additional corporate contributors were identified.  An annual report of the Board to the contributing corporations provided details of the K-12 programs and the breadth of participation among K-12 teachers and students.

After serving on the Board for several years, I was summoned one day by two professors who were instrumental as leaders of the program.  Since I had background in strategic planning and analysis, they asked if I would take on a small project in support of the Board activities.  They were concerned that funding for the program seemed to be on the decline.  Over the past three years the funding had decreased by $20,000 each year so that the quality of the programs was in jeopardy.  They were at a loss to explain why the sudden decrease in funding over the three year period, and asked if I would undertake some analysis to assist in their planning.

I was glad to assist in this effort and studied the scenario from various perspectives for a month or so.  I interviewed corporate contributors, the teachers involved in the K-12 programs, the professors and other community groups.   I looked at other University groups who approached their funding in a similar way and others who approached funding from alternative means.

Here were my findings:

1.  The business climate in California had changed over the last three years.  Whereas aerospace and petroleum companies dominated the corporate giving scene three years earlier, biotech and medical device companies were beginning to emerge to take their place.

2.  An individual corporate contributor had many more choices in making contributions because many other groups in that California community were doing similar work with schools.

3.  Other University groups had emerged as new curricula developed and these groups increased the number of total University groups seeking corporate contributions.

4.  The methods of solicitation of corporate funding were changing.  Many groups partnered with the stakeholders in the K-12 schools who received the benefits of the programs to provide a brochure to corporate contributors that tied real benefits to both the provider and the receiver.  This method was unlike the solicitation method of the School of Physical Sciences, which relied on its past work to carry the story.

The real themes from this analysis were:

1.  Don’t rely on “static” data to tell a “dynamic” story.  Look at the dynamics of the situation rather than a point in time.

2.  Don’t consider yourself to be the “Center of the Universe” when it comes to activity.   Look at the Corporate contributors as the “Center of the Universe” and map the interactions they have with the groups requesting funding.  This tells two things.  There are more requests than in previous years and many of the requests tell a story that clearly ties in the end result with the level of contribution.

So the real story of the fall-off in corporate contributions was in the dynamics of the business climate and the solicitation model.  Never look statically when you should be looking dynamically.  Never consider yourself to be the “Center of the Universe” around which other activities revolve.   It is a recipe for disaster.

Now, what does this have to do with our scenario of the PMO group and the systems application supporting the Commercial Group?  Over time, as the Commercial Group grew and its business grew, more and more was asked of the vendor who supplied and supported the systems application which facilitated the transactions enabling the Commercial Group to flourish. 

But, there came a time when a new business requirement relayed to the vendor was met with the response “We don’t have any more resources to do this enhancement.   All our resources are fully employed to support the day-to-day operations.” 

The PMO was incredulous.  It had created a strategic partner without really trying.  But it had failed to plan for the development of its partner to support new development work.  Why?  The PMO focused on the static scenario, rather than on the dynamic scenario.  They felt they were the “Center of the Universe” when it came to that vendor’s support.  In actuality, the vendor’s business had grown to support other major companies as well.

This is a good example of how companies can put strategic vendors in place without really trying.  It sounds rather farfetched.  But it really happened to a major PMO organization.  Is your PMO ready to define the capabilities it needs both internally and with external vendors to support the growth that it desires?  Is your PMO looking at static conditions rather than on dynamic conditions for its decision making framework?  Does your PMO consider itself the “Center of the Universe” when it comes to dealing with other key groups and vendors?

I would be interested in your feedback.  Thanks for your time.

“We had everything to gain by planning and working closely together to advance the development and maturity of our new IT Project Office, but it seemed that every time we would take a step together in the right direction, one of us would sideswipe the accomplishment by acting irrationally or in what seemed like an irrational manner.”

Those were the words of my former manager in an IT Project Office (a predecessor to the modern PMO).  It is an often-repeated statement, but one which does not get much scrutiny from a root cause analysis format.

Here was the scenario:

A major energy company acquired the downstream assets of another energy company, and integrated the functional groups, including the Information Technology groups.  At the start of this scenario, I was a Project and Planning Consultant in the IT Planning Group.  The Information Technology group decided to form an IT Project Office (ITPO), and it hired an experienced manager from a major Fortune 500 Company whose expertise was in forming and maturing PMO-type organizations.  Prior to that point, each IT Applications Development, Systems, and Infrastructure Group had planned and executed projects within their own groups with limited collaboration across groups.

A major consulting firm had facilitated the merger of the two energy companies, and Management of the merged company strongly recommended that the Information Technology group use the consulting firm as a “guide” in forming the IT Project Office.  The consulting firm had an excellent reputation for internal project management capability, and it utilized a methodology which I will refer to here as “THE METHOD.”  So, Information Technology Management was pleased at the outset that they not only had an experienced PMO-type Manager, but also a strong consulting group direction.

The “vision” and directions given by the IT Project Office Management to the consulting firm were that the ITPO wanted to instill its own “trademark” and “business context” in the new project group. 

While the consulting firm heard this “firm” direction,” it internally recognized that the firm had made a great investment in “THE METHOD” and that it would exploit “THE METHOD” at every opportunity.

The IT Project Office utilized the SEI Capability Maturity Model as a framework for planning its path of evolution to a mature state.  However, whenever a new process or procedure was developed in concert with the consulting group, the outcome had a strong flavor of “THE METHOD.”  So, whenever the IT Project Office mapped its systems projects to follow the business processes with which it was trying to align, it conveniently left the consulting group out of the process until some redefinition of an omitted process was imminent.

This recurring pattern of behavior was subtle but highly visible to those of us living the daily ITPO experience.

This is an example of a “systems archetype” at work. 

Peter Senge has written extensively about organizational dynamics and behavior and systems archetypes identifiable from events and patterns of behavior.

William Braun has also written extensively about systems archetypes.  System Archetypes are highly effective tools for gaining insight into patterns of behavior, themselves reflective of the underlying “structure” of the system being studied. The archetypes can be applied in two ways – diagnostically and prospectively.

Diagnostically, archetypes help managers recognize patterns of behavior that are already present in their organizations. They serve as the means for gaining insight into the underlying systems structures from which the archetypal behavior emerges. This is the most common use of the archetype.

Archetypes are effective tools for beginning to answer the question, “Why do we keep seeing the same problems recur over time?”

Prospectively, archetypes are useful for planning. As managers formulate the means by which they expect to accomplish their organizational ends, the archetypes can be applied to test whether policies and structures under consideration may be altering the organizational structure in such manner as to produce the archetypal behavior. If managers find this to be the case, they can take remedial action before the changes are adopted and embedded in the organization’s structure. 

From my experience, archetypes can be highly effective when examining PMO and IT Project Office organizational structure.

The particular “systems archetype” described above is called “accidental adversaries” because it explains how groups of people who ought to be in partnership with each other, and who want to be in partnership with each other (or at least state that they do), end up bitterly opposed.  It applies to teams working across functions, to joint ventures between organizations, to union-management battles, to suppliers and manufacturers, to family disputes, and even to civil wars.

The classic case where this “accidental adversaries” structure was first articulated and  recognized was a scenario involving Procter and Gamble (P&G) and Walmart.  Both had the same goals–improving the effectiveness and profitability of their production/distribution system–but they each felt that the other was acting in self-serving ways that damaged the industry. 

Wal-Mart learned throughout the 1970’s and 1980’s that heavy discounting and price promotion of goods could boost market share, value, and improve profits.  But price promotions created extra costs and difficulties for distributors like P&G.  The Wal-Mart practice undermined P&G manufacturing, creating great swings in P&G’s manufacturing volumes.  The practices of each firm were intended to meet each firm’s internal objectives but, as a partnership, each was always pointing a finger at the other claiming undermining practices.  In responding more attentively to their internal objectives, the partnership fell short of optimizing its combined operational effectiveness.

While this pattern of behavior continued for years, attempts to reconcile and elaborate exactly what was happening was a difficult, if not impossible, order.

And so, this same pattern existed in the newly formed and maturing IT Project Office, among seemingly cooperative and optimization-oriented managers, who did not recognize the future implications of their antagonistic conduct.  It is often not easy to discern or to admit that these behaviors take place among rational and intelligent groups who join their efforts to make a better condition within their groups.

But, as William Braun has suggested, the potential exists for  archetypes to be applied to test whether the policies and structures under consideration may be altering the organizational structure in such manner as to produce the archetypal behavior. If PMO managers find this to be the case, they can take remedial action before the changes are adopted and embedded in the organization’s structure. 

Have you identified some recurring behaviors in relationships between your key PMO suppliers, vendors, partners, or other support groups which can be limiting your attainment of PMO Excellence?  

Here are some prescriptive actions and seven action steps from William Braun in case you find candidates for “Accidental Adversaries”:

Prescriptive Action

• Revisit the original opportunity that brought the PMO parties together into a collaborative relationship.

• Use the archetype to identify the origins of adversarial attitudes.

• Renew the Shared Vision of the collaborative effort and commit to Team Learning.

Seven Action Steps

• Reconstruct the conditions that were the catalyst for collaboration and PMO success.

• Review the original understandings and expected mutual benefits.

• Identify conflicting incentives that may be driving adversarial behavior.

• Map the unintended side effects of each party’s actions.

• Develop overarching PMO goals that align the efforts of the parties.

• Establish metrics to monitor collaborative behavior.

• Establish routine communication.

I don’t want to leave you with the impression that this IT Project Office archetype produced a highly dysfunctional organization as it matured.  Over a two or three year period, the management of the IT Project Office and the consulting firm realized and recognized the internal objectives of the other party, and actually began to discuss how they could support their own internal objectives while creating the fully functional IT Project Office that everyone envisioned at the beginning.   Dialogue and continual realignment of values and vision were effective over time.

Last week on “The Tonight Show with Jay Leno,” Paul Reiser was a guest.

You may remember Paul as the male lead in the sitcom “Mad About You” which starred Helen Hunt as his wife.  The madcap comedy of this twosome kept me in stitches for many evenings.

Paul was appearing on “The Tonight Show” to promote his new sitcom “The Paul Reiser Show.”  However, as luck often has it in the TV business, Paul’s show was canceled after just two shows on air. 

The way he said the TV executives pitched the cancellation to him was “Well, you have some viewers and then you have not so many viewers.  Your show fell in the latter category.”

So he was a “lame duck” in a sense but, since he was already scheduled for Jay Leno’s show, he showed up to provide some laughs and a look a reality in the wacky world of TV sitcoms.

Jay asked Paul about his two sons, who I believe are seven and ten years of age.  Apparently, the last time Paul and Jay spoke, Jay recalled that the two boys had requested a 3-D TV for their home.

Paul explained that one of his sons had exclaimed “Dad, didn’t you see that last jungle picture in 3-D.  The trees were slapping me in the face as the animals swung through the trees.  It was so real.” 

Paul explained that he had always been a 2-D person himself and, in fact, throughout his life, he had tried to avoid being slapped in the face by anything resembling tree limbs as he navigated the world. 

But, of course, the boys were different.  They really enjoyed the idea that they could actually experience being slapped by something unreal and yet so lifelike in appearance.

To all you project managers reading this blog, how do you treat your projects?  Do you go through the motions, treating your projects like 2-D, always hoping that something won’t leap out and slap you in an unexpected manner? 

Or do you approach you projects with a 3-D mentality, relishing the idea that every slap in the face represents a new opportunity to lead?

If you are experienced enough to have managed several projects, you know that 3-D is the only flavor for projects in today’s fast-paced project environment. 

So why avoid being slapped in the face by treating projects as 2-D?  Take a risk and embrace new experiences and new opportunities to lead–you will be glad that you did.

Some project managers reading this blog are engaged in developing software, hardware, and systems applications for corporate or other uses by stakeholders who bank on their technical expertise to provide solutions for cost, scope, quality, and schedule issues.

Other project managers are engaged in designing and building “brick and mortar” facilities.

Still others create value for organizations by providing project deliverables that satisfy requirements for new transactional systems applications that enable the business processes of organizations to realize their full effectiveness.

In general, the project business requirements for project managers working on the types of projects discussed above dictate an in-depth understanding of stakeholder behavior under the most rational of conditions, and those stakeholders usually recognize the importance of a collaborative effort with the project manager in defining the project’s business requirements.

However, there are other types of projects for which the requirements space includes much more than just cost, schedule, scope, and quality; rather, these projects require kindness and empathy in addition to the standard project requirements.

I wanted to learn more about project management in the business context where project managers work directly with customers. John Esposito and his team at ESPO Fire and Water in Tulsa, Oklahoma, were kind enough to let me visit them on-site and find out more about how project management principles are implemented in their workplace. ESPO Fire and Water is engaged in mitigating loss, and in restoring and renovating properties damaged by fire, smoke, wind, water, and other secondary entities such as mold.

The project managers at ESPO Fire and Water deal with home and business owners who have seen their homes and businesses devastated by flood and fire— stakeholders who are often distraught and emotional. Who do I turn to? How do I recover? What is my best alternative? These questions are foremost in the minds of the people immediately affected by a disaster loss.

I wanted to learn how they dealt with the unique customer-service demands of their industry.

I met with Kevin Hefley and Ann Parker, project managers who each have more than twenty years of experience in fire and water damage assessment and cleanup work. They are extremely well versed in the typical project management aspects of scheduling, estimating, planning, budgeting, and quality. Moreover, they keenly understand that, in their business context, building a relationship with their customers is far more important than the transactional aspects.

Kevin told me that project managers from ESPO Fire and Water are often the first representative of ESPO Fire and Water that the customer meets. Sometimes, project managers from ESPO Fire and Water are the first people on-site after the disaster. Given that, at that first visit, a project manager may spend “most of his or her time with the distraught victims, who are trying to grapple with the situation. We know that [we] must play more than one role in these cases so we can quickly calm the victims and assist in their thought processes.”

Kevin told me that one of the many roles that project managers at ESPO Fire and Water must play is that of an advisor to their customers. For example, they must inform and educate customers about any standards—such as ANSI (American National Standards Institute Standards)—that must be met in the remediation. Kevin summarized his customer-centric philosophy this way: “Every morning, before I begin work, I glance at a Chinese proverb on my computer which says ‘Before you ask yourself if you are doing things right, first ask yourself if you are doing the right things.’ This saying has become my philosophy because we are often acting so fast in dealing with multiple projects.”

Ann also commented on the importance of the customer at every step. “There was one job where the customer wanted to know exactly what we planned to accomplish each day on the job and, since that customer was on my way to work, I stopped by each morning to make sure the customer knew exactly what would happen that day.”

Kevin and Ann also told me that they try to import their relationship management skills into other, non-customer oriented aspects of their project management. For example, ESPO Fire and Water relies heavily on contractors and vendors to supply basic electrical and plumbing work. Management of these vendors is facilitated by the fact that most of the vendors have worked with ESPO Fire and Water for a number of years, so they understand the quality of work that is demanded.

I also asked Ann and Kevin whether they used best practices in their project management. They described to me an extremely mature business process which relied heavily on best practices—even including preparing the trucks each night so that they would be ready to roll at a moment’s notice (which is all you get in a disaster situation)! Similarly, the technical director of ESPO Fire and Water is a member of the ANSI standards board. He has a very interactive role to play in both setting new standards, and in interpreting existing standards.

My visit reminded me of process guru Michael Hammer’s classic book Beyond Reengineering. I have applied his thinking to every project management organization that I have been a part of throughout the years. In the book, Hammer discusses the fact that the natural consequence of an organization that focuses on well-defined processes, and on becoming process centered, is the “professionalizing” of the organization’s work.

In this context, he says: “Three words characterize the worldview of a professional: customer, result, and process. The professional sees himself or herself as responsible to the customer; the mission is to solve a problem for the customer, to create the value that the customer requires. If that value is not created, if that problem is not solved, the professional has not done his or her job. It is only by producing the result that the customer requires, by performing the entire process that yields that result, that the professional discharges his or her responsibility.”

Other scholars have added to this definition by insisting that the “professional” is one who is continuously learning on the job and “reflects” on his experiences while sharing lessons learned with others in his practice.

In my experience with the various project management organizations, some met Michael Hammer’s standards, and others were “somewhat less than professional in their approach.”

I was impressed by the high degree of “professionalism” displayed by the project teams at ESPO Fire and Water. I think that other organizations wishing to evaluate and improve their own internal processes could use ESPO Fire and Water as a “benchmark” in that respect.

ESPO Fire and Water project manager Ann Parker told me that “the greatest satisfaction I get from my project work is when a customer calls me six months after a completed job and says ‘thanks for giving me my life back.'”

We don’t always see such a level of empathy in our daily project work; but, with the success that ESPO Fire and Water has demonstrated in all of its project management practices, maybe we should strive for a similar customer-centric outlook.

What level of “professionalism” does your project organization exhibit?

Is your process driven by transaction or relationship?

I look forward to your comments below.

As project managers and PMO practitioners, we continually strive to improve our performance by reflecting on those areas where we excel, and critically reviewing areas where we could create more desirable outcomes when faced with similar circumstances.  

“Dilemmas” are one area of conflict where we can all improve our performance. 

Dilemmas arise from internal or external conflicts between goals, values, perspectives, and points of view.  In this post, let’s examine some elements of the conflicts that give rise to dilemmas for project managers.  As you will see, dilemmas provide learning and growth opportunities for project managers to review and choose a course of action.  John C. Maxwell, who is known as a present day guru of leadership, has often been quoted as saying that “leaders have choices and when they make those choices, the choices in turn make them.”  As leaders, project managers are often faced with those same choices in the form of dilemmas.

Here is a story from my life that may provide a helpful illustration of a dilemma:

During the summer between my freshman and sophomore years in high school, I collected insects.  Not because I had a great interest in insects, but because several rising juniors had informed me that the sophomore biology courses required a leaf collection one term, and an insect collection the next term.  Those students who were unlucky enough to get the insect collection assignment in the winter months often could not find good specimens of the most common insects in our geographical area.  Hence, in order to get good marks in the course, we needed to start a collection as soon as possible so that we could be assured of getting a good representative cross-section of insect types.

I rigged up an insect net by bending a wire coat hanger for a frame and using an old sheer curtain my mother had discarded from a window treatment.  The mesh was sheer enough not to let out any insects but transparent enough that you could clearly see your catch.  So, armed with my handy insect manual and my rigged net, I was the “scourge” of the neighborhood and nearby streams and ponds looking for specimens. 

I was lucky that my family took a driving vacation trip from our home in North Carolina to Florida’s Gulf coast during that summer because I was able to find several varieties of Gulf Fritillary butterflies that were native only to that area.  I thought that would give me a decided advantage with the judges of the insect collections.  Several people had also informed me that bright lights would attract insects during the evening hours, and under a lighted sign I was lucky to snare a rhinoceros beetle on that trip. 

When I returned home, I made the trek early each morning to an all night laundromat about a mile from my home to see what moths and other nocturnal insects might be left over from the night before.  Most of these treks yielded very little except for an occasional small moth like a sphinx moth, which has a bright colored pattern on its wings.  Then, one morning as I walked up to a large screen at one end of the laundromat where the exhaust fans seemed to roar on incessantly.  I stopped in my tracks when I saw something at the corner of the screen which was both large and very colorful.  I had never seen anything like it, and I had poured through that insect manual dreaming of catching something exotic which would really “wow” the judges.

It was a greenish-blue color with a wingspan that must have been at least four inches from side to side, and it had curved tails on its wings which extended back from the body and were symmetrical about the centerline of its body.  It must have been six inches long from top to bottom.  What was it?  So, I pulled out my handy-dandy insect manual and I started to leaf through the pages.  It only took me three or four minutes to realize that I was looking squarely at a “Luna Moth.”

Now, if you have ever seen a Luna Moth, you will know that its beauty and sheer size are the most distinct characteristics.  Why do they call it a Luna Moth?   Naturally, because it is out when the moon is out!

A million thoughts ran through my head.  I did not have much time to think about the consequences of my find.  Any time now the sun would be high enough that the Luna Moth would loosen its grip on the screen and be gone. My first reaction was that this was going to be the greatest insect specimen that the school had ever seen, and I was thrilled to think that I would be applauded as the student who uncovered the specimen. 

But, then a second thought ran through my mind.  What right did I have to capture this beautiful creature and inject it with alcohol to preserve it for my collection?

I had to hurry and decide.  On the one side my mind argued that since I had devoted so much time and effort to this project, I needed to achieve the best possible outcome and to share it with everyone.  On the opposite side, my mind argued that my collection with its smaller moths, butterflies, beetles, dragonflies would do just fine without it. 

Looking back on that moment today, I really did not have the option to take a picture.  Digital cameras didn’t exist.  Back then, pictures were taken when there was a deliberate need to take pictures, and disposable cameras were not available in every drug store.  Spur of the moment yielded no camera readily available for a picture.  The only camera I could hope to put my hands on was a clunky camera my family used on vacation and it was in our house a mile or so away.  So technology was clearly a variable that I was not fully aware of at the time.

I faced a dilemma.  My decision was to capture this insect for my collection.  The Luna Moth was clearly an example of an insect in the insect manual and qualified as a specimen acceptable to the teacher in satisfaction of this assignment. To this day, however, I often rationalize my decision to capture this Luna Moth because I had no idea if the biology teacher would even have accepted a “picture” in place of a real specimen.  From what I heard from those juniors, the assignment was to collect specimens—not take pictures of them.

We are faced with dilemmas in our work and our personal lives every day.  How we resolve them is a very personal matter.  But we should all consider that everyone faces dilemmas, many of which are never revealed to anyone else.

Cordell Parvin, my good friend and colleague, provides training and coaching for lawyers.  When we discussed “dilemmas” one day, he said that, in the legal context, one dilemma he faced was “whether to take a client/case when I knew I would be paid a lot of money but I did not like what the client was trying to accomplish.  Another dilemma is when I have had a client who only wanted a lawyer who would agree with him.  I call it a ‘yes’ man.  In both instances, I resolved the dilemma by not taking the matter or client.  I know that lawyers are supposed to represent clients who are bad people or who have done bad things.  But, for me I could not totally separate my feelings from our concept that even the worst of us is entitled to a lawyer.”

Project managers are no exception—you have probably faced dilemmas on several occasions. 

Have you ever stopped to think about the crucial decision elements and the choices that help you resolve dilemmas?  Consider the following dilemmas which project managers may face:

Scenario One:  An SAP project manager is planning his budget for the next SAP project.  He knows that other SAP projects have typically overrun their budgets because of the need for additional resources and project work in the “data conversion” phase.  He also knows that the PMO is controlling budgets closely for upcoming projects so he is reluctant to include a full amount for any data conversion resources which may cause the budget to seem inflated versus previous SAP budgets.  How is his planning for the project affected by these different perspectives?

Scenario Two:  A project manager who is in charge of a design team to provide a major component for a larger assembly has identified a risk in the use of the component, namely, at lower temperatures than the assembly has been subjected to thus far, and which are not normally encountered by the assembly in its usage pattern, the component may lose its elasticity and become more rigid, thus potentially compromising the performance of the assembly.  He knows that the next proposed application for this assembly will likely be in that lower temperature range.  He has alerted the Design Manager, but the Design Manager refuses to inform the contractor of the potential flaw.  His rationale is that every assembly to that point in time has performed flawlessly and there is no need to think that the major contractor would desire a redesign if the risk of a failure were very low.  He asks the project manager to confirm his analysis regarding the identified risk.  Does the project manager confirm that low risk or continue to raise a red flag about a potential failure?

When facing project dilemmas such as the above sample scenarios, what are some key conflict and decision elements which project managers should consider? 

1.  Timing

In the case of the Luna Moth, since I had a limited time in which I could capture the moth, “timing” was of the essence in forcing a resolution to the dilemma.

2.  Goal or Outcome

Often, conflicting goals are an issue.  There may be, for example, conflicts between personal goals and organizational goals, between the goals of two individuals, and between internal personal goals and externally defined peer group goals.  The experience of the individual project manager frames the project manager’s determination as to what are possible choices.  For example, in the case of the Luna Moth, having only the input from former students, I believed that the only way to fulfill the assignment was to actually collect (rather than photograph) the insects. 

3.  Perspective or Frame

We have often stated in this blog that people act in accordance with the truth as they perceive it to be.  Right versus wrong is often based on the truth that an individual defines for himself in the world.  Choices are then defined by those “truths.”

4.  Technology

In the case of the Luna Moth story, did I really at that time believe there was a technology choice to be made between taking a picture and harvesting the specimen?  Or, did I inject that into my story I told myself many years later as I recalled the incident based on my years of experience in facing other dilemmas and choices that had a variety of technologies available for deployment?

5.  Interpretation of the Facts

Two individuals experiencing the same scenario may view the events and actions of the participants in entirely different ways based on their experiences, value systems, and what they consider the “truth.” 

6.  Reality or Wishful Thinking

When reflecting on past events or experiences, we often inject our own stories into the scenarios because we are continually telling ourselves stories based on our observations, biases, values, and what we each consider reality.

Dilemmas provide us with a playground for testing our viewpoints versus others’ viewpoints. 

Roger Martin, Dean of The Rotman School of Management at The University of Toronto, has written a great deal on the topic of “Integrative Thinking.”  Integrative Thinking is a framework for evaluating conflict in scenarios.  I encourage project managers, when faced with new dilemmas, to look upon them as opportunities to grow and develop their own “integrative thinking” framework.  Think of some dilemmas you have faced in projects and share your experiences with others who have faced similar dilemmas.  You will be surprised by how many different viewpoints and interpretations will surface when you discuss your past dilemmas with others.

As I have alluded to before, John C. Maxwell has outlined the impact that “choices” make on leadership development.  The choices that project managers make in the course of their projects, in turn, make them.  Choices like responsibility, accountability, integrity, compassion, and values-based decision making can impact not only other project managers and PMO practitioners around them, but also other individuals in the organization, the organization itself, and those with whom the organization interacts.

Thank you for your attention.

Recently, I collaborated with Wayne Thompson, author and host of the very popular blog “Project Management War Stories,” to develop a podcast covering one of the topics that I have frequently written about in this blog–Project Lessons Learned. 

Part One is now ready for your listening. Part Two is also ready on the same site. 

As I alluded to in my last blog post, I believe that more companies are seeking to close out projects in a more documented manner and they are using a Project Lessons Learned Framework to do so.

Those of you who have followed my PMO Blog for some time know that I am very interested in Project Lessons Learned and their impact on future project team behavior and success.  

Among the themes that I have developed are:

1.  Why it is desirable to conduct Project Lessons Learned reviews at specific intervals in the project such as Phase Gates rather than waiting until the Project Close Process?

2.  What is the actual cost to the PMO for not developing and sharing Project Lessons Learned?

3.  How PMOs can make Project Lessons Learned a Best Practice in their organizational and business context.

In 2011, I predict that we will see PMOs focusing on Project Lessons Learned as a primary focus, rather than a secondary focus (as has been the case in the recent past).  More organizations are seeking to close out projects in a more formal and documented manner, and Project Lessons Learned is an excellent framework to follow. 

Here are some other items I see that contribute to this trend:

1.  The need to include Risk Management in every aspect of Project Planning and Execution.  Risk can be included as a variable in the Project Lessons Learned framework, especially if applied in a Project Lessons Learned schedule that calls for a review at the Phase Gates at the end of each project process.

2.  Project Lessons Learned will eventually be captured and stored in new systems such as the Microsoft Project 2010 client and server, so that the information can be treated as just another piece of performance reporting information for a project.

I recently collaborated with Wayne Thompson, host of the very popular blog “Project Management War Stories,” to develop a two-part podcast on Project Lessons Learned.  I will post the first part of the podcast in late February, and the second part in early March.

I would be interested in some comments from those of you actively working with Project Lessons Learned in PMOs.  Please contribute, and I will continue to monitor and assess the increase in usage of Project Lessons Learned.

In a recent blog post, I discussed using “Design Thinking” principles to define complete business requirements for projects. 

Audience response to this post was extremely positive, so I recently collaborated with Wayne Thompson, the author of the very popular blog “Project Management War Stories” to develop a two-part podcast on his blog site about the “Design Thinking” topic.

Part One of the podcast covers background material on why project teams often fail to define complete business requirements for projects and are forced to rework and redo much of their planning. 

Part Two of the podcast covers the use of “Design Thinking” and other innovation principles to better define project business requirements. 

I hope all PMO practitioners, project managers, and project team members find these podcasts interesting and enlightening.  I have certainly enjoyed working with Wayne Thompson on these topics, and we are planning a new podcast for later this month on Project Lessons Learned.  Stay tuned for that next podcast and thanks for your support.

Project managers who fully experience the project process learn and acquire truth, knowledge, decision-making skills, and good judgment.  There are three primary methods by which project managers may learn these lessons:

First, “reflecting” is the preferred method because it results in the highest value to the project manager.  “Reflection” means focusing attention on or studying an event or outcome to understand its origin and root causes as they apply to new project situations.

Second, “imitating” other project managers’ documented, shared experiences is the easiest method by which project managers may improve their skills.  “Imitation” means to behave in a manner which mirrors the actions or behavior of others.

Third, “repeating” his or her own bad experiences and unplanned or poor outcomes may also result in the project manager developing his or her skills, although this method causes the most pain and, in most cases, creates the least value addition.

These concepts paraphrase Confucius’ fifth-century B.C. quote concerning “wisdom” and “lessons learned”, which many of you will recognize from previous posts on this site.  They relate concepts of “behavior,” “actions,” “outcomes,” “experiences,” “pain,” “ease,” “value addition” and “knowledge.” 

Why is it that project managers refuse to accept the reality that it is more painful to keep repeating the same mistakes in their projects, rather than learn and benefit from the experiences of others? 

Lou Tice teaches us two principles of personal growth and development:

1.  People act in accordance with the “truth” as they perceive it to be.

2.  People move toward and become like that which they think about.

As Lou Tice suggested, project managers who act as if project lessons learned can have no positive impact on their future success, act in accordance with their perceived “truth” that project lessons learned aren’t valuable.  Similarly, many organizations have been reluctant to require their project managers to take the time required to reflect upon their completed projects and document their project lessons learned, despite the fact that most PMBOK practices suggest that project managers properly close-out projects with an after-action review and documentation of project lessons learned. 

Today, however, I believe that this reality is beginning to change.  Many companies have begun to take project lessons learned more seriously, and are interested in closing-out projects with documentation preserving the “knowledge” created by the project, and the “experiences” of project participants.

On the other hand, what do project managers want to do more than anything else when they successfully complete a project?  Those of us who have observed this behavior over time can tell you that overwhelmingly project managers want to get on to that next great assignment, that next great challenge, that next great project.  Rarely do they want to pause and reflect upon what they have just accomplished, or what the organization could gain if they documented and shared their project management experiences. 

So, what should be the driving force for properly documenting and sharing project lessons learned?

We all know that most organizations now recognize that there are certain Best Practices—in both their project management processes and their business context—which they employ over and over again.  This is to be expected; when an organization experiences a successful outcome using a key Best Practice, the organization is likely to have a successful outcomes in the future if it employs that same Best Practice again.  Often these Best Practices are specific to that organization’s culture, and they fit into the project process naturally in the course of executing projects.  Indeed, many organizations are employing Best Practices now intuitively.  Few companies, however, are adept at recognizing and employing their own Best Practices.     

Just like Best Practices have become—no pun intended—Best Practices within many companies, shouldn’t PMOs look upon Project Lessons Learned as having the same potential to lead to “success” in their project work? 

Here is a “process” and “framework” for looking at Project Lessons Learned that will allow the project lessons learned process to become a Best Practice in your PMO: 

In my last blog, I talked about building capabilities as a prerequisite for successful PMO execution. 

What would constitute a “capability based system” for capturing and sharing project lessons learned?

1.  There must be some process or mechanism for sorting out the FACTS in stories, experiences, and anecdotes versus the ASSUMPTIONS.

2.  There must be a recognized “review” process to identify candidates for project lessons learned. 

3. There must be a willingness on the part of project managers and project team members to speak directly, concisely, and with conviction about project events and lessons.  This involves a risk-taking attitude that only comes from developing an internal capability in the organization to acknowledge that project lessons learned add lasting value.

4.  There must be a “review” process which addresses the following questions:

        –What were the Expected Results from the action or behavior of the project team?

        –What were the Actual Results from the action or behavior of the project team?

         –What is the gap between Actual and Expected?

         –What are the Lessons Learned to be captured, shared, and documented?

5.  There must be an internal knowledge-management system devoted to storing project lessons learned documentation so that project managers may easily retrieve and apply the lessons contained therein to new projects.

6.  There must be a single person who is the coordinator or caretaker of the project lessons learned process and knowledge-management system, so that he or she can analyze the documented lessons learned in order to identify any broader lessons learned which may be applied to the policies, processes, and procedures governing the organization’s project management processes.

Once you have mastered these basic elements and gain some experience in applying the process to a number of projects, you can begin to add some sensitivities.  For example, you can relate project lessons learned to the risk of developing a new technology concurrent with the project within which the new technology is being applied.  At the outset of the project, you can establish a plan to prove-out the technology as the project progresses.  A lesson learned can then be documented in terms of the risk of the new technology being proved-out successfully during the project.  Such a scheme could introduce concepts such as “controllable” and “uncontrollable” risk.  “Controllable risk” could be associated with those portions of the technology prove-out where there is a high probability of success.

Likewise, you can look at project lessons learned at the end of each major phase of your project and apply some “integrative thinking” principles, as I have outlined in another blog post.  This allows a reexamination of original “assumptions” for the project and sets the tone for good project planning for future project phases.

Where does your PMO stand on closing out projects?

It has been difficult to pick up any literature on business strategy and business growth recently without seeing the word “innovation” splattered all over the headlines and content.  “Innovation” is such a catchy word these days because the idea inspires people; it connotes taking the innovator to a new height of success.  Likewise, there are some companies whose names seem to “drip” with the word “innovation” whenever you encounter the company’s name:  DuPont, Procter & Gamble, and Apple,  for instance.

A.G. Lafley, in his book, The Game Changer:  How You Can Drive Revenue and Profit Growth with Innovation, defines innovation as “the process of converting or turning new ideas into revenue and profit.”  Similarly, many authors in the PMO field have defined the PMO as a distinct organizational structure which can be used to drive innovation through project management and product development.

A recent article in the Winter 2010 issue of Strategy + Business magazine, entitled “The Global Innovation 1000:  How the Top Innovator’s Keep Winning”, was based on an ongoing Booz & Co. study of innovation in the most successful companies in the innovation game today.  The goal of the study was “to examine the capabilities needed to maximize the impact of the company’s innovation efforts in good times and bad, and to highlight the benefits both of focusing on the short list of capabilities that generate differential advantage and of clearly linking the specific decisions within innovations to the company’s overall capabilities system and strategy.”

Their premise was that “innovation capabilities enable companies to perform specific functions at all the stages of the R&D value chain–ideation, project selection, product development and commercialization.”  The consultants asked the respondents in the Global Innovation 1000 survey which capabilities were most important in achieving and sustaining success in innovation.

Surprisingly, the study found that “all the successful companies surveyed depended on a common set of critical innovation capabilities.  These include the ability to gain insight into customer needs and to understand the potential relevance of emerging technologies at the ideation stage, to engage actively with customers to prove the validity of concepts during product development, and to work with pilot users to roll out products carefully during commercialization.”  The study’s authors also found important the ongoing assessment of market potential during the project selection phase.

Exhibit 1--The Most Important Innovation Capabilities

You will recall that in other blog posts, I have discussed the rise of PMOs for specific purposes in organizations which recognize the special value-added by having an organization focused on project management capabilities as a means of converting strategy into action.  For example, some utilities have formed Smart Grid PMOs to handle Smart Grid projects.  In an organization that is determined to succeed and grow in its industry, with best-in-class products, services, or both, why not consider creating an entity called the Innovation PMO?  What would the characteristics of such an entity be?

First, since feedback and research from consumers, users, and other stakeholders is critical to understanding “what to innovate for,” the Innovation PMO would establish its own unique source of feedback research within the context of its own industry or consumer setting.  This is a key element of success.  Unfortunately, very few PMOs are currently doing a good job in this area, but to become an Innovation PMO, they must.

Second, the Innovation PMO has leveraged its key supplier and vendor relationships.  It knows that frequently, the unsolicited feedback provided by suppliers and vendors provides a fresh look as to where the market is headed, especially in innovation scenarios.

Third, the Innovation PMO has tailored the critical innovation capabilities discussed in the Booz & Co. study to the internal business context of the organization.  This tailoring process is analogous to the benchmarking process, discussed in a previous blog post, which is used by leading PMO organizations, such as American Express and Procter & Gamble, to establish best practices.  Like best practices, to be successful, innovation capabilities can’t be lifted verbatim without being tailored to the organization’s business context.

Margo Visitacion of Forrester has also written about the expansion of the PMO concept to innovation in organizations in her recent Forrester paper “Involve Your PMO to Find the Right Match for Innovation Opportunities.”  I would recommend you read her analysis as well.

Innovation is certain to be a topic embraced by more and more organizations looking for successful growth-promoting projects in their industries.  Your role as a PMO practitioner is to find a spot where you can contribute to that success.  Remember–“Change Creates Opportunity.”  Now, go find that opportunity.

“Pay Me Now or Pay Me Later”

Sounds like a hit song or a cry that something may have gone wrong with the relationship at hand.  Turns out that “Pay Me Now or Pay Me Later” describes a number of consequences of project scenarios with which we all are familiar.  It was an expression I coined one time in response to a PMO Manager with whom I worked who wanted to proceed with a contract for services without adequately reviewing the risks in employing that vendor or the services requested.  “Expediency” was the name of the game.  Forget the requirements, just deliver the solution.  Sound familiar?

In this particular scenario, I used a “timeline” to lay out for that Manager the consequences for two scenarios–one in which the vendor did not deliver because the requirements were ill-defined and one in which we took time to evaluate and define the requirements carefully to “frame” the problem adequately.  Of course, this story would not be worth telling if the timeline for the redo and rework ended before the timeline for the complete requirements development.

The Manager signed the contract anyway despite my “drawings.”  And, sure enough, I refrained from saying “I told you so.”

If you survey project teams, project managers and key project stakeholders throughout the various industries that heavily employ project management as a discipline to add value to their respective organizations or to translate strategy into action, you will find that one of the principal problems encountered is the complete definition of project business requirements.  I have alluded to this problem in other blog posts, and in particular in the blog post on “Reframing” the project requirements to provide a more complete and accurate assessment of what problem is being addressed by the project.   Good business requirements are the key to a successful and compelling business case which, in most PMOs, is the basis for approval, rejection or deferral of a project. 

Among the many remedies for the lack of adequate business requirements definition which are found in project literature is the use of very disciplined approaches for defining business requirements by use of templates, coordinated facilitation of group meetings and very detailed descriptions of the “as is” and “to be” project environments.

Every year there is an enormous amount of rework, redo, and replanning of projects due to incomplete and inaccurate definition of business requirements by project teams.   What are some of the shortcomings of business requirement development that most project managers and PMO practitioners will recognize?

1.  Use of a “Once Through” Approach:  The “once and done” syndrome is rampant in business requirement development because of the desire to get on to the “execution” phase which is most often deemed by project teams as the most important phase.  Very little “iterative” approach and retesting of business requirements (and original project ASSUMPTIONS) takes place in actual project work.

2.  Abdication of Business Requirement Development by the Group most affected by the Project:  Usually a business-driven project will have functional and business representatives and stakeholders work with the IT group to develop business requirements.  In many cases, I have seen the business/functional group abdicate its position in the “dialogue” in favor of IT or another lead group taking over the entire process.  This has the effect of the development of business requirements from only one single point of view or perspective and leads to “interpretations ” and “judgments” which, if not tested appropriately, will result in poorly defined business requirements.

3.  Narrowly defined interface requirements between people/functional, functional/technology, and people/technology interfaces:  This results in technical feasibility and market viability often being ignored and the people/functional interface being treated with simplistic ideas for solutions.

4.  Requirements that are not truly “empathic” in their derivation:  Often the stakeholders’ real requirements are not surfaced in the “dialogue” because a singular perspective is applied by the IT group facilitating the dialogue with the business/functional group.  A real visceral understanding of the emotional, social, cognitive, and physical needs of the stakeholder are not defined.   “Empathy” requires looking at things from the users or stakeholders point of view without interpretation on the part of the dialogue facilitator about what the stakeholder or user really “wants.”

5.  Poor “dialogue sessions” between requirements gathering group and the stakeholders or sponsors of the project resulting in rework and redo to create a business case that truly reflects the business requirements being targeted.  I have written about this in another blog post about what to do if your PMO does not execute as expected.

You can certainly extend or expand this list from your own project experiences and I encourage you to write down your observations and test them with others in your project community who are subject to the same project environment.   You will be surprised at the recurring themes, many of which occur because of the similar approaches in building business requirements that are defined within the “structure” of your PMO organization and culture.

You may recognize that one reason for the rise in interest in other methodologies such as AGILE and JAD is specifically because these methodologies address some of the shortcomings in the previous ways in which business requirements were developed.  Utilizing iterative techniques, incorporating more than one point of view and prototyping have been accepted as very applicable to many project situations.

I would like to propose that we take a new approach to project business requirements definition based on principles of “design thinking.”  Design Thinking is an approach to innovation.  In fact, it has often been called “human centered innovation” because of the focus on physical, emotional, social and cognitive needs of the stakeholder or client.  Design thinking has been used successfully by consumer and industrial products companies as well as service providers to open up new markets, define new products, identify new partnerships and to solidify relationship management for parties involved.   Design thinking starts with “empathy” which means looking at things from the viewpoint of the stakeholder, user or sponsor.

Tim Brown, the CEO of IDEO, has written extensively about “Design Thinking” and his reference book on the subject is Change by Design.  And A.G. Lafley and Ram Charan have written about “design thinking” and its associated facilitating framework known as “integrative thinking” in their book Game Changer:  How You Can Drive Revenue and Profit Growth with Innovation.

In a WSJ article early in 2010, Estee Lauder CEO Fabrizio Freda, formerly an executive with Procter & Gamble and a leading advocate of “design thinking” in product development at P&G, said “We don’t want to just do the products that consumers want.  We want to be inspired by consumer desires and surprise them with products that they don’t expect.”  That takes a deep understanding of the cognitive, social, physical and emotional needs of the clients, consumers and customers.  But it also applies to project business requirements development.

Here are some specific actionable things you can do from a “design thinking” perspective to enhance your business requirements definition:

1.  Listen.  Employ “empathic communication” to understand the viewpoints of the stakeholders, users and sponsors.  Listen to the “stories” and “anecdotes” that your stakeholders tell each other.  Often they will reveal their anxieties, worries and fears along with other needs that are never mentioned in their straightforward conversations.  Engage them in “storytelling.”  Recall the account of the SAP project manager from one of my blogs who spoke to everyone who would potentially be affected by the changes introduced by his SAP program.  His method of “empathic communication” elicited many business requirements and business opportunities of a very detailed nature.  It also built “commitment” from the ground up for the program scope, issues and approach which the project manager wanted to pursue.

2.  Look for analogous situations or scenarios to develop deeper insights into the needs of the customers.  Tim Brown, CEO of IDEO, one of the pioneering companies in “design thinking” techniques often talks about some work they did in redesigning the processes for a hospital emergency room.  They talked to so many ER “experts” about what could be done that they decided to seek an analogous situation.  So they studied NASCAR pit crews.  Notice the similarities:  high pressure, high competency requirements, ability to work as a team and as individuals in  a time constrained , close quarters environment.  Often sharing the analogous scenario with your stakeholders can stir their innovative and creative instincts.  I mentioned in a previous post the analogy between project manager and movie director.  Look at the similarities between developing movie script, background, character and actor development and managing a project’s requirements.

3.  Prototype the business requirements situation as best you can.  This will provide additional insights into “real needs.”

4.  Expand your questioning of stakeholders to other than just “superusers” of the systems or new processes.  Tim Brown often tells the story of redesigning cooking utensils for the kitchen.  After continually using experienced cooks for requirements gathering, they brought in a group of children and asked them to put the utensils through their paces in some cooking classes.  The dexterity and handling requirements were immediately accentuated because the children had very few preconceived ideas about how the utensils were to be used.

5.  Read or view some background information on “design thinking” and “integrative thinking.”  Lectures by Time Brown of IDEO can be easily found on the internet.  Also, some business school curricula are now embracing “design thinking” as a basic tool for business strategy and requirements gathering.  See the work of Heather Fraser at DesignWorks which is the model school for design thinking at The Rotman School of Management at The University of Toronto.  Dean Roger Martin’s work on “integrative thinking” can be found in his book The Opposable Mind.

This is just the starting point for opening up a whole new panorama of requirements gathering techniques and validation.  Design Thinkers use the whole world experience in their designs.  Project managers should do the same.

Now, “Pay Me Now or Pay Me Later” should take on a whole new significance to you.  Give me some feedback about your most useful “design thinking” techniques and how you employed them.

Copy Protected by Tech Tips's CopyProtect Wordpress Blogs.