SCENARIO-BASED MODELLING: Storytelling our way to success. 1

“The soft stuff is always the hard stuff.”

Unknown.

Whoever said ‘the soft stuff is the hard stuff’ was right.  In fact, Douglas R. Conant, coauthor of TouchPoints: Creating Powerful Leadership Connections in the Smallest of Moments, when talking about an excerpt from The 3rd Alternative: Solving Life’s Most Difficult Problems, by Stephen R. Covey, goes on to note:

“In my 35-year corporate journey and my 60-year life journey, I have consistently found that the thorniest problems I face each day are soft stuff — problems of intention, understanding, communication, and interpersonal effectiveness — not hard stuff such as return on investment and other quantitative challenges. Inevitably, I have found myself needing to step back from the problem, listen more carefully, and frame the conflict more thoughtfully, while still finding a way to advance the corporate agenda empathetically. Most of the time, interestingly, this has led to a more promising path forward and a better relationship, which in turn has made the next conflict easier to deal with.”

Douglas R. Conant.

Conant is talking about the most pressing problem in modern organisations – making sense of stuff.

Sense Making

Companies today are awash with data.  Big data.  Small data.  Sharp data.  Fuzzy data.  Indeed, there are myriad software companies offering niche and bespoke software to help manage and analyse data.  Data, however is only one-dimensional.  To make sense of inforamtion is, essentially, to turn it into knowledge. To do this we need to contextualise it within the frameworks of our own understanding.  This is a phenomenally important point in sense-making; the notion of understanding something within the parameters of our own metal frameworks and it is something that most people can immediately recognise within their every day work.

Contextualisation

Take, for instance, the building of a bridge.  The mental framework by which an accountant understands risks in building the bridge is uniquely different from the way an engineer understands the risks or indeed how a lawyer sees those very same risks.  Each was educated differently and the mental models they all use to conceptualise the same risks (for example)  leads to different understandings.  Knowledge has broad utility – it is polyvalent – but it needs to be contextualised before it can be caplitalised.

Knowledge has broad utility – it is polyvalent – but it needs to be contextualised before it can be caplitalised.

For instance, take again the same risk of a structural weakness within the new bridge.  The accountant will understand it as a financial problem, the engineer will understand it as a design issue and the lawyer will see some form of liability and warranty issue.  Ontologically, the ‘thing’ is the same but its context is different.  However, in order to make decisions based on their understanding, each person builds a ‘mental model’ to re-contextualise this new knowledge (with some additional information).

There is a problem.

Just like when we all learned to add fractions when we were 8, we have to have a ‘common denominator’ when we add models together.  I call this calibration, i.e. the art and science of creating a common denominator among models in order to combine and make sense of them.

Calibration

Why do we need to calibrate?  Because trying to analyse vast amounts of the same type of information only increases information overload.  It is a key tenent of Knowledge Management that increasing variation decreases overload.

It is a key tenent of Knowledge Management that increasing variation decreases overload.

We know this to be intuitively correct.  We know that staring at reams and reams of data on a spreadsheet will not lead to an epiphany.  The clouds will not part and the trumpets will not blare and no shepherd in the sky will point the right way.  Overload and confusion occurs when one has too much of the same kind of information.  Making sense of something requires more variety.  In fact, overload only increases puzzlement due to the amount of uncertainty and imprecision in the data.  This, in turn, leads to greater deliberation which then leads to increased emotional arousal.  The ensuing ‘management hysteria’ is all too easily recognisable.  It leads to much more cost growth as senior management spend time and energy trying to make sense of a problem and it also leads to further strategic risk and lost opportunity as these same people don’t do their own jobs whilst trying to make sense of it.

De-Mystifying

In order to make sense, therefore, we need to aggregate and analyse disparate, calibrated models.  In other words, we need to look at the information from a variety of different perspectives through a variety of lenses.  The notion that IT companies would have us believe, that we can simply pour a load of wild data into a big tech hopper and have it spit out answers like some modern Delphic oracle is absurd.

The notion that IT companies would have us believe, that we can simply pour a load of wild data into a big tech hopper and have it spit out answers like some modern Delphic oracle is absurd.

Information still needs a lot of structural similarity if it’s to be calibrated and analysed by both technology and our own brains.

The diagram below gives an outline as to how this is done but it is only part of the equation.  Once the data is analysed and valid inferences are made then we still are only partially on our way to better understanding.  We still need those inferences to be contextualised and explained back to us in order for the answers to crystalise.  For example, in our model of a bridge, we may make valid inferences of engineering problems based on a detailed analysis of the schedule and the Earned Value but we still don’t know it that’s correct.

