Tick Box KM
Two recent things prompted me to address this topic. One is for a voluntary organisation I work for where one of our supporters would like our volunteers (people like me) to become accredited advisors. After all we would "tick all the boxes". However, since there is no demand from our beneficiaries (out of work managers and professionals who we help) and to become accrediated would cost us the equivalent of year's rent of the premises we use, I question its value.
Another is an interesting article (Computing, 7 Feb 2008) by software professional, Peter Merrick, who says "it is not project management that is of interest, but project delivery. The fact that a project is well managed and ticks the right boxes, does not mean it will deliver a working system".
I recall when pushing companies to achieve ISO standards for customer quality was in vogue. Even though a company could get accredited, it did not mean it could deliver exemplary customer service, simply that it adhered to the procedures and standards it set for itself.
Unfortunately in bureaucracies - and that's what many large corporations and public sector organizations are today - there is a tendency to say that processes are in place and rules have been followed and to take the eye off the ball about what is really important. I've had a running argument with one such public service recently who keeps hiding behind "our minimal legal obligations" rather than thinking about the needs of the customer.
So far, most KM initiatives have succeeded using necessary but 'light touch' procedures. But with IT playing a major role in many KM initiatives, it would be a pity if too much attention was given to ticking the right boxes in the project management methodology and not enough to the essence of the project. Another danger lurking is that if the movement to KM standards and professionalisation movement were to enforce unrealistic 'standards', then KM might itself become too bureaucratized. Fortunately, the British Standards Institute has realized this and at the moment feel that KM is not mature enough for highly specific standards, so it issues 'guidance on good practice'.
Delivering KM should be similar to what Peter Merrick describes as a delivery framework for IT, i.e. one that "prioritizes the business community stakeholders, senior management, middle management, project management and users". I commend his PrinceLite delivery framework as an approach for knowledge management projects. It may not seem 'lite' enough for some KM practitioners (in that there are mandatory requirements) but its merit is that it is stakeholder-focussed, something every project manager ignores at his or her peril. As Peter himself says: "it does not tell you exactly what to do, but does give you some very strong hints".
Another is an interesting article (Computing, 7 Feb 2008) by software professional, Peter Merrick, who says "it is not project management that is of interest, but project delivery. The fact that a project is well managed and ticks the right boxes, does not mean it will deliver a working system".
I recall when pushing companies to achieve ISO standards for customer quality was in vogue. Even though a company could get accredited, it did not mean it could deliver exemplary customer service, simply that it adhered to the procedures and standards it set for itself.
Unfortunately in bureaucracies - and that's what many large corporations and public sector organizations are today - there is a tendency to say that processes are in place and rules have been followed and to take the eye off the ball about what is really important. I've had a running argument with one such public service recently who keeps hiding behind "our minimal legal obligations" rather than thinking about the needs of the customer.
So far, most KM initiatives have succeeded using necessary but 'light touch' procedures. But with IT playing a major role in many KM initiatives, it would be a pity if too much attention was given to ticking the right boxes in the project management methodology and not enough to the essence of the project. Another danger lurking is that if the movement to KM standards and professionalisation movement were to enforce unrealistic 'standards', then KM might itself become too bureaucratized. Fortunately, the British Standards Institute has realized this and at the moment feel that KM is not mature enough for highly specific standards, so it issues 'guidance on good practice'.
Delivering KM should be similar to what Peter Merrick describes as a delivery framework for IT, i.e. one that "prioritizes the business community stakeholders, senior management, middle management, project management and users". I commend his PrinceLite delivery framework as an approach for knowledge management projects. It may not seem 'lite' enough for some KM practitioners (in that there are mandatory requirements) but its merit is that it is stakeholder-focussed, something every project manager ignores at his or her peril. As Peter himself says: "it does not tell you exactly what to do, but does give you some very strong hints".
Labels: strategy
posted by David @ 4:00 PM
0 Comments:
Post a Comment
<< Home