'Communities of Practice' - could they be the solution to better Portal content management ?

[Former Member]

When TransAlta first rolled out its myTransAlta portal to its 2500+ end users back in 2002, the primary objective was to simply create visibility of a corporate intranet solution that would provide an innovative approach to sharing information and completing common tasks. As part of this first rollout, TransAlta implemented the ESS (Employee Self-Service) and MSS (Manager's Self Service) packages without extensive customization to meet the needs of the userbase. These two packages forced the use of additional roles, over and above the out-of-the-box User and Admin roles in the SAP Portal 5.0 product. Those roles were eventually known as Employee and Manager, and were assigned to the ESS and MSS content, respectively. Although, the majority of content was made available to all users, not including consultants - whom the business chose not to include as Portal users, the ESS and MSS packages forced the team to start thinking about a better organization of the portal content based on employee position, business unit, department and/or geographical location. The initial investigation resulted in a proposal of a multitude of roles in the portal to create such a structure, but with a huge price to pay from a Portal performance standpoint. With the portal having to compare each users' id to their associated roles, page rendering times would be exorbitant. As such, the decision to continue with the two roles, as well as a third Executive (for very sensitive, VP level content) role was made.

In the second phase of our Enterprise Portal development, TransAlta focused a great deal on performance tuning, including applying a series of hot fixes and patches to get the myTransAlta portal to the latest patch level of EP5 SP4. Whilst looking for performance improvements, the Portal team did some server load management analysis to investigate how to reduce load time on the portal home page. The exercise resulted in a much faster load time, and a much cleaner home page, with less clutter and more meaningful information to the end users corporate wide. Towards the end of the second phase, the concept of a Community of Practice was introduced to the team. This was a whole new concept that was never researched prior to the inception of the myTransAlta portal. And, as such, the Portal team faced great challenges, first in determining how best to define a Community of Practice, and second how to sell the business users so the team could proceed with applying this new concept in the portal.

In 2003, after considerable research and comparing with other existing portals that had already adopted the COP (or Communities of Practice) approach, the Portal team developed two Communities for the Information Technology and Generation Operations groups. Each had their own look and feel and even unique navigation styles. But, both worked sufficiently to meet the needs of their respective interest groups (or organizational units). From their creation, came 3 new roles - one for the Information Technology group, one for the Generation Operations group and one that included both. Then, a new first level navigation tab was introduced appropriately called 'myCommunity', and underneath that would be the link to the associated community pages. As an initial roll out we provided basic document management as a function of each community, as well as commonly shared links within each community. The intent was to simply introduce the concept and get as much feedback as possible from the respective groups to add additional functionality such as collaboration, training, discussion forums, and quite possibly connectivity to specific SAP functions that related to those communities. Unfortunately, due to the rather complex governance model that exists in TransAlta, none of these additional features have seen the light of day, even though the initial rollout versions of each of these communities are currently in use.

From this, we realized many questions needed to be answered, even before establishing a COP in the portal. First, given an interest group, is there a real need to provide them with a 'private area' in the portal to enable them to do part, if not all of their work ? Then, if the need is apparent, what should that area in the portal comprise - collaborative tools, discussion forums, KM, related training, visual process workflows, and so forth ? Once, this is determined, where is the logical place to create this community in the portal ? Now, let's look at each question carefully. When the Portal team approached a series of different areas in the business to discuss the possibility of creating COP's, no real vision or template existed on what would be provided, from a functionality perspective. So, the onus was left to the business to specify what they would like in their own community. As a result, the Gen Ops page contained only a basic document management solution, and nothing more than that - not exactly rocket science if you ask me. Although this did meet the Generation Operations group's requirements, it had so much potential of having more to offer. So, now that we'd determined the need and the requirements, and the application was built, we needed to create a suitable location for the Gen Ops page in order for it to be easily accessible to the 600+ users who would be its main audience. One approach was to simply link to the content via our existing Business Links iView - that contained links across the whole organization, such as our Benefits service, TransAlta.com and our Corporate Policies. But, the path to navigate to this area was too long, and instead we chose to simply create a new first level navigation tab called 'myCommunity', and place the Gen Ops page there. Then to make this accessible to the appropriate users, we created a role in our portal LDAP and assigned the group of users to the role in our portal that contained the new myCommunity folder and Gen Ops page. The same exercise was used when creating our Information Technology community. And, yet again, without sufficient vision, the end product was a basic document management solution, with some important links.

Our more appropriate approach would have been to build a solution that contained as much as possible common elements that would be available to virtually every community we would intend to create. Then, present this template to the business and proceed from there to create the associated COP, plus any additional custom development for that specific group's needs. So, what should the template for a COP consisted of ? Who would be the content owners of the COP and who would administer that content ? Finally, who ensures proper discipline to ensure the content is kept up to date, relevant to the direction both the group is taking as well as that which is inline with the overall vision of the company ? At this point, it can be easily agreed upon that the whole concept of a COP is ever evolving and unless there is a common understanding of what a COP is and how it would be implemented from a portal perspective, no clear standard can be set, and its sustainment becomes very difficult. I'd like to open this topic to all SDN subscribers to provide their feedback and experiences with implementations they have completed or intend on pursuing. I've personally reached a stage where I can't completely answer the questions I've raised, with any degree of confidence, and as such I feel that quite possibly the COP concept has no real value in our portal. There are more questions that need to be answered, such as what content should remain private and what should be public domain, and is this the approach that is desirable when considering granting access to groups such as consultants, vendors, partners and so forth. I would encourage the folks at SDN to establish a forum around this discussion which I believe will help my team as well as others out there better determine where to go from here, and if there is an alternative approach that would make implementation and support much easier.