Storytelling

As an accountant or lawyer, therefore, in order to make sense of the technical risks we need the engineers to play back our inferences in our own language.  The easiest way to do this is through storytelling.  Storytelling is a new take on an old phenomenon.  It is the rediscovery of possibly the oldest practice of knowledge management – a practice which has come to the fore out of necessity and due to the abysmal failure of IT in this field.

Scenario-Based Model Development copy

Using our diagram above in our fictitious example, we can see how the Legal and Finance teams, armed with new analysis-based  information, seek to understand how the programme may be recovered.   They themselves have nowhere near enough contextual information or technical understanding of either the makeup or execution of such a complex programme but they do know it isn’t going according to plan.

So, with new analysis they engage the Project Managers in a series of detailed conversations whereby the technical experts tell their ‘stories’ of how they intend to right-side the ailing project.

Notice the key differentiator between a bedtime story and a business story – DETAIL!  Asking a broad generalised question typically elicits a stormy response.  Being non-specific is either adversarial or leaves too much room to evade the question altogether.  Engaging in specific narratives around particular scenarios (backed up by their S-curves) forces the managers to contextualise the right information in the right way.

From an organisational perspective, specific scenario-based storytelling forces manages into a positive, inquistive and non-adversarial narrative on how they are going to make things work without having to painfully translate technical data.  Done right, scenario based modelling is an ideal way to squeeze the most out of human capital without massive IT spends.

 

 

 

 

 

Give Me Back My Silo! The problems with cross-functional collaboration Reply

Collaboration requires trust.  Collaboration often requires risk with new relationships.  Collaboration requires doing something new.  In short, people do not like to collaborate.  People do not like to share.  People like safe relationships with others from the same educational background.  They collaborate with those who  share the same problem solving paradigms, issue identification and decision making criteria.  Knowledge and knowledge-intensive work is intensely hierarchical.  People guard their secrets and their weaknesses.  So, although the business may look towards de-layered flexible working structures as a cost saving measure, people do not necessarily follow.  Knowledge is and has always been a powerful means to embed and entrench power within an organisational hierarchy. 

Collaboration, however, is worth money.  In 1969 Peter Drucker noted that sharing and managing knowledge is “essential to organisational success” because it ensures sustainable competitive advantage.  How then do businesses best help employees engage and collaborate in a meaningful way which creates business value?quopte

Larry Prusak notes that large organisations performing complex tasks have been around since about 1860.  So far the corporate community has had over 160 years to solve this problem and we seem no nearer to it.  He posits that it seems so hard because, essentially, it is not possible.  There is no science behind it only heuristics.  Solutions are not algorithmic but rather anecdotally commonsensical.

quopte

The problem is that cross-functional collaboration is counter-intuitive.  It is not a normal feeling to share intra-discipline information with other functions around the business.  Complex ideas are not easily understood or translated outside professional groups.  Geologists and pharmacists can only explain an important discovery if it has immediately recognisable business value.  Lawyers can only explain the value of an idea if it averts imminent loss.  Manufacturers articulate the value of a process where it creates savings or improves revenue.  Everything else is esoteric gibberish. 

Thought leaders such as Prusak and Drucker well note that the answer to the standard problems of intra-disciplinary collaboration is to create well supported Communities-of-Practices (CoP).  Practices, they note, are best kept to about 200 members who meet about 2-3 times per year.  In the diagram below, such CoPs may extend beyond the walls of the organisation and may even include other competitors. 

To misquote Shoeless Joe Jackson in “Field of Dreams:  ‘Build it and they will not necessarily come.’  Increasing networks and their IT support will not necessarily produce any tangible return.  Most likely it will needlessly absorb organisational time and money only to increase the personal fiefdoms and create further bottlenecks and over-centralisation.  Such networks will help to increase the volume of knowledge within an organisation and problem solving but, critically, it will not help convert it it into business value.  In order to realise business value knowledge must cross functional boundaries.   

xFunctional Collaboration

GOVERNANCE & WORKFLOW

