Profound “Aha’s” and “Duhhh’s”

Project Management practitioners call them lessons learned. These are lessons from things gone right and things gone not so right on the project. It is easy to talk about things gone right but not the more important lessons; opportunities for improvement, or what some call mistakes.
I want to leave dry Project Management Lingo and stick to what happens in real life. In reality, lessons learned are broken down into two categories: Ahaaa’s and Duhhh’s. Aha moments are those of discovery and learning.  Usually they have to be profound to provoke an Ahaaa!  the longer the “aaaa” part the more profound the experience.  Then there are “duh” moments.  These are not as welcomed.  They usually are statements made by others when we finally see what is supposed to be an obvious basic fact.  These are profound, but we do not know that when we make the mistakes.  Both Aha’s and Duh’s are key in the development of professionals.

Some deny the Aha! moments.  These are the “know-it-all’s.”  Learning is a risk of seeming ignorant, instead of being an opportunity to grow. They lose a big chunk of the learning by their denial.  All to please the ego.  Some also deny the duh moments, and these too face problems learning. A mistake is a risk of getting exposed, instead of a chance to improve.

Every professional should reflect on his personal Aha’s and duh’s, to grow and improve.  Everyone can write a book about these based solely on personal experiences, if one is observant enough to catch them.

My favorite personal Aha! moments, Well, I have two favorites.  One from my mentor, who taught me that I can be a manager and be me.  I can adopt any style, learn from best practices, improve my skills, and anything else that I want, and still be me.  He taught me that I can be a manager and have a heart.  I can be a manager and have a sense of humor (it does not mean that I have one).  It was an Aha moment that opened up lots of doors for me, without having to pretend to be someone I am not.

My other favorite Aha moment, professionally, is when I learned from another mentor that if someone is disrespectful, mean, or not cordial to you, most probably he or she is like that with everybody.  So, it is the person’s problem not yours.  Protect yourself from the actions, but never take it personally. Many times people I found repulsive, I found out others found them the same way even worse.  So, it is not really my problem.  This helps a lot in picking your battles wisely.

I have had my duhhh! moments as well. I will only mention one even though God knows they are plenty. I learned that if there is an inherent problem in a setup, unless you address that inherent problem, trying to make things work is a futile effort. I bought once a Cafe in a land far far away, and a long long time ago. The previous owner was not doing well and the cafe was going out of business. The main problem with the cafe was the location. It was out of sight, and not very inviting. I thought I can outsmart the problem by giving the cafe a slick name, offering gourmet cakes, fancy coffee etc. But how does all that fix the location problem? it does not; duhhh! So instead of becoming a cash cow the place turned into a cash drain. The rest is history, and lessons learned
What are your Ahaaa’s and Duhhh’s? Please do share.

Certification mindset and the training dilemma

PMP training might be the most popular project management training out there.  It should not be.  Not in this day and age.  PMP played a key role.  While important and necessary, it is not sufficient.  PMP is the Project Management Professional certification by the Project Management Institute, PMI.  Hundreds of thousands of project managers have been certified and have the PMP designation next to their name.  While this helped the industry, we are today at a cross-road where the PMP training is not enough.

Most organizations are finding out that it takes more than just hard project management skills to succeed in projects.  While knowing how to develop a project charter, a schedule, a budget, or a breakdown structure are key, they are not enough to ensure success.

Consistently, surveys from leading organizations worldwide are showing that those who are among the best project managers possess skills beyond those required to calculate a critical path, or earned value.  They are leaders.  They have a business sense and an understanding of the value sought from the project.  They are able to engage stakeholders and empower their teams.   They know how to negotiate and use opportunities available to them for the betterment of their projects and their chances for success.

Organizations are looking for project managers who are proactive not reactive.  They are not waiting for input from their sponsors on what to do, but to the opposite, they are giving directions to their management and their sponsors and clients on what is needed to make the project a success.  They have the virtual power to demand that their employers and clients do the right thing to reap the project benefits.

