http://www.gantthead.com/workshops/regions.cfm?region=North%20America

Please join me for a one day workshop.  We will be coverinng the Project Lessons Learned Framework I have discussed in my blog.  Thanks for your interest.

In the course of this review of critical success competencies, we must also ask what skills and capabilities are required of project managers or project facilitators to enable the full development of project lessons learned? 

As we all know, people are what really make a difference in the deployment of corporate resources.  To make a real difference, and to stand out versus other organizations’ implementations of the project lessons learned process, your organization needs to ask what skills and capabilities it must develop and nurture in its project managers to fully realize the benefits of Project Closeout and Lessons Learned.

It is the combination of Process, People, Tools, and Capabilities that really make a successful package for Project Closeout and Lessons Learned.

So, what skills do your project managers need to develop to enable the full development of project lessons learned?

First, the project manager must be a good “facilitator” of the Perspectives, Facts, and Deliverables that are key to defining Significant Events for Lessons Learned.  The project manager or coordinator must be able to work with different Perspectives as to what actually happened in key project situations, sort through the various Perspectives, and then “reconcile” if necessary those Perspectives that would hinder gaining consensus on key Significant Events.

Second, the project manager or coordinator must be a good “reframer” if necessary to hold the dialogue with key project participants who might see situations differently but, in actuality, just need a “reframing” of the facts of the situation to be brought on board.

Third, the project manager or coordinator needs to be a leader of the discussion, at all levels, during which it is important to convert Significant Events, to Candidates for Lessons Learned, and finally, to the identification of Lessons Learned themselves.

Fourth, the project manager or coordinator needs to be a good documenter of the process using the Lessons Learned Template as a key documentation tool.

Fifth, the project manager or coordinator needs to be able to explain, and put into context, why certain lessons learned led to improvements in process, and how those improvements were actually realized.

In my experience, even the most experienced project managers have trouble working with the Framework at first and must develop some experience with using it effectively.  In most cases, it is these capabilities or competency areas that are being developed while the project manager or coordinator grapples with the details of Project Closeout and Lessons Learned.

I have also found in my work with PMOs that oral presentations of Lessons Learned by project managers to their peer group is a very effective way of building these capabilities, and also to build project leadership.  In a major PMO with which I worked, those project managers who consistently stepped forward and volunteered to lead this discussion of project lessons learned eventually became the leaders of the PMO.  Why was that?  Project managers who embrace change, who believe that Risk Management is a friend, and who want to be “curators” of the project knowledge in their own project communities are often the very ones who step forward and lead in the Project Closeout and Lessons Learned arena, as well as in their own PMO development and maturity.

So, please keep in mind that it is not enough to espouse good Project Lessons Learned documentation.  You must first look to how your organization is nurturing those Process, People, Capabilities, and Tools for Project Closeout and Lessons Learned.  You can start this journey in your own organization by volunteering to speak to other project managers about your own project experiences and by beginning to examine Facts, Perspectives, and Deliverables for your recent projects in anticipation of capturing Lessons Learned.  Integrate this zeal with a good Project Risk Management Plan and see how it contributes to the success of your PMO or project organization in upgrading the entire project process.

Many project organizations already incorporate Risk Management as a capability in their planning and execution of projects, but many others have not reached the stage where they really appreciate how a Risk Management Plan can contribute to project control, outcomes, and success.

Although it is not necessary to have a Risk Management Plan to apply the Project Lessons Learned Framework I have developed, the real power in having a Risk Management Plan lies in the fact that “Significant Events” that may become “Candidates” for Lessons Learned may already have been identified in Risk Mitigation Planning and Risks Triggered during a project.  That makes it easier to collect as many real Significant Events as necessary to complete a Project Lessons Learned exercise.

Risk Management is, of course, an attempt to anticipate actions and events in a project for which the organization has not formally planned, but which could impact the project. 

Risk Management is also a way to address a project’s “assumptions” that might previously have been considered to be unchanging during the course of the project.  We all know from experience in managing projects, however, that initial “assumptions” almost never stay the same during projects.  So, Risk Management is a technique for planning and taking action for assumptions that change during a project.

Risk Management is an exercise in which you identify possible events that might lead to adverse consequences for a project.  Mature project organizations or PMOs that embrace Risk Management techniques are also more likely to embrace “change” which, as we have observed in other blog posts, correlates highly with embracing Project Lessons Learned.