Knowledge will flow relatively freely within disciplines.  CoPs  address the problem of collaboration for such knowledge generation and problem solving.   Knowledge does, however, need to be forced across functional boundaries.  Commercial teams will not be drawn to good ideas.  They will not recognise them.  Workflows are essential to implement collaboration across organisational functions.  The key to implementing cross-functional (as opposed to hierarchical) workflows is to embed them in governance.  People will collaborate across functions if they cannot achieve their goals or get their work done.  The difficulty with any governance, however, is making sure that these ‘gates’ do not become bottlenecks.  Although the onus may be on the professions to present their work for approvals, so to is there a burden on the executive silos to understand and approve in a timely manner.  In this way there should be no burden on the operational disciplines to present their work on an ad hoc basis.  The presentational form must be agreed between professional and executive branches to understand.  There is no sense in letting commercial elements of the business dumb down sophisticated ideas.   Only when both parts of the organisation come together in mutual understanding is there truly any sense of collaboration across functions.

In the end trust will always trump value when it comes to the exchange of knowledge.   Indeed, businesses must actually increase organisational silos and insulate them rather than fight them.   The solution is not to break down the silos but to build them up.  People like safe relationships.  They like to feel warm and closeted from ‘outsiders’.  The key is to increase their sense of importance through revenue generating communities of practice in order to increase the volume of knowledge in an organisation.  Only then should the business increase the pace of converting knowledge to revenue through cross-functional workflows strictly embedded in the corporate governance.

Hidden Costs in ICT Outsourcing Contracts Reply

hidden-costs

Why are IT outsourcing contracts almost always delivered over-budget and over-schedule?  Why do IT outsourcing contracts almost always fail to achieve their planned value? How come IT contracts seem to be afflicted with this curse more than any other area?

Quote

The common answer is that (i) the requirements change,  and (ii) that handovers from the pre-contractual phase to in-service management are always done poorly.  These are both true although hardly explain the complexity of the situation.  If requirements change were an issue then freezing requirements would solve it – it doesn’t.  The complexity of large ICT projects is derived directly from the fact that not all the requirements are even knowable from the outset.  This high level of unknown-unknowns, coupled with the inherent interdependence of business and system requirements, means that requirements creep is not only likely but inevitable.  Secondly, (ii) handover issues should be able to be solved by unpicking the architecture and going back to the issue points.  This too is never so simple.  My own research has shown that the problem is not in the handover but that the subtleties and complexities of the project architecture is not usually pulled through into the management and delivery structures.  Simply put, it is one thing to design an elegant IT architecture.  It is another thing entirely to design it to be managed well over a number of years.  Such management requires a range of new elements and concepts that never exist in architectural design.

The primary factor contributing to excessive cost (including from schedule overrun) is poor financial modelling.  Simply put, the hidden costs were never uncovered in the first place.  Most cost models are developed by finance teams and uncover the hard costs of the project.  There are, overall however, a total of 3 cost areas which must be addressed in order to determine the true cost of it outsourcing. 

True Cost of IT

1.  Hard costs.  This is the easy stuff to count; the tangibles.  These are the standard costs, the costs of licensing, hardware, software etc.  It is not just the obvious but also includes change management (communications and training).  The Purchasor of the services should be very careful to build the most comprehensive cost model based on a detailed breakdown of the project structure, ensuring that all the relevant teams input costing details as appropriate.

2.  Soft Costs.  The construction industry, for instance, has been building things for over 10,000 years.  With this level of maturity one would imagine that soft costs would be well understood.  They are not.  With project costs in an extremely mature sector often spiralling out of proportion it is easy to see that this might also afflict the technology sector which is wildly different almost from year to year. 

Soft costs deal with the stuff that is difficult to cost; the intangibles:  The cost of information as well as process and transaction costs.  These costs are largely determined by the ratio of revenue (or budget in terms of government departments) against the Sales, General & Administration costs, i.e. the value of the use of information towards the business.  Note that this information is not already counted in the cost-of-goods-sold for specific transactions.

Soft costs go to the very heart of how a business/government department manages its information.  Are processes performed by workers on high pay-bands?  Are workflows long and convoluted?  The answers to these questions have an exponential effect on the cost of doing business in an information-centric organisation.  Indeed, even though the cost of computing hardware is decreasing, the real cost of information work – labour – is increasing.  This is not just a function of indexed costs but also the advent of increasing accreditation and institutionalisation in the knowledge worker community.  Firstly, there is greater tertiary education for knowledge work which has hitherto been unaccounted for or part of an external function.  The rise of the Business Analyst, the Enterprise Architect (and a plethora of other “architects”) all serve to drive delivery costs much higher.  Not only are the costs of this labour increasing but the labour is now institutionalised, i.e. its place and value is not questioned – despite the data showing there seems to be limited economic value added through these services (i.e. no great improvement in industry delivery costs).