It seems that organizations do not want project managers anymore and want more of business project managers who can ensure value and benefits from the project, the same way a project manager is responsible for value and benefits not just deliverables.  I think this will give rise to the importance of the program manager role, who is responsible to ensure benefits, and be responsible for maybe operations of the handed over deliverables from projects, to ensure delivery and sustaining of value.

I think it is time for the professionals in the industry to start helping business executives understand the role of a program manager beyond what a project manager can do.  Also, professionals should start designing leadership and soft skills courses that target project managers specifically and help build their soft skills as leaders from a business perspective not a technical perspective.

There is still room for the technical project manager, but even they will need the soft skills to empower their teams and communicate with stakeholders.

So the need is there for businesses and organizations to recognize the need to build leadership and soft skills, and for the industry to start offering these courses, beyond the generic form, and specifically target the project and program manager needs.

I believe the older generation before the PMP understand the project manager skills needed more than those who became project managers during the PMP era.  Pre PMP, there was no defined or structured certification for project management.  They had to take care of business and they knew they needed the soft skills to handle the project.  Post PMP I think many project managers started relying on the certification assuming it will suffice and replace the need for soft skills.  Apparently that did not work, and organizations are still looking for the leader project manager.

 

 

What I learned at PMI Congress 2013 in Istanbul

I have not been to a global PMI congress for over 20 years now.  So it was about time for me to attend again and it was a learning experience.  The choice of location, Istanbul, was excellent; beautiful city that represents the trends and changes we are witnessing in a changing world of emerging markets.

I will try to sum up my learning  briefly, and hope to be able to cover some of the more important points in later blogs.  I do not think any of the items below are earth shattering, but they give telltale signs about where the profession is heading, and how to take advantage of the opportunities these trends offer.

The main theme for the congress to me was the new role for a project manager, beyond being just a manager.  Many of the keynote speakers made strong connections between project managers’ success and their ability to grasp and act upon the project from a strategic perspective that includes understanding the markets, policies, culture, politics, and business strategy surrounding the project.  There was consensus that the project manager has to act more as an executive than a manager to succeed in today’s fast paced work environment.

There was a lot of focus on the importance of agile as a business philosophy, not merely a development or management technique.  The focus was on repetitive fast paced moves, if you will, towards a goal, while keeping the stakeholders on board and revisiting and refining requirements and direction continuously and effectively.

The project manager as a leader and influencer also took center stage.   Jay Leroy Ward talked about the 14 skills a project manager must possess to succeed, and all of them where on the leadership and communication side of things, not on the hard skills side of project management.  He and many others emphasized that training efforts in organizations are more geared towards hard skills, and away from the soft skills required for success.  It does not mean that hard skills are not important, but they will be much less effective without the right leadership and communication skills.

Another theme in many sessions was the importance of collaboration, networking, and trust among stakeholders.  They are the real drivers for project success and are quickly replacing traditional modes of governance like hierarchy, direct authority, and we-they or win-lose relationships.

A related subject that also was discussed was the focus on quality rather than quantity especially in working hours, relationships among team members, and management.  Pushing people to work “harder” and longer hours is becoming something of the past, as more organizations are finding out that effectiveness is not proportionally linked to number of hours worked.

It is pleasant and reassuring to see the models of fairness, trust, and collaboration still reign with the professionals and experts even with the difficult situation of the economy worldwide.

There was lots of witty humor and use of YouTube and media in the presentations which was refreshing and fun.  May of them focused on cultural interfaces and challenges.  Here are a few:

- The offensive translator

- lost in translation

- Dinner Etiquette

And finally a picture shared by Jay Leroy Ward on the importance of trust among team members which shows my favorites: The three stooges

 

 

Organizational Theory and Project Management

One way to look at Project Management is a means to realize effective delivery from the organization(s).  Delivering through layers of organizational hierarchy is not easy especially if the organization was setup for operational work without much consideration to project work.  Because of challenges faced by organizations worldwide in delivering successful projects, most have revisited their organization structure to accommodate project delivery.  Organizations usually start making changes hastily, based on traditional recommendations like changes a functional structure into a weak, balanced or strong matrix.  Some even go the projectized route.  There is lots of information about how to affect such changes in the organization so I am not planning to talk about that.