Risk Management also usually involves some discussion of how risks could introduce gaps in expected-versus-actual results for a project. 

Project organizations that do not formally have a Risk Management Plan in place for individual projects should, of course, still pursue Project Lessons Learned exercises at the close of their projects.  As the organizations gain more experience in capturing, documenting, and sharing lessons learned, they will also become more aware of systemic risks in their business or project context which, in turn, should make it easier to introduce a Risk Management Framework that addresses the portfolio of projects and individual projects as well.

Ask yourself whether your organization fully utilizes its Risk Management Plans and Frameworks in assisting in Project Lessons Learned exercises.  You can play a leadership role in introducing the link between Risk Management and Lessons Learned.

Thanks for your attention.

Today, I am going to discuss the second aspect with you–Perspectives.

The end objective of a Project Closeout and Lessons Learned exercise is to determine “actionable” changes that can be made to basic processes in order to improve performance of projects and the organization in total.  “Actionable” changes need to be agreed to by the organization’s participants so they are committed to the changes, and work to sustain the changes over time.  And someone in the organization needs to be assigned the role to make the process changes, so that the actionable lessons learned fit easily into a “continuous improvement framework” for the organization.

To provide better understanding of “perspectives,” let’s give a definition and an example.

Perspectives are different viewpoints which people may feel or express about a situation or an action or an event which represents their interpretation about the “truth” of the situation as they perceive it.  An example would be the following exchange recently between David Gregory, moderator of the NBC News Program “Meet the Press” and a Republican Candidate for the Presidency. 

Mr. Gregory:  “Mr. Candidate, isn’t it true that none of your colleagues in the Congress have not endorsed your Candidacy for the Presidency?”

Candidate:  “The truth, Mr. Gregory, is that I have not asked any of my colleagues from the Congress to endorse me yet.  I will at the appropriate time.”

You see from this exchange that each person expressed a viewpoint about the same situation or potential action or event that represented their own interpretation of what was “true” for them in their business, social or political context.

Sometimes perspectives are reconcilable and sometimes they are not.  Two parties may continue to disagree about the “truth” of a given situation.  In this case, they cannot agree whether it was a Significant Event or how significant the event was to the overall outcome of their work.  Reconcilable perspectives are important in agreeing upon what really happened in a given situation.

Because project participants bring many different viewpoints to projects as to what was significant, and as to what really took place in the project, each of the project participants possess what I term “perspectives.” 

Perspectives are viewpoints that capture the truth as perceived by the viewer.  However, as we have alluded to many times, people act in accordance with the “truth” as they individually perceive it to be.  Project participants often “perceive” different outcomes and actions in projects and disagree about what really took place.  That is why I advocate starting with FACTS, the statements and data that no one can refute.

Timing is also very important for gathering and processing “perspectives.”  The closer to the project lessons learned exercise the perspectives were documented, the more they will reflect what truly happened in the project.  If we allow much time to pass from project close to the capturing of lessons learned, the perspectives will often be colored by other experiences that the project participants have been involved with after completion of the project.

A principle of Lou Tice’s is that “[p]eople act in accordance with the TRUTH as they perceive it to be.”  Their definition of a project’s Significant Event may be different from yours if they see a different TRUTH in the actions or outcomes of the project.  Reconciling different perspectives, and gaining agreement about the TRUTHS of a project, are often critical to gathering Significant Events and then qualifying them as Candidates for Project Lessons Learned. 

Project Managers and other project team facilitators must be adept at sorting out the feelings that project participants, sponsors, steering committee members, and subject matter experts express about TRUTHS and OUTCOMES in a project.

Even very experienced project managers often find it difficult to sort out and deal with the various “Perspectives” that project participants bring to the table to discuss as part of a Project Lessons Learned exercise.  Practice in identifying Project Lessons Learned, and in sharing with others, is a major step toward building an internal organizational capability to develop “actionable” Project Lessons Learned that can contribute to a “Continuous Process Improvement” Framework for a project team or organization.

Another aspect of reconciling perspectives that I have written about extensively in this blog is “reframing.”  Project managers and facilitators must be adept at “reframing” positions to bring out the relevant facts and viewpoints that make sense in identifying Significant Events for Project Lessons Learned.

