One of the most significant projects I worked on (as project manager and KM consultant) whilst at Unisys was the portal for housing all the main sales and delivery assets for use by the sales, bid and delivery teams within the company.
The project was an undoubted success and transformed the way the company's critical assets in this area were created, published, managed and used. It was also one of the most effective and visible examples of the "One Unisys" ethos which the company's executives were promoting at the time.
A related Six-Sigma Lean project used two approaches to estimate the benefits in monetary terms, and found them to be $1.4 million p.a. and $1.7 million p.a.
The core team varied in size but was usually around 10 people (excluding Sponsors and Steering Committee) covering 5-8 workstreams.
Team members included a number of SSL Black Belts, long-standing Unisys employees who had a deep understanding of the corporate dynamics across the different divisions (this was critical to project's success), highly talented and dedicated technical developers, user-interface designers and offshore developers.
However, the extended team was significantly larger than that and some (virtual) project meetings had 20 - 30 attendees. The main reason for that was the need to work with content owners in all the company divisions. In addition, this project overlapped with several other initiatives for managing cross-divisional content (for example - assets covering the use of the company methodologies during the delivery phase), and there was a constant need to define and monitor the scope and agree on standards and methods of integration where appropriate. In some cases, we absorbed those other projects.
Stakeholder management was a major part of the project from the outset. During the initial SSL project that gave rise to it, we interviewed 114 stakeholders and surveyed 656 bid and delivery personnel - representative of the core user base.
One of many challenges we faced was the perception that we were encroaching on other peoples' territory: these people being the ones we needed to work with as content owners and content managers. The corporate dynamics in Unisys were strongly aligned with the divisional structures - and the management of the corporate sales and delivery assets reflected this.
The promotion of the One Unisys ethos was aimed at overcoming this silo mind-set - and we were in the front line of the battle. In the early stages of the project there was clear antagonism and skepticism in some quarters, with a reluctance to cooperate. However, as the project progressed there was a total turn-around, and in the end there was almost universal support and enthusiastic cooperation. The reasons for this turn around were:
Our ability to demonstrate the live portal running with the initial content: its user interface, navigation, and integration of multiple types of content were all significantly better than that of the divisional portals
The realization that this was becoming the "one place to go" for all sales and delivery content: the strongest message we received from our survey was that people were confused about where to go to find content - there were simply too many portals. Although at first we were regarded as adding to that problem, once it became clear that other portals were being decommissioned, we were seen as the only solution.
The fact that we were introducing formal and properly-defined content management process as part of a wider Portal Governance initiative (instigated by the KM Team)
Our policy of having regular meetings - which gradually strengthened the relationships, improved confidence and constantly reinforced the One Unisys ethos: in the end, we were all working towards a common goal.
As regards the underlying technologies and methods used, we used all of the following at various times:
SharePoint 2003 and then 2007: this was the content management tool for the portal. We also began preparations for transitioning to SharePoint 2010
A form of Agile project management (where appropriate)
SharePoint Team Spaces: we used Team Spaces quite extensively. I configured various spaces for a variety of purposes, including:
Task Management and Tracking
Issue Management
Feature and Requirements Management
Meeting Workspaces
Although I have described this as a single project, in fact it was a number of overlapping projects. The vision of "one place to go for all Unisys sales and delivery assets" emerged as a corporate consensus over time.
Although the KM Team and the core project members saw very early on that this was not only desirable but ultimately inevitable, it only became possible to agree it as a formal objective as a result of various reorganizations and the release of the first version - which showed not just the practice (which was well-received), but also the principle of cross-divisional collaboration.
The project raised a great many challenging and interesting issues, some of which I will write up in other posts. They included:
Creating a model of roles and responsibilities for managing content on the operational portal: this turned out to be a much more complex model than anyone expected. The challenge was converting this into something practical.
Implementing the idea of Authoritative Content to which a rigorous and formal content management process was to be applied.
Recognizing the need to allow for, and somehow integrate, non-authoritative, informal content: many portal users could potentially also be contributors of content - they were keen and willing to share their documents widely.
The difficulty of getting an ongoing true insight into the value of the portal (as seen by the users) and the scenarios in which it was used.
Defining a common structure and terminology: e.g. "solutions", "services", "offerings" - and the number of levels of offerings/sub-offerings to be allowed for.
Balancing the need to make content quickly and easily available, for rapid access and use, with the requirement to facilitate and encourage person-to-person communication: often, people would only feel confident about using assets after talking with the relevant content owners.
Managing scope creep: as mentioned above, in some cases, this meant encouraging scope creep in order to move towards the goal of One Place To Go.
In summary - this was a large, complex project in one of the most critical areas of content management for the company. It's success was undoubtedly due to the excellence of the project team.
I personally found it a hugely rewarding experience and am proud of the team's achievement. I now regard myself as an expert in the domain of "managing enterprise-wide sales and delivery assets". Previously, I would have regarded this as a relatively straightforward topic, but I now understand the depth of the complexities - and there's enough there to fill a book!
Role-call of some team members (names to be added as I get their permission):
Things have moved on a long way since I first started using SharePoint (that was SharePoint 2003, not SharePoint 2010 !). And even that was the THIRD portal technology.
Obviously the technology has advanced hugely, but so has the recognition of the importance of Portal Governance – along with the availability of guidelines and templates for defining governance.
[Governance, by the way, deals with issues such as ownership, permissions, site creation rules, maintenance, support, de-commissioning, content management etc. etc.]
When I first experienced SharePoint – even in those early days – my initial reaction was: “Wow! This is amazing! It’s so easy to create sites/post content!” And then my second reaction was: “Oh dear! This is awful! It’s too easy to create sites/post content!”
I could see both the benefits and drawbacks of this undoubted jump in ease of use.
Suddenly, we no longer had a relatively simple split of roles into two categories (producers vs. consumers). Now, if we were to manage the possible chaos that could arise by allowing unfettered access to too much functionality, we had to consider a whole spectrum of categories
- who decides where sites can be created
- who decides what they can look like and what features they can have
- who can create sites (actually)
- who can determine what sites are created
- who can manage content (actually)
- who can decide what and how content is managed
- who can access sites – and with what permissions
… along with managing the training of the different roles, and defining the processes (which may be federated down a hierarchy of organizational structures).
All this may seem obvious to current SharePoint implementers, but back then, there was little realization of quite how complex these governance processes could become – or needed to be. And there was little guidance available.
In those early days, people would put up a portal and then, retrospectively – when the ***t hit the fan – go back and put some form of governance process in place.
Nowadays, SharePoint implementers, at least, understand that these are very important issues and can call on guidance and templates to help them help their users.
And in theory, at least, they can get the goverance sorted out right from the start.
But that doesn’t mean the problem has been solved. Far from it!
Firstly:
These governance processes can become very complex, and the number of roles can mushroom. Many organizations are simply not sufficiently process- or systems-oriented to be able to cope with such processes – or even to fully appreciate the need for them.
Secondly:
When issues of content ownership and responsibility are raised, that may (not always) uncover ambiguities, inconsistencies, power-plays and internal politics. These have to be resolved, one way or another.
Thirdly – and most importantly
Many of the decisions that go into a governance plan are intimately connected to the company culture. Is control heavily centralized, or are divisions, groups, and individuals more autonomous? Does the company have a history of imposing processes from the centre? Are such centralized processes actually followed in practice? Is information freely available by default (with sensitive information being protected), or is information hidden by default and only made available in a need-to-know basis? How uniform is this culture across the company? Does it vary from country to country / division to division?
So, governance has to be front and centre of any portal project, and discussed right from the very start.
It has to be kept to a level of complexity which the organization will accept: not just to sign off on, but to follow-through on. That’s a hard judgement call, and the implementers need to be sensitive to this and offer helpful guidance.
Issues related to content ownership have to be sorted out without any ambiguity.
And finally, how to deal with corporate culture?
Without a doubt, certain types of culture will get more benefit from a portal than others. But cultures can’t be changed easily. So the people involved in helping the company draw up its governance plan have a very difficult task.
They need to grasp the nature of the corporate culture as it is – almost certainly without the benefit of an in-depth study. And they need to understand the major stakeholders and the influence they have over how the culture could evolve (positively or negatively). Installing a Portal CAN influence the company culture, under the right circumstances, and if done with proper understanding.
And with all this largely unarticulated and undocumented background insight, the portal implementers need to guide the creation of a governance plan that is “appropriate” to the organization.
Getting the technology and infrastructure right will ensure that something tangible gets delivered.
With that assured,
Getting the governance right is the only hope of meeting the business needs – which ALSO need to align with corporate culture.
I hope you didn’t expect this to be a matter of spending half an hour with the project champion and ticking a few boxes!
Intelligence is clearly very important for effective performance. And so is knowing the right things: knowledge and memory.
But as we all know from personal experience and observation there are many other factors required for effective performance – Emotional Intelligence being one of the most referenced critical competencies.
However there is a collection of other competencies that no one would argue are not also critical for effective performance. These include:
Future planning
Staying focused
Goal setting
Creativity
Overriding and suppressing unacceptable social responses
What is interesting is where I came up with this list of competences. In fact, they are the mental capabilities for which the frontal lobe area of the brain is largely responsible.
The frontal lobes have nothing to do with intelligence or memory but everything to do with how we use our intelligence and knowledge.
The frontal lobes area is the most highly evolved area of the brian and the last area to develop in children.
Here are some quotes from the video below:
“Frontal lobes is an executive brain area that is responsible for
integrating information that comes from many different brain systems
into a purposeful plan of behaviour, anticipating the future, making
critical judgements, being able to survey a situation to juggle ideas
and choose which idea is most likely to have implications for the
future”
“Without the frontal lobes we are at the mercy of our environment, we
response to events without reflection, we are unable to plan for our
futures.”
Since these abilities appear to be localised to a particular area of the brain – and one which is the most recently evolved and which most distinguishes us from other mammals – does this suggest that these capabilities have something in common? And if so, perhaps there is something important we can deduce from this about how our higher cognitive functions work.
This might even lead to a name for this generic mental activity.
This topic could take up a full-length book, but in this blog post I want to highlight some of the common mistakes made by people who design learning system for sharing their knowledge with others. In many cases, although the designers of these learning system have great expertise in their particular domain, they are relative novices when it comes to designing learning systems.
A simple model of the types of knowledge is:
Concepts
Skills
Expertise
A simple model for the types of learning is:
Education
Training
Operations
In some cases learning systems are so poorly designed that they mix up education, training and operations. In other cases, the educational aspect is deliberately ignored and turned into a benefit statement such as “No Theory Here! Just Practical Step-By-Step Instructions!” And sometimes the merging of training and operations is turned into a benefit with statements such as “Learn on the Job!”.
Below, I look each of the types of learning in turn and explain why they need to be clearly differentiated. Differentiating them doesn’t necessarily mean they have to be delivered sequentially – although that would be the norm. It does mean that as a designer of a learning system you need to be very clear what type of learning you are providing at each point in the learning process.
Education
The educational component is essential because that is where the fundamentals and Concepts are explained. If you don’t understand the concepts then your learning is extremely brittle. That means that if you get at all stuck or veer off the step-by-step sequence even slightly, you have no way of helping yourself recover. It also means that your learning is stunted because you cannot learn new things on your own without understanding the basic concepts.
Part of the educational component is to make available to the learner a glossary where terminology is defined and concepts are explained. As a learner, what you want to be able to do is very quickly to access any term during any part of the learning process. Ideally, you don’t want to be presented with the full glossary and a full set of concepts right at the beginning of your learning process (unless you explicitly request that). Rather, you want to see just those terms or concepts that you have already been introduced to so that you can remind yourself of their meaning.
You also don’t want to be presented with very complex definitions of terms until and unless you need to understand that complexity. What you often want is a definition that is simple enough to be meaningful at your current stage of learning without necessarily being 100% accurate or complete. An “incremental glossary” allows the complexity of the definition of the terms to be adjusted in this way.
Training
Training is where Skills are learned and Concepts are internalised and much more fully understood.
Although there are occasions when it is acceptable to be trained on the job, it is often much more effective to go through a separate training process.
As a learner, if you know that what you are doing is “for real” (i.e. you are in Operations), then you are likely to take too much time over trying to get every part of it right instead of doing it quickly, making mistakes, and learning from those mistakes. In fact the importance of training can be summarised as “learning from mistakes in a safe environment”, and learning from mistakes is probably one of the fastest ways to learn.
Operations
Operations is where you are applying what you have learned in a live environment. There are two points to raise in connection with this.
The first is the rather obvious fact that learning doesn’t stop at the end of the formal education and training process, but continues during operations. Many things are learned during operations, but the most critical is what I call Judgement. And this brings me back to the creation of step-by-step guides and methodologies.
When people write methodologies or step-by-step guides, they usually start with the assumption that everything can be explained adequately provided enough detail is included. Too often there is an unstated implication that the methodology or guide will turn a novice into an expert.
But that can never be the case, and it’s naive and unhelpful to think that way.
For any significant topic – and certainly for any topic for which someone could claim to be an expert – there are certain points within the method or the step by step guide at which judgement is required.
Almost by definition, judgement is something that can never be written down and made explicit. Judgement is something that can only be learnt through sufficient practice. This is also referred to as tacit knowledge or expertise.
If you’re learning a new subject, it’s extremely helpful to know at exactly what points judgement is needed. The last thing you want is for this to be hidden from you and not made explicit in the guidance. If it is not made explicit, you’ll find yourself struggling or coming to wrong conclusions or getting completely lost – and you’ll think it’s because you haven’t understood something. In fact, if you were told exactly where expert judgement is needed, you’ll know exactly when you need to ask for Help. And you’ll also know which parts of the process you need to experience often enough to be able to acquire the ability to make judgements for yourself.
The second point concerning Operations is the provision of space and Operations Manual process guide. As a designer of a learning system, the best that you can do is to provide a generic operations manual. This should not include any education or training, but should be written on the assumption that the user has undergone education and training. However for any live operating environment, and operations manual would need to be tailored to fit in with that specific environment.
This is something that is rarely made clear by learning system providers.
Lori Wizdo, Rob Taylor, Mike McHugh, Lee Beyer, Barbera Geharty, Ian Farbrother, Susan McCabe, Jim Kane and myself.
This brought back very happy memories of visits Blue Bell (the Unisys headquarters) and working with a very talented team.
The submission was made some years earlier – the process is rather slow – and by the time the patent was approved our thinking had moved on considerably.
The original patent was for CNEM (Community Network Enablement Method), later changed to KNEM (Knowledge Network Enablement Method) when we decided that what we were creating were better described as knowledge networks rather than community networks.
Subsequent to the submission of the patent, my colleague Rob Taylor and I made a significant enhancement to the method by introducing the concept of Components and Functions.
Components are what make up a Knowledge Network. For example, People, Technology, Knowledge etc.
Functions are what a Knowledge Network does. For example: run monthly seminars, provide learning resources, provide facilities for virtual collaboration, etc.
This proved to be a very powerful method both for defining and implementing Knowledge Networks.