Instead, let us talk about some of the new methods that are out there that can help the organization deliver projects in a more effective fashion.

One of the options is to organize projects into programs and assign a program manager and create a program management office to oversee the program.  The advantage of this relatively new route is the executive perspective the program manager brings to the table through focusing on value and benefits and sustainability instead of just focusing on deliverables.  For this to work, experienced program managers must be assigned and must report to a sponsor at the right level in the organization to properly support the program.

Another option that I believe we will see more often in the future is an “organizational circles” setup where organizational circles are formed at different levels in the organization to support the project.  So, one project circle would include the project manager and the team leaders and team members.  A higher level circle will include the project manager, functional managers, and maybe the Project Management Officer, another circle might include an executive steering committee, for more important projects, which includes executives and upper management members.  If an organization takes this route, it is important to define clearly governance for these circles, and ensure accountability.  I like this method as it avoids having to deal with organizational structure changes, and focuses on getting the project completed successfully, with the right level of rigor and support vertically and horizontally through the organization.  another advantage of this technique is that it works nicely when multiple organizations are involved, with different approach to managing projects which might cause conflict or confusion on the project.  Bringing members from different organizations into the circles allow flexibility in charting circle rules, instead of being tied to different organizational rules.  If any work is outsourced, it is important and crucial to bring in suppliers as well as clients into the circles.

The important thing in any setup is to clearly define governance, escalation, accountability, and where subject matter expertise will come from.

“Certified Project Executive” Anyone??

I was reading earlier an article in the PM Network issue this month, that quotes Mr Mark Langley, Project Management Institute – PMI President, challenging audience to become “Project Executives” not only Project Managers.  This really clicked for me and I think he hit the need right on.  We need a level of project management competency that ensures leadership at the BUSINESS level of the project.  This is how I understood Langley’s comments and this is the need that I see on the ground.

If one looks at what the organizations consider as the best project managers, they are are those who:

1. Understand the Project Management Knowledge

2. Know how it is applied

3. And most importantly know how to masterfully apply it or lead a project management team that applies it in a business setup.