I encourage anyone truly interested in becoming a “curator” for their project environment, in terms of capturing, documenting, sharing, and perpetuating project lessons learned, to practice the flow from “Significant Events” to “Candidates” to full “Lessons Learned” by actively involving themselves in the reconciliation of “Perspectives” in Lessons Learned exercises.

You will be happy that you took the time for focus on identifying and reconciling “Perspectives” because it will provide you with new insights into interpreting events, actions, and feelings on the part of project participants.  It will also help you record those TRUTHS about projects that can lead to more in-depth insights into project performance and ongoing project success.

Challenge yourself in the next Project Lessons Learned exercise that you conduct or facilitate for a project team to recognize and appreciate the different PERSPECTIVES and their contributions to fully understanding your project environment and context.

The Single Project Case involves a project manager and his team who wish to identify, document, and share project lessons learned at the completion of a project, usually during the project close process. 

The Multiple Project Case is the case in which several projects are subject to the same “project environment” and, therefore, may exhibit patterns of behavior that are the result of the structure of the project environment.  The “structure” of the project environment is the policies, procedures, standards, and working processes that the project organization establishes to govern the way that the project will be conducted.

As we have discussed previously, the real leverage in looking at patterns of behavior from several projects that are subject to the same project environment is that a single change to the structure could potentially improve the performance of all the projects in the environment.  This is because the structure has dictated some behavior or action on the part of project teams of others associated with the project that have contributed to suboptimized performance.

The purpose of this blog post is to provide a simple “analogy” to further explain the power and leverage associated with looking at patterns of behavior among projects, and tracing these patterns to some action or process in the project environment that contributed to those patterns. 

The simple analogy is the story of a breakfast buffet at a hotel.  From six AM to nine AM each morning, the hotel offers a breakfast buffet to its guests consisting of the usual breakfast foods:  eggs, sausage, oatmeal, coffee, orange juice, muffins, bagels, cereal, etc.  Guests usually serve themselves from a buffet and then sit in a lobby designed with tables for use by the guests during breakfasts and other meeting occasions.  Guests usually serve themselves and then clean up at the end, which assists the breakfast staff in maintaining a continuous flow of breakfast guests.

On one particular morning, as each table completed its breakfast and vacated the area, a member of the breakfast staff wiped the table clean with a damp cloth in preparation for the next guests.  Several breakfast staff noted that there was a sticky substance on each of the tables that resisted the usual wiping with a damp cloth, so that additional cleaning was required.  The incident continued throughout the morning. 

At about 8:50 AM, the manager, who had been informed by the breakfast staff of the sticky substance, observed several guests as they ate and completed their breakfasts.  He approached several tables, and asked if the breakfast staff could examine the tables while the cups, plates, and utensils were still on the table.  It was found that the sticky substance had been deposited on the table by the plastic orange juice cups. 

 A “pattern of behavior” had been identified.  A sticky substance had been identified with each table where an orange juice cup had been place by a guest.  The sticky substance appeared to be the same in each case.

The manager and several breakfast staff proceeded to the orange juice dispenser and observed the following process.  Guests would pick up a juice cup from a stack of empty juice cups and place the cup on a specific spot in the juice dispenser.  The guest would then push a button to dispense the juice into the juice cup.

The manager and the breakfast staff examined the single spot where each empty juice cup was placed by guests.  On that spot there was a sticky substance.

A process that had been put in place to facilitate ease of juice dispensing had caused a bad outcome at the customer environment location.  The process supported the overall structure of breakfast for guests during the time period six to nine AM. 

If the breakfast staff had not acted to identify the incident and its resulting pattern of behavior, the impact on customer satisfaction might have been negative.  At the very least, it might have contributed to the sticky substance being spread to other equipment and guest utensils.

Because the breakfast staff and the manager reacted quickly, however, the sticky substance was removed from the orange juice dispenser.

This analogy is far from being too simple.  It points out that “patterns of behavior” are so important in a project or customer environment that project groups should be attentive to them and act with haste to correct them.

Many such patterns of behavior occur in project environments every day.  Do you take the time to think through incidents and events in your own project environment which can be “patterns of behavior?”

The quick action of the breakfast staff and the manager in identifying the patterns of behavior were a significant step in making the improvement to the process which kept the structure working as planned.

In your own project environment, look for “patterns of behavior” and the underlying root causes for their occurrence.  The leverage you can apply in your business context is enormous.