3.  Project Costs.  Projects are never delivered according to plan.  Requirements are interpreted differently, the cohesion of the stakeholder team can adversely impact the management of the project, even the sheer size and complexity of the project can baffle and bewilder the most competent of teams.  Supply chain visibility, complicated security implementations and difficult management structures all add to project friction and management drag.  There are many more factors which may have an adverse or favourable effect on the cost of performing projects. 

IT Transition Cost Graph

In the Defence community, Ph.D student Ricardo Valerdi created a cost model – COSYSMO – which isolated 14 separate factors peculiar to systems engineering projects  and gave these factors cost coefficients in a cost model.  Ultimately, each factor may be scored and the scoring then determines the effort multiplier, usually a number between approximately 0.6 and 1.8.  Naturally, when all factors are taken into account the overall effect on the contract price is significant. 

More importantly, for IT implementations, the “project” is not short.  IT outsourcing projects are generally split into 2 phases:  Transition and Transformation.  Transition involves what outsourcers call “shift-and-lift” or the removal of the data centres from the customer site and rear-basing or disposal of the hardware which allows the company to realise significant cost savings on office space. 

During the second phase – Transformation – the business seeks to realise the financial benefits of outsourcing.  Here, a myriad of small projects are set about in order to change the way a business operates and thereby realise the cost benefits of computer-based work, i.e. faster processes from a reduced headcount and better processes which are performed by workers on a lower pay-band. 

IT outsourcing  is not just about the boxes and wires.  It involves all the systems, hard and soft, the people, processes and data which enable the business to derive value from its information.  Just finding all of these moving parts is a difficult task let alone throwing the whole bag of machinery over the fence to an outsourcing provider.   To continue the metaphor, if the linkages between the Purchasor and the Vendor are not maintained then the business will not work.  More importantly, certain elements will need to be rebuilt on the Purchasor’s side of this metaphorical fence, thus only serving to increase costs overall.  The financial modelling which takes into account all of these people, processes and systems must, therefore, be exceptional if an outsourcing deal is to survive.

CIOs as Storytellers? Reply

In a recent article in online magazine CIO & Leader Chris Potts argues that technology has come so far that CIOs need to start to take the lead and help businesses move beyond the antiquated structures of yesterday.  He says that CIOs need to tell a story of how the business could be, how it should be.  He says that CIOs are uniquely equipped with the technological mindset to tell the story of the business of the future.

Picture1

In  recent tweet I was harsh on Chris but in hindsight I believe I need to be more brutal.  The world does not go round for a lack of dreams.  Businesses are not short on vision.  What is lacking is execution.  Projects do not fail for want of strategic intent, they fail for want of expert systems engineering and expertise in engineering systems.  This means that an enterprise doesn’t only need good technical expertise in their horizontal functions but they need expertise in the methodology which carries that knowledge as it passes through the market verticals.  This is to say that it is fine to be a good project manager but can you manage the project from market analysis through to business development?  Can you manage the project through the architecture? Through to contract close out?   

None of this relies on telling stories.  These is deep technical expertise.  Storytelling shouldn’t be ignored.  One of my all-time favourite authors, Larry Prusak, is a huge believer in storytelling as a means for engagement and building up a common picture of knowledge.  A sort of inherited reference point for change.  As important as storytelling is, it is becoming a fad and a distraction for executives.  By focusing on storytelling they are ignoring the real complexity hidden in projects.

Benefits-Led Contracting: no immediate future for outcome based agreements Reply

The IACCM rightly points out that key supplier relationships underpinned by robust and comprehensible contracts are essential to the implementation of significant strategic change.  Their research identifies a 9.2% impact on bottom line from contract weakness.  Top 5 causes being:

  •      Disagreement over contract scope,
  •      Weaknesses in contract change management,
  •      Performance failures due to over commitment,
  •      Performance issues due to disagreement over what was committed,
  •      Inappropriate contract structures or responsibilities.

Two things are given in this mess:  (i) Firstly, that contractual structures are weak and inappropriate to deal with high levels of operational complexity and technical risk, and (ii) secondly, that legal means of enforcement are cumbersome, expensive and ineffective.

That business is ready to solve this legal problem by contracting for outcomes is (a) nonsense and (b) missing the point.  Business is already dealing with the operational and technical risk of large and complex contracts.  Business is already structuring many of its agreements to deal with outcomes.  Large prime contracts,  alliance contracts and performance-based contracts are already commonplace in PFI/PPP and Defence sector deals.  That neither are wholly efficient or effective is for another time.  It is, however, for the legal community to devise more sophisticated ways of contracting in order to solve their side of the problem.

