The Critical “Knowing Steps “ for Successful Project Management

Some years ago, a friend of mine, and former colleague at Pratt & Whitney Rocketdyne, Kiho Sohn, were discussing the linkage between successful knowledge management and successful project management. I told him of my observations of inefficient startups and flawed execution of projects caused by inadequate attention to identifying and marshaling all of the relevant knowledge resources. Kiho lamented…“if only we knew what we know”, and that phrase has stuck with me over the years. As I’ve discussed in a previous blog, The Interdependency of Project, Risk and Knowledge Management, you can’t be a good project manager without being a good knowledge manager. In my experience, there are four critical “knowing steps” that project managers must go through in the planning and execution of any project.

1) Knowing What You Need to Know
2) Knowing What You Know.
3) Knowing What You Don’t Know.
4) Knowing That There Are Unknowable’s.

The following offers some strategies project managers can apply in the first two “Knowing Steps”. More in another blog about the last two

Knowing What You Need to Know
• Talk frequently and openly with your customer and your internal business sponsor. You need to build a trust relationship with them to get to the heart of what you really need to know for your project.
• I’m not just talking about the customer’s formal stated requirements and constraints, but also gaining knowledge of their market environment, goals, needs, fears and sources of pain. Such knowledge brings understanding, which enhances communication and decision-making.
• Remember, like you, your customers are going through their own knowledge building process and they can’t always tell you exactly what they want because they haven’t completely figured it out themselves.

Knowing What You Know
• What I’m talking about here is the nature, relevancy and availability of all of the knowledge resources that your business, your project team, and you can bring to bear on the project to provide an executable solution that meets the customers needs.
• You and your team will start looking for everything that’s been recorded in written or computer files, and you’ll find some success. That’s good, but you need to know that explicit knowledge probably only represents 10%-15% of the total knowledge on any given topic. The rest of it is tacit knowledge that is locked up in the heads of people. Worse than that, most of those people probably don’t even know what they know, unless they’re prompted by a context, story or event that triggers their memory. So don’t rely on individual interviews with those people. Instead, get them in a room with your project team members, tell them about the nature and challenges of your project and record the stories they tell.
• Network. Tapping in to the minds of those with relevant experience requires that you know who they are. Hopefully your company has established some kind of personnel competency and experience profile database. If you haven’t got that now, you’d better get started. Build yourself a “knowledge map”, or a knowledge registry of both the explicit and tacit knowledge available to your team. It can be as simple as a spreadsheet, or you can use tools like SharePoint and ask potential contributors to write profiles describing their competencies and experience. Make these profiles accessible and searchable by your team. Train the team to check this resource when they need knowledge, advice or ideas. Remember, studies have shown that the collective knowledge of a group of people is greater than the sum of the individual’s knowledge. The reason for this is what I call “interactive knowledge” where people only recall their knowledge when prompted by their interaction with someone else whose comment stimulates the recollection.
• Ensure that your team members act as knowledge managers. Your team needs to know that their success is as much a function of the effectiveness and efficiency with which they process information into knowledge, as it is the way they execute the project tasks. Share, don’t compartmentalize, project knowledge.
• Remember that what you know isn’t static. You and others on your team are constantly learning throughout the project. Make sure that you set expectations and establish the infrastructure to capture and share that knowledge effectively.
• As an individual and as a team, be curious and have a learning bias. Be open to new ideas or old ones, even if they’re uncomfortable. I’m not saying that you should necessarily adopt ideas that are uncomfortable, but listen to them, give them an objective assessment, and then if they look like they add value for acceptable risk, and then adopt them.