And the next time you drink a cup of orange juice, think of this example.  You will be glad you did.

Our podcast on this topic is available here (Podcast No. 229).

I have worked in this field for many years, during which time I worked with several major project organizations.  I feel that now is the time for increased emphasis on Lessons Learned. 

Early in 2011, I predicted that more companies would seek to close projects successfully and to capture project lessons learned.  In fact, I stated that those companies who successfully documented and shared lessons learned would gain a decided competitive advantage with regard to competition.

Today, I see a trend toward being more open in organizations with regard to “project failures” and poor performance of projects.  However, it is still a “culture” phenomenon, and much work must still be done with organizations to help them gain an appreciation for the full value of lessons learned.

Our BOT International work has shown that how project and PMO organizations embrace “change” is very much related to how they embrace lessons learned.  The discipline of lessons learned is all about change. 

To quote John C. Maxwell:  “Real change occurs as the result of either inspiration or desperation.” 

Project and PMO organizations that are “business driven” and proactive take a decidedly different approach to that of project and PMO organizations that are on the “compliant” end of the spectrum.  This difference between “commitment” and “compliance” when addressing change is important.

Our BOT International consulting offerings in the Project Closeout and Lessons Learned Advisory Practice take these CHANGE, CULTURE, and PMO MATURITY issues into account in their planning and execution.

All of our consulting offerings approach project lessons learned from a Framework which contributes to a continuous process improvement environment for the organization.

We have four basic consulting offerings from BOT International regarding Project Closeout and Lessons Learned.  I would like to review each one and provide the following information:  type of engagement, length of engagement, participants, focus, and outcomes.

First, we have a culture and change initiative (PCOLL010).  This is a three to five day on site intensive culture initiative to instill an appreciation for project lessons learned and the value to be gained by sharing information.

The second offering is a three day intensive workshop (PCOLL020) aimed at groups of 20 or less to discuss tactical aspects of documenting lessons learned. 

The third offering is a five day on site engagement (PCOLL030) which combines the three day workshop with intensive discussion of project culture and importance of lessons learned in a continuous process Improvement framework.

The fourth offering is an intensive one day on site workshop (PCOLL040) whose participants will become “mentors” to others in the organization with regard to capturing, documenting and sharing project lessons learned.  The selection of these “mentors” is a collaborative effort with the project organization.

Obviously, these four offerings can be modified to meet the needs of specific organizations based on their individual project and business contexts, project organization maturity or Management’s desire to change the culture.  I would be happy to work with any Managers who wish to emphasize a specific aspect of Project Lessons Learned or Knowledge Management in our consulting work.

Please contact me at mbost@botinternational.com to discuss how BOT International can assist you with Project Closeout and Lessons Learned or any other aspects of PMO Setup and Maturity.

Everyone can participate in gathering, sharing, documenting, and capitalizing on lessons learned, no matter what their individual backgrounds might be or what field they may be interested in.

I am particularly interested these days in “innovative” techniques and methods for capturing lessons learned and the various ways that they are used to improve processes in daily life.

This morning I heard about a new venture that Marlo Thomas is pursuing on Broadway.  You will remember that Marlo Thomas is the daughter of Danny Thomas of early TV fame and a staunch supporter of St. Jude’s Children’s Hospital in Memphis.  Marlo herself starred in the TV show THAT GIRL with her steady boyfriend Donald.  I am not sure we ever heard what Donald’s last name was.

Marlo Thomas is appearing on Broadway in Relatively Speaking, three one-act plays by Woody Allen, Elaine May, and Ethan Coen that ”explore the often outrageous reality of relatives.”  When she discussed the specific details of the performances on TV this morning, one thing particularly interested me.  The playwrights for each play attend a play each week to see firsthand how the performers interact, how the plot unfolds, how the emotion runs, what the audience reaction is to various actions of the actors, etc.  In other words, the playwrights are getting an “in process” look at their own work each week.  They use this insight to change certain aspects of the play for the upcoming stage productions of the plays.

What an innovative approach!!!!   Reminds me a little of our discussion of project managers identifying lessons learned at the end of each major stage of a project which we have discussed several times in this blog.  This method also gives the actors insight into how their performances are being perceived and received by the audience so that they can adjust their actions accordingly.

