Absolutely Murray, in fact my thought on reading the original question was that the PM mindset is to manage from start to end, and that may be where the particular phrasing of the question came from.
However, I’m not sure I agree on accommodating to this mindset too much, without giving some push back, especially with regard to double loop learning, and managing critical knowledge across multiple projects. I think your distinction between a project and a program is an excellent way to do that.
P
On 3 Nov 2022, at 8:55 PM, Murray Jennex < murphjen@...> wrote:
I agree with you Patrick as I would look at learning how to do the analysis and how to improve that process as a reflection of KM maturity (you would be surprised how many organizations don't think of learning to do the process better and just focus on the outcome). I was just speculating that in the PM world they are probably looking at knowledge processes a little differently. PM is about managing short term activities to a conclusion, it is all about the end state when it comes to achieving project success and realizing project benefits. In that world asking for the end state is a very valid request and I think we need to work within their culture on this. Yes, we know that KM is an evolving set of capabilities and goals and continuous improvement. PM focuses on continuous improvement but with respect to very measurable goals. I don't think we will win many PMs over by not recognizing that they work in a world of short term activities with measurable goals and end states. Currently, PMs think of project knowledge as lessons learned, we can help them expand that concept to be more inclusive of process and capability improvement. However, I think PMs will only shake their heads at us if we refuse to work our concepts into the way their world works. PMs are more concerned with knowledge (singular) than broad knowledge (plural) and they are very focused on measuring benefits. When PMs say end state they mean after the project completes. Our answer that there is no end state means to PMs that we aren't talking projects and instead have moved into programs, perhaps we should state that very clearly PMs are not doing stand alone KM projects but that they need to look at as a KM program with a series of KM projects. The KM projects can and must have an end state with measurable benefits and goals. Most of our discussion has focused on the KM program (and rightfully so). My read of the original question leads me to see this difference in concepts and perhaps that is the first step to answering this question, emphasizing that KM is not a project but a program....murray
-----Original Message-----
From: Patrick Lambe < plambe@...>
To: main@SIKM.groups.io
Sent: Thu, Nov 3, 2022 2:04 am
Subject: Re: [SIKM] Knowledge Maturity #maturity
Hi Murray
You are quite right to make a distinction between specific knowledge artefacts/ resources and knowledge in general or “knowledges” pertaining to a domain, and I accept that specific knowledge resources (usually explicit) may reach an end state.
However, I find it more useful to think of the broader knowledge ground out of which those resources are produced, which guides how they are applied, and which determines when they need to be updated, discarded or replaced. And against that ground, (as you point out) different knowledge resources change at different paces - “knowledge pace layering” if you like. Managing that environment is the real point, I think.
For example, in your case of the engineering solution, yes the solution is interesting and important, but the “ground” of knowledge out of which that solution was produced and in which is it used, is the more important resource, I think, because it is that which tells us how and when to renew it.
Why more useful? Because none of what we do makes sense if we don’t look beyond the resource to the purpose and context of using the resource.
P
Patrick, I understand when you use the term knowledge you are using it in plural, no problem, I just didn't want you to think I was criticizing something I wasn't. My question and point is that as knowledge (in a singular state) matures it may reach an end state where it is only historical/archival in nature and will no longer mature. It may be used again, but it may not. For example, I do an engineering analysis of a problem and reach a solution, it is very useful knowledge as long as I have that component in service, but after a while the component becomes obsolete and is replaced, the knowledge of fixing the problem becomes obsolete in that unless I can relate it to another component it may not be useful directly. I still may retain it for training purposes or historical purposes but for all intents and purposes it has reached its maturity and end of life. I could also apply this logic to many social situations as there are many things we believed as knowledge in the past that would no longer be considered useful or appropriate, that knowledge has reached end of life and is useful only for historical purposes. Frankly, I believe all knowledge has a life cycle with some life cycles being very long and others fairly short. So in this context, I would suggest there is an end state for knowledge....murray jennex
-----Original Message-----
From: Patrick Lambe <plambe@...>
To: main@SIKM.groups.io
Sent: Wed, Nov 2, 2022 11:17 am
Subject: Re: [SIKM] Knowledge Maturity #maturity
Hi Madeleine
I don’t think I would ever use the concept of “end state” with reference to knowledge, because all knowledge has to adapt continuously to changing demands, needs and opportunities. Projects may end, but the knowledge does not.
I do think capabilities are the right way to frame the question, because that covers the base of ensuring that knowledge is kept relevant. Similarly, I think one could define what a desirable knowledge environment/ infrastructure should look like to maintain different classes of knowledge to the necessary levels of relevance, accuracy, completeness, timely production, accessibility, etc.
For these attributes, not all knowledge classes are equal, “it depends” as you say what requirements they might want to set for different classes of knowledge. Some areas of knowledge are more slow moving or fast moving than others, and some forms of knowledge have very high dependencies and risk factors associated with them (e.g. when the technology changes quickly, or there are supply chain disruptions, or new regulatory requirements, or key lessons learned from a major incident).
I hope this is helpful
P
Hi,
I'm currently assisting an organisation with managing their project knowledge. They are looking to me to define an end-state. Something they can work towards. They keep on throwing Knowledge Maturity into the mix..... what would mature knowledge look like?
I know of APQC's Knowledge Maturity framework but that looks more at KM as a capability. Any ideas on where to look or what to use to define "mature knowledge"? I'm kind of leaning towards - it depends on what you want, but maybe you have some ideas.
Appreciate the input
<SK18th_Anniv2020_emailfooter (2).jpg>
|