Picture1

PEOPLE ARE THE KEY

The primary reason for not being able to contract for outcomes is that the vendor doesn’t own the people.  This is critical because without the ability to control and intervene in the delivery of work the risk increases exponentially.  Consequently, the risk premium paid for outcome-based contracts will either make them (a) prohibitively expensive, or (b) impossible to perform (within parameters).  So, a business which offers you an outcome-based contract is either having you on or just about to charge you the earth.

 

 

Business Capability: creating a modular information supply chain through selctive outsourcing 2

The chart below only serves to prove Paul Strassman’s mantra that outsourcing is more an emetic than a cure.  By and large the following is true:

  1. Outsourcing is a financial decision and not a business one.
  2. Companies engaging in heavy outsourcing activity are overall commercial losers.
  3. Financial gains from outsourcing are usually mythical as per user costs usually increase from declines in overall employment.
  4. The only financial gains from outsourcing are usually short term wins on the stock markets. 

Large scale outsourcing of the IT function weakens corporate productivity by lessening flexibility at a time where the company must create additional agility in order to survive.  The heavier the outsourcing activity the more likely the business is to lose its information management function, i.e. the  ability access information (which now largely resides under vendor SLAs), package and use it quickly and effectively is now gone.

The secret to IT outsourcing is to (a) commoditised and (b) focus on capability.  Firstly, businesses should not even have to think about infrastructure.  There are very few arguments to retaining one’s own data centre.  IT infrastructure and even network monitoring and optimisation are highly commoditised product offerings with very low risk.   Just do it.

Secondly, focus on capability.   Understand where technology creates value in your business.  Focus on increasing the productivity (and reducing costs) of those areas of opportunity by packaging modular information offerings from high-end suppliers.  For instance, some outsourcing companies specialise in data analytics and BI.  Some specialise in risk analysis and some specialise in service-based client messaging.  Start to build these services – all of which can be done better and cheaper by outsourcing firms  – and begin to build them into a client narrative which allows your business to penetrate deeper into the middle and front offices.  This is just an example but it highlights the fact that if your company has a modular information supply chain you have the agility to create great, differentiated service offering based on real customer value. 

Be careful what you outsource.  Get to grips with business complexity (it’s here to stay) and don’t derogate from your business responsibility to information management.

INFOGRAPHICS: the worst form of risk management Reply

Aristotle wrote that “metaphor is the worst form of argument.  He’s right.  If you have something to show/prove, then do so precisely and in a way which is meaningful and useful to your target audience. 

Recently the guys at Innovation of Risk posted an article on the use of infographics to analyse risk.  I don’t know who coined the term “PowerPoint Engineering” but most infographics fit neatly into this category.  Infographics can save presentation or they can sink it but mostly they are used to convey ill conceived and poorly thought out ideas which snowball into worse run projects.  The best advice is to take these bath-tub moments (why do people think they have great ideas when they’re washing?) and run the analysis with an expert using an expert system.  If you can’t do that then (a) you’re in the wrong department for having the idea in the first place, and (b) chances are that there is a tonne of minute but important detail you missed out.

Whilst I think that visual display of graphics is vital to achieve stakeholder buy-in, it is also clear that imprecise PPT-engineering masquerading as infographics is the worst form of management snake-oil there is.  An erstwhile systems engineering mentor of mine used to say, “if you think they’re BS’ing you then ask them what the arrows mean”.  9 times out of 10 they won’t have a clue. 

Competitive Advantage in IT 1

Although a recent article in SearchCIO alludes to competitive advantage by IT departments, arguments like this can take the CIO down a dangerous road.  The holy grail of many CIOs is to run a department which is both profitable and also increases business capability.  Mostly, however, IT departments are costly and the subject of constant complaint.

Can IT ever be a profit centre?

Economists have long argued that businesses should strip away overhead (i.e. not included in the cost of goods sold but pure overhead) cost chargebacks from business verticals and their processes in order to gain a clearer view of what is profitable and what is not.  If they don’t then smaller, profitable processes are often in danger of being swamped with overhead.  In this way, many businesses often outsource or cut the wrong activities.

It is notoriously difficult to cost IT chargebacks so that market verticals are charged just the right overhead.  Should businesses charge their verticals for email?  They often do but isn’t this just a cost of business that the centre should absorb?  Isn’t the burden of communication and reporting largely placed onto verticals anyway?  So if they could run their business units in a more entrepreneurial way wouldn’t the cost of IT be significantly reduced? 

