That's Akapalah as in "a couple of" with a New England accent. OK. It's a stretch. But I like Egyptology, so any excuse to get a picture of a pyramid or a Pharaoh on the site is good enough. The subject today is the role the Project Manager plays in getting all of the data that flows around in different directions in gargantuan quantities to be as meaningful as possible to the stakeholders. Which brings me to something called the Knowledge Pyramid. Which of course allowed me the play of words in today's title, and the picture of "a couple of" pyramids that I've placed to the right and above.
This is one of the cases in which PM is a microcosm of 'general management', but the environment of a project makes us as PMs even more responsible than in a general management situation. Here's the scenario: your project is big. It has many stakeholders. It may be a clinical pharma trial, a new release of software, a telecom network upgrade, a research effort, whatever. If it's sized like any of those projects, you are dealing with tons of data. Data from instruments, surveys, management, customers. Data from schedules, budgets, requirements lists. Enough data to make the hieroglyphs (to keep our analogy going) blush with the shame of inadequacy.
Your job as a PM - realize it or not - is to upgrade this data into wisdom. Yes, you read that correctly. Wisdom. You can do something with wisdom. You can avoid previous mistakes. You can create new ways of doing things. And in the case of customers, wisdom pleases customers.
The thing to realize is that you cannot move directly from data to wisdom. there is a step-by-step approach, and this is where the DIKW, or Knowledge Pyramid comes in. This theory, which I have seen used by excellent PMs in practice many times, involves moving from data (D) to information (I), to knowledge (K), to wisdom (W). You can find an expanded explanation of this subject by clicking here. But here is my take on it from a PM perspective.
Data would represent bits of project information not organized in any particular way. I picture a phone number, a test measurement, a temperature and a website address thrown haphazardly in a jar as data. Keeping the Ancient Egypt analogy, this is like the canopic jars in which the Egyptians preserved the organs of the deceased. Actually, I'm sure it was quite orderly to them, but to us it's a jar full of random guts. Sorry for the visual, but I'm making a point over here!
Information is a state in which there is order to that madness. Now I picture a stakeholder contact list, organized and sorted by those who are inside and outside the organization, those with high and low risk tolerance, those in favor of and those opposed to the project, associated with all of their contact numbers. You sense an upgrade from the jar above, right?
Knowledge is that information leveraged to convey some important meaning. So we may have the information on our stakeholders organized so that we know not only phone numbers and emails but also key behaviors of stakeholders so that we know that when Seth (get the Egyptian connection again?) calls us, we are dealing with someone whose birthday is tomorrow. Shallow example, but it gives you the idea.
Wisdom could be defined as the applying intelligence (data, information and knowledge) and experience toward the attainment of a common good. Seeing the project manager, as would be natural for me, as the coordinator of the common good (the product of the project), I see the PM as gathering all of the intelligence possible, combining it with experience, to get to this stage (at the top of the knowledge pyramid) of wisdom.
The otha pyramid of akapalah pyramids
The other pyramid I cover briefly is one I tell my students is called Mount Fact. And the job of PMs is to climb that mount with your project teams. Mount Fact is a pyramid based on misunderstandings.
Belief-based misunderstandings. At the base of Mount Fact is a layer of belief-based misunderstandings. These are complicated, difficult to resolve, and can get heated at times. To answer the question, "who is your favorite Pharaoh?" one needs to go to their set of values, opinions and even arbitrary or quirky things to make that decision. And if I pick Khufu and you pick Amenhotep, we could both stand by our decisions and both be absolutely right.
Interpretation-based misunderstandings. One layer up, we find misunderstandings based on disagreements even if the parties agree on the facts. For example, even with all of the facts in hand, I could argue that Amenhotep was the most successful Pharaoh. And you could argue that Khufu was. But maybe I am measuring success by the number of years ruled and you are measuring by territory conquered. The key word is successful. We need to get agreement on what that means. As a project manager this is critical when you are defining what success means in terms of project closure. Or, your project may have eternal life, something the Ancient Egyptians wanted, but not something you want for your project which is supposed to end on 6-July-2008 (for example).
At the peak of Mount Fact, you will find factual misunderstandings. These are the easiest to resolve. If you can point to reliable sources that both parties acknowledge, there can be little debate. So if I tell you that Amenhotep was Nineteenth Dynasty and you say he was Eighteenth Dynasty, we could check that against sources from universities and museums to resolve the issue. (You are right - he's 18th). This is where you want to head as a PM (not universities and museums, necessarily, although that may work). You want to climb to this peak at which point you eliminate the misunderstandings based on belief and interpretation and rely purely on fact.
So I hope you enjoyed this brief tour of Ancient Egypt. Let me know if you enjoyed it. Write back, I can take criticism - just don't be a pain in the asp.