I think the PMP certification can shed light on the first two points, but might fall short from guaranteeing the third.  It is one thing to be a certified Project Management Professional (PMP) (All rights reserved to the Project Management Institute – PMI http://www.pmi.org), but it is another thing to be a competent project manager.  I am a proponent of certification and believe that the PMP certification has served the industry and the project management professionals very well, myself included.  However, many companies are seeing the need to differentiate between someone who has 3 years experience in project management and passes the PMP exam, and someone who can really lead the business of the project.

For example, as a PMP, one might know:

- How important a project charter is,

- When it must be developed,

- Who should be involved,

- What should be in it.

But still a PMP might not be able to develop a value adding project charter, or evaluate the quality of a project charter.  Just because a project manager knows a project charter should include clear definition of the business need, does not mean that manager know how to articulate it.  I have seen project charters that are a waste of time, as if they were written just to get checked off someone’s checklist.  Sometimes because the project manager does not really believe in its importance, and other times because of external pressures of others who refuse to cooperate or subscribe to its development and chartering.

On top of what is required to be certified as a PMP, a competent project manager, also needs the following essential attitudes, competencies, and abilities:

- The Project Manager has the conviction that this is an essential document

- The Project Manager has the leadership abilities to use influence and resources to get others to subscribe to the charter and its development

- The Project Manager knows how to develop or ensure quality value adding content is in the charter, not just a space filler kind of information.

- The Project Manager knows how to communicate the charter and when to refer others and self to it throughout the project

- The Project Manager knows how to use the charter to improve chances of project success throughout the project

The above skills and competencies are needed for all other tools and techniques of project management including managing stakeholders expectations, developing a communication plan, managing conflict, etc.

In the big scheme of things, I see the PMP as a good place to start to acknowledge a project manager who understands how the PMBOK should be applied on actual projects.  But then, there is the project manager who does not only know how, but a master of this application in real life.  At this level of competency, the project manager should be tested in the ins and outs of the technique, the outcomes, and the actual development of the outcome, and how to use it.  The PMP exam is not designed that way in my opinion.  To give an example, the PMP exam asks questions that ensures I understand the importance of the communication plan, its main components, who should be involved in developing it, etc, but I can know all that and not be able to write a decent communication plan.

When I keep using the word masterfully, it does not mean “perfectly.” There is no black and white in the management science and organizational theory.  There is always a better way, and room for improvement.  So, “masterfully” means the wisdom and experience to utilize what is available to the best of one’s ability to create value, and be ready and flexible to modify as needed to meet needs and expectations.

I understand the difficulty coming up with such new certification can pause, as far as logistics, design, etc, especially when trying to apply this globally.  However, I believe it must be done.  At a high level, this is how such certification might look like:

1. Pass a preliminary test that shows that they have sufficient PM knowledge, leadership abilities, and experience.

2. Qualifying application, CV review, and multiple interviews including some kind of a 360 evaluation

3. Read assigned reading which will include books, papers, etc pre-selected to cover the key focus areas of the certification.  There will be no one reference.  Also, for tose who prefer to learn in a course setting, a training will be provided on each focus area online and classroom style, but they will be optional not mandatory.  The key focus areas should include:

- Organizing and preparing for initiation

- Project Initiation

- Project Charter Development

- Securing Management Support

- Managing Client Expectation

- Cross Organizational Stakeholder Management

- Initial Project Setup

- Risk Management, beyond the mechanical structure, and into engaging stakeholders, clarity, commitment, and decision making

- Defining the project organization structure and its support structures

- Managing Stakeholders Expectations

- Scope Definition and the skill of writing a scope statement, building the WBS, and writing the WBS dictionary in way that serves the WBS purposes

- Developing a baseline at the right detail level, and additional derivative baselines for different project working levels

- Distributing work and project ownership

- Managing Subject Matter Experts and resource managers

- Project Reporting including report design based on level of reporting and stakeholders needs

- Estimation techniques and its relationship to type of work, team motivation and type, and other behavioral factors, and linking estimation with risk management and progressive elaboration

4. Attend a workshop to cover the focus areas that the certification focuses on.  The workshop will allow discussions of these areas and presentation of the take home assignments in the next step.  The workshop will be 5 days.

5.  Take home assignments to develop necessary artifacts based on a given case study. These will be presented by candidate to panel of experts at the end of the workshop.  The review will be elaborate, where a day will be assigned per candidate for the discussion and review of the candidate’s work.  The work will be scrutinized and this will be the most challenging part of the certification process.

5. Final exam, not multiple choice, where candidates have to demonstrate their ability to deal with open scenarios that do not have a clear “correct” answer.

6. Once passed, the candidate will receive not only a certification, but a presentation and media from certifying body about the skills and abilities of the candidate who carry the certification.  The candidate will be certified only in the areas he or she demonstrated competency in, so it does not have to be all or nothing.  So, If I am competent in managing stakeholders expectations, but did not reach that level in estimating, I will get a certificate of competency that lists just the areas I covered.  Later, as my competency is verified in other areas, they are appended to the certificate.

7.  The certification is a lifetime certification, not subject for renewal.

I believe that the main driver for this certification will be companies who hire the certified professionals, and how easy the certification makes it to select the practitioner who can run their project as a business, not merely has the project management knowledge and how it is applied.  Instead they can apply what it takes for projects to succeed and provide value.

I know that such level of complexity is difficult to achieve, but if this is what the industry needs to grow and mature, it might be necessary to overcome the challenges and come up with such certification.

For PMP to continue its success as a certification, we need a distinguishing certification that acknowledges the big difference between a three years experienced project manager who learned the structured PM approach and had a brush with its application, from the competent project manager who also knows the structure, but is a master in applying it in real world projects.

Thirty One Ingredients of Failed Projects

Failed projects have a lot in common.  Here are the things I most commonly find in failed projects, the lower the number the higher the impact:

31. Focusing on the mechanical part of planning (critical path calculations, the schedule model, etc)

30. Ignoring proper definition of “project success” and “project and product quality” by all involved

29. Making promises you cannot keep

28. Lying

27. Thinking you are smarter than everybody else

26. Dealing with the client as an inconvenience

25. Focusing on finishing the project (instead of providing value to the client)

24. Not reading every single project related document (especially business and high level technical)

23. Being oblivious to project developments

22. Disconnect between project manager and client

21. Disconnect between project manager and sponsor

20. Uncommitted client

19. Uncommitted sponsor

18. Uncommitted team

17. Trying to win popularity contests instead of holding everyone accountable

16. Ignoring subtle and not so subtle messages from stakeholders especially client

15. Avoiding the client and how satisfied they are of your work personally and the project

14. Getting stuck in busy work and ignoring big picture (like an ostrich sticking head in sand)

13. Being afraid to say no

12. Ignoring the contract and project documents

11. Rough attitude (thinking that by being cruel people will fear you and do what you want)

10. Soft attitude (unable or afraid to reprimand)

9. Hiding in your cubicle

8. Taking progress reports as accurate (without double checking)

7. Victim mentality, refusing to take responsibility for mistakes and errors

6. Blame game, blaming others and not standing up to your part

5. Hogging credit, and not giving credit to the team and other stakeholders.

4. Mistrust others

3. Assuming you can win alone, and let client and suppliers and team lose

2. Quitting early; assuming there is nothing you can do and letting the project go south

1. Fear of failure; you will never get anything meaningful done

Thirty-ingredient recipe for successful projects

Projects require certain ingredients for success.  They do not guarantee success, but the more you have of these ingredients the better are the project success chances.  Here are the top 30 ingredients I see in successful projects.  All of them are important, but the lower the number the higher the importance.  How many of these does your project and its environment have?

30 User Friendly Collaborative Web Based Software
29 Document Management
28 Issues & Risk Management
27 Control, Progress Analysis &Reporting
26 Project Baseline (especially WBS, WBS dictionary, and Schedule)
25 Project Charter
24 Project Management Training (Preferably on Custom Methodology)
23 Project Methodology
22 Team Buy-in
21 Project Management Awareness
20 Communication Planning and Management
19 Big Picture view of project
18 Project Awareness & Marketing
17 Engaged Subject Matter Experts
16 Skilled Project Manager
15 Capable PMO
14 Engaged Client
13 Engaged Project Sponsor
12 Cross Organizational Project Steering Committee
11 Upper Management Support
10 Clear Project Objectives
9 Good business case
8 Positive Attitude
7 Trust
6 Fairness
5 Clarity
4 Honesty
3 Integrity
2 Competence
1 Good Intentions

How to tell if a project is in trouble: Part II the quick casual way

When it comes to analyzing the health of a project, there is a structured way, and a quick casual way.  You always want to go with a structured approach.  However, that is not always possible.  Then you have to go with a casual quick way to get you the indications you need about the health of the project.

In Part I: I already discussed the structured way of checking on a project.  In this part (Part II) I will focus on the casual quick way, when you do not have access to enough data and information to go on.  Luckily there are always tell-tale signs that something is wrong on the project.  Here are a few of these signs.

- If the project manager and or team members are always too busy to talk to anyone.  This is a sign of not wanting to face reality. When the project manager and  / or team members “hide in a cave” refusing to talk to anyone and getting irritated by requests for updates, the project is for sure in trouble.

- When the delivery is late and everybody is saying that we are “almost done” and it is a matter of a few days.  Usually the next line is “SURPRISE: we cannot deliver.”  Sometimes the line does not come from the project manager.  He goes  on a surprise vacation and stops answering phone calls.

- If blame game is taking priority over real progress.  This is where everyone is trying to document and create evidence that they have done their part on the project and it is someone else’s fault that things are not going well.  Sometimes this is done through emails with unclear meaning or goal, but somewhere in there is a line that will be used to prove that ” I already told you that in my email.” Sometimes these emails are started in a very tame neutral voice to hide the “bombs” hidden somewhere in the middle of the email, in the longest paragraph that most will not read.

- If the project plan is based on optimistic estimates that were given by managers who fix the estimates to match the needed deadline, without any attention to reality.  Team buy-in is lost on these estimates, but the team do not say anything for fear of retaliation from management, so they keep their head down and work, knowing they cannot meet the deadline.

- When there is no such thing as a “project team.” Different employees from different departments are working on tasks that have no integration.  It is just a task on some project and when it is done there will be another task on another project.  The employees are working in a department, focusing on the operational aspect of what they do.  No team spirit.  No project integration.  The project manager is looked at as the “nagging figure” that annoys us about finishing faster.  The department manager is looked at as the protector who protects us from the project manager and his unrealistic requests.

- If the project manager is not communicating, and project plans, issues and risks are kept in a drawer at his or her desk, instead of communicating with stakeholders.  When project manager avoids the confrontation and emails these issues and risks and assumes he or she did their duty by sending them and it is up to others to respond.  If they do not then it is not the project manager’s problem.

- If projects are used as a political platform to serve agendas like: “this department is not doing its job,” or even worse: “I am indispensable for the organization,” and to prove someone to be wrong. This usually leads to ethics and professionalism becoming lip service, but project stakeholders have no problem lying, hiding the truth, or acting in an unprofessional fashion.

- If management throws the project at the project manager and turns its back assuming that everything is fine, just because they are not hearing from the project manager.  They follow the wrong rule of “no news is good news.” Usually on projects it is the exact opposite.  Silence is a sign of trouble.  Management must challenge the project manager and team to “show” progress and how the project is proceeding towards providing intended value.  Also, management must provide the project manager with the necessary support especially with dealing with issues and risks that are outside the responsibilities or control of the project manager.

- Rhetoric: When project correspondence looks like a political speech, talking about the greatness of manager X or the honor of organization Y then you can be sure that the project is in deep trouble.  If we exalt the project and its stakeholders so much , and they are so perfect, then how can we dare bring to anybody’s attention the potential problems the project might face or the shortcomings of the work done to date?

- When people are afraid to make mistakes and all they care about is not to do anything wrong.  If you are not making mistakes then you are not working.  But Most would rather not do any work rather than get blamed for mistakes they made.  This is a management problem, not team members problem.  If management does not create an atmosphere where team members are comfortable making mistakes, then no difficult project or undertaking will ever be tackled with enough rigor to succeed.

How to tell if a project is in trouble: Part I the structured way

When it comes to analyzing the health of a project, there is a structured way, and a quick casual way.  You always want to go with a structured approach.  However, that is not always possible.  Then you have to go with a casual quick way to get you the indications you need about the health of the project.

This part will address a structured approach.  I am planning to do a “part 2″ later to address the “quick and dirty” method.

If you are going with the structured approach, here are a few tips to help you determine how well a project is progressing.

The first thing to do is to understand the intent from the project.  If the intent is not clear, then the project is already in trouble.  Intent is different from objective.  Intent is strategic, and talks about why the project is undertaken in the first place.  Objective is more about the final deliverables expected from the project, which tells you about the resulting “product” but not why it was developed.

Look at the original project documents: the request for proposal (RFP), proposal, and contract.  Try to understand the project objectives, scope, approach, key stakeholders, and assumptions.

Then move your attention to the project baseline: which is the agreed upon project plan between the key stakeholders including contractors, customers, suppliers, etc. If a project baseline does not exist, and everybody is relying on what is in the contract, the project is already in trouble.

Your next move is to look at the latest progress reports, risk and issues logs, and a comparison between the original baseline, current baseline (which is the original plus approved changes), and current plan.  Make sure you check the latest update to any of the documents.  Anything over a month since last update most probably is an indication of an obsolete document.  If any of the above is not there, or progress documents and plans are obsolete, then the project is most probably in trouble already.  Also, ask about which “phases” have been completed, then ask about the completed phases, what is the work that must be done before they are declared complete, and whether that work has been done actually.  You will be amazed at how much work is missing on things people consider “complete.”

You should not rely on progress reports alone.  You should assess the situation first hand.  Use the words “show me” a lot when requesting evidence of work accomplished.  Go meet with people working on the project, and see if you get consistent answers from them to seemingly innocent questions like “How is the project coming along?”  If people are not too talkative, shy away from discussion, or give you generic answers, then either their project is top-secret or the project is probably in trouble.  Make sure your tour includes visits to client and suppliers, and other key stakeholders, not just the performing organization.

Finally, if everything seems to be in perfect order on the project; the plans are up to date, everything is on schedule and on budget.  There are no complaints from customer.  There are no issues.  Then most probably the project is in trouble.  

Lessons Learnt from a 1400 year old project

605 AD; Well over fourteen hundred years ago, the Meccan tribes collaborated on a critical project.  The rebuilding of the Kaaba.  As is the case with projects always, conflict arose: Who will have the honor of placing the most sacred Kaaba stone in its place?  Every tribe wanted that honor, and mediation and arbitration seemed to reach a dead-end.  Fighting almost broke off.  Then a Meccan solved the problem through compromise, and placed the stone in its place with his own hands, after each of the tribesmen representatives carried collectively a cloth on which the stone was lifted.  The conflict was over and the project carried on.  End of the story, which is repeated so many times in books that talk about life of Mohammad (pbuh) before he became a messenger.

The question that always was in my mind: how did this solve the conflict?  I mean after all each of the tribes wanted the honor of placing the stone in its place, then all of them gave that up to a man who is not considered one of their chiefs.  They all carried the stone to its place but it was he who put it in its place.   He was not a prophet then yet.  He was a young Meccan man who was known for his honesty.  Why let him do it and get that honor?  Can the answer offer a lesson learned for projects of today, even if it was from such an ancient time?

To solve this mystery, let us start with facts: Mohammad (pbuh) was known as an honest man.  He was even nicknamed “Assadeq Al-Ameen” which means the honest man who speaks the truth.  Another fact is that the conflict was mainly an  ”honor and shame” conflict.  Honor and shame was a major factor and motivator for Arabia tribes.  It was only after Islam that the mentality of honor and shame was given a secondary priority to more important social rules like  justice, freedom, and equality.  All the tribesmen involved in the conflict were playing that game: the honor game.  Mohammad (pbuh) was known not to want any part of that game.  So,  the man was not interested in the game they were playing and he was to be trusted.  Two elements allowed easy solution to a complex problem.

This is not a lesson in history or a lesson in Islam, but a story about the importance of trust in dealing with conflicts on projects. Trust could be the most ignored element on projects but it should not be.  Without trust, projects get in trouble, and sometimes fail, but rarely do people notice the effect missing trust played in failed projects.  If we look at the example above, it is clear how trust played a factor in solving the delicate issue.

This leads us to a modern day rule about building trust and influencing others.  It is called the “psychological contract.” The psychological contract is an unwritten contract that governs relationships between any two parties.  It consists of two subliminal statements that each party can make.  The two statements are: 1) “I mean you no harm,” and 2) “What’s in it for me.”  The first builds trust that there are no hidden agendas or a trick up anyone’s sleeve.  The second shows the other party what they get for cooperation.  If any of these two elements are ignored, influencing others becomes a tough task and even if achieved will remain on shaky grounds.  From his past demeanor, no one even doubted Mohammad’s intentions that he was sincere in trying to solve the problem without hurting anyone.  Also, he showed all what’ s in it for them when he allowed them all to have the “honor” of raising the stone on the cloth closer to its destination.

Unfortunately, trust is taken for granted;  As if trust is there by default and there is no need to talk about it. When in reality, trust might not be there at all.  Some look at it as a textbook word that is used for marketing purposes.  Try to bring up trust in any conversation with project stakeholders.  Either they roll their eyes, or try to agree with you as fast as possible to get to talk about what they think really matters, instead of wasting time talking about trust.

I believe that the solution offered by Mohammad (pbuh) on the Kaaba project was not the only solution.  I would think that if any of the quarreling factions offered this solution, it would be turned down.  What made the solution acceptable was the built trust he had with everybody involved.  I think any other solution that gave a “what’s in it for me” to everyone involved, and with the existence of the element of trust could have solved the problem.

Another important lesson from the story is the need to build trust over time.  Unfortunately we cannot build trust just as conflict arises.  Trust is built over time, from many tests of putting people in situations where there integrity and honesty are tested.  Just once acting dishonestly brings down trust built over years.  This is why one has to build trust carefully and guard integrity very closely.