What if we extend that argument and let IT be a profit centre?  Why don’t we let business units find cheaper ways of doing business and compete with the IT department?  Security/integration/management time arguments aside – it is likely that if IT departments were able to charge for the thing they were really good at, this would be a source of competitive advantage within the business.

So, there is a good reason why IT departments aren’t profit centres but, of course, this doesn’t solve the problem of the high cost of IT inside business.

Cloud research exposes gaps between CIOs and the business. . .again Reply

In a recent article for Beyond IT Failure Michael Krigsman highlights the colossal disconnect between IT and the business.  Looking at the graph below has IT really spun off at a tangent?  Is IT just pursuing its pet projects again?

IT is not wrong.  IT is best placed to understand compliance requirements.  IT should understand which applications delivery value for money and IT should be able to choose which apps support competitive advantage.  Cloud is, by and large, a non-functional requirement as so does not need to be in the functional user spec.

“Business is not a toy shop and the argument “but I’ve got it on my phone” does not wash in a secure, structured enterprise environment.”

So why the disparity between what what the business thinks it needs and what IT choses?

  1. IT is a cost centre.   IT is responsible for delivering functionality in the most cost effective way.  Business is not a toy shop and the argument “but I’ve got it on my phone” does not wash in a secure, enterprise environment.
  2. Business Requirements.  I have never met a business vertical which understood its requirements.  Requirements engineering for the systematic design of accurate software is an entire segment of the tech industry.  It is complex and (mostly) poorly done.  Invest in getting it right if you want to deliver better systems.
  3. Engagement.  There is no two ways about it – IT is appalling at business engagement and business are shockingly bad at letting IT in and then articulating their needs (in order to begin the requirements process.
  4. Productivity.  Improved productivity is more of a human problem than a technological one.  New software will not make people smarter.  Unless the processes and collaboration structures already exist then new binary systems will only serve to compound the problem.  In such cases, software procurement becomes a very, very expensive process of sandboxing and prototyping to elicit accurate business requirements.

In order to achieve better ROI on tech investments whilst still delivering great software which improves productivity, businesses need to (a) understand where tech enables business capability in their value chains, (b) understand the development of their business’ capabilities, and (c)  create a ‘value ladder’ which supports the parallel propositions of architectural development and business productivity.

Getting Rid of the Help Desk–a structured approach to KM 1

In a recent article in CIO magazine Tom Kaneshige argues that the rise of BYOD spells the demise of the traditional Help Desk.  He intimates that BYOD has now been overtaken by BYOS – bring-your-own-support!  The network-enabled user, with access to huge volumes of information, requires a new Help Desk. 

He is right that, ultimately, power-users need better, faster support delivered to them in a format and by people with a deeper understanding of the context and with more intricate solutions.

BYOS is the exception and not the rule. 

Although the IT function is becoming more commoditised, the larger fields of knowledge work isn’t, hasn’t and won’t be commoditised anytime just yet.  Otherwise, any 12 year old with a laptop would be in with a chance.  Help Desks don’t need to be expanded but they do need to become more mature, agile and integrated into the KM procedures of modern networked enterprises (ie those businesses with a heavy KM focus).  Expanding the remit of the Help Desk opens the door for colossal cost increases.  Internal knowledge management functions need to become more structured beyond simplistic portals.

INTERNAL KNOWLEDGE MANAGEMENT

In a recent article in McKinsey Quarterly, Tom Davenport argues that organisations need to get a lot smarter in their approaches to supporting knowledge workers.  He says that greater use of social media and internet use will harm the business more than help it.  Lower level knowledge workers need more structured support to their processes.  On the other hand, high-level knowledge workers are better supported by an open platform of tools.  Getting the right balance is as much art as science.

BYOS is the wrong approach.  It’s a derogation of KM responsibilities.  Organisations need to focus on an approach to KM with the following structures:

  1. A good Help Desk function for knowledge workers involved in highly structured processes.
  2. An IT function which supports a flexible arrangement of tools for advanced knowledge workers.
  3. Knowledge Managers:  people who provide the focal point for certain areas of knowledge.
  4. Portals:  A single entry point for people seeking access to communities of interest.

So, be careful when thinking about Tom Kaneshige’s advice and “blowing up” your Help Desk.  IT can be a self-licking lollipop.  More tools and more information won’t necessarily improve productivity.  At the lower level, sometimes it makes more economic sense to support the process.  It’s only at the upper levels of expertise that it is more profitable to support the person.