If you are a project manager looking for ideas about how to improve your project, why don’t you try to “observe” the actions of your actors in their natural setting at least once a week.  How do they interact?  How do they interpret their lines and deliver the outcomes?  How does the entire project “play” out under your direction and initial charge to the group about what was the desired outcome of the project.

I will bet that many of you project managers have never attended a project review for another project in progress.  Try that sometime to see how others are approaching similar situations and how the various project actors are playing out their parts.

You will be very happy when you do this for the insight will rush over you like a wave on the beach.

Let me hear about your successes.  Good luck.

The HGTV consultant they were using suggested that they fill the planters with empty plastic water bottles to a certain height and then fill the remainder with dirt to adequately cover the plant roots and provide the irrigation needed.  Why?  The explanation was that the planters would be much easier to move around on the patio for different settings since the plastic water bottles, as opposed to soil, would make them not weigh as much. 

Now, this insight on the part of the HGTV consultant was very valuable to the homeowner.  It had been derived from the consultant’s experience gained in other such patio decorating, and made possible from collaborating with other consultants who worked in this field.

Sometimes “finesse” is what is needed in a project–rather than brute-force implementation.  In the case of the patio, the “finesse” of using a proven technique for the planters that would allow the homeowners be able to move them in the future was insightful, productive, and yet easy to implement.

How many times have you, as a project manager, examined your potential actions to decide if “finesse” could be used rather than “brute force?”  How many times have you collaborated with other project managers to describe a situation that you are facing that might be leveraged by “finesse” rather than by your own blind experience?

As Project Managers, we must look for “finesse” in everything we do.  It pays dividends in little ways.

This team recently assembled in Orlando, Florida at the 2011 PMO Symposium to demonstrate their process assets “Processes on Demand” to Symposium participants and to discuss their expertise in any field of PMO maturity and development.

The principal subject matter experts and their fields are:

Mark Price Perry:  PMO Setup and Maturity

Terry Doerscher:  Project and Portfolio Management (PPM)

Steve Romero:  Governance

and me, Mel Bost:  Project Closeout and Lessons Learned

Another BOT International consultant and facilitator, Cornelius Fichtner, interviewed the four subject matter experts during the 2011 PMO Symposium to provide his PM Podcast and PREPCAST listeners with the latest news on the BOT International talents.  Check out his podcast here.

BOT International is a global firm specializing in Project and Program Management Office (PMO) competencies.  Contact me to find out more about how BOT International can help you.

Here are some other factors 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 each of the Phase Gates of the project process.

2.  Web-based tools such as the Microsoft Project 2010 client and server or Basecamp allow Project Lessons Learned to be easily recorded so that they will be treated as just another piece of performance reporting information for a project.

Project managers who fully experience the project process—including the use of Project Lessons Learned—learn and acquire truth, knowledge, decision-making skills, and good judgment. 

There are three primary methods by which project managers may learn these valuable 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. quotation concerning “wisdom” and “lessons learned.”  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 to 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 to 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 finally beginning to change.  Many companies have begun to take Project Lessons Learned more seriously, and they are now  interested in closing-out projects with documentation preserving the “knowledge” created by the project, and the “experiences” of the project’s 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 in their business context—that 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 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 now employing Best Practice 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. 

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 and PERSPECTIVES contained therein.

2.  There must be a recognized “review” process to identify SIGNIFICANT EVENTS and CANDIDATES for Project Lessons Learned. 

3. There must be 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 (such as, as mentioned above, Microsoft Project 2010 or Basecamp) 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 the knowledge-management system, so that he or she can analyze the documented lessons learned in order to identify any broader lessons learned that 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 could relate Project Lessons Learned to the risks existing when you are developing a new technology concurrent with the project within which the new technology is being applied.  At the outset of such a technology-driven project, you can establish a plan to prove-out the technology as the project progresses.  A lesson learned could 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 could look at Project Lessons Learned at the end of each major phase of your project, and apply some “integrative thinking” principles.  This allows a reexamination of original “assumptions” for the project and sets the tone for good project planning for future project phases.

Does your organization have a capabilities-based strategy for making project lessons learned a Best Practice?

As a Principal Consultant with BOT International, we are interested in assisting PMOs and project groups with PMO Setup, Project and Portfolio Management (PPM), Governance and Project Closeout and Lessons Learned.  Call on me or email me if you would like more information about our consulting services.