All organizations support a variety of systems that can create and contain unstructured information like documents, images, video, audio and other materials.  These items are  used by business users to support functions like sales, marketing, research, or collaboration between various parties.  As a business grows and changes over time it becomes very costly to house, maintain and control each of the dispirit repositories and access their underlying information, as each repository generally provides its own means of control and access.  At one point in time, these solutions were deemed effective for their specific purpose, but ultimately lacked some ability to audit, regulate, version, secure and govern the content that they housed.  Often times these systems were also closed from developer access and their information was only available from a specific application.

There are many benefits of a scalable content management platform like Oracle’s Universal Content Management (UCM), but adoption challenges remain, as people inevitably ask about migration strategies to new tools.  To help reduce the time, cost and effort of migration the following strategy has been highly effective – view existing content items as being an Artifact or a Perishable Content item as outlined below.

Artifact – an artifact is something that must persist within an organization as a point of reference, will not change from its current format and is required or mandated to persist for an extend time.  This might be the 401k retirement guidelines for a given tax year, an annual company report, sales performance figures from a particular year, technical manuals for a specific product version, etc. are good examples of such materials and will at some point be called upon for reference by an end user.

Perishable Content – perishable content rarely needs to persist within an organization, but due to loose governance policies and the speed  at which user-generated content proliferates it is not uncommon for it to live on for years.  Legacy departmental news, sales strategies for products that no longer exist, office lunch menus, materials from defunct business units, materials used for single-point in time collaboration and other items that will never again be accessed by users are all examples of Perishable Content.  At first glance these materials are harmless, but end up cluttering your enterprise with irrelevant information, increasing the time that it takes users to attempt to browse and search for information needed for their tasks.

Strategies
Categorizing content as an Artifact or Perishable content makes it much easier to approach the process of “migration”.  Based on the categorizations we are now left with the following options:

1. Artifact only Migration
Introduce a centralized system like UCM and migrate only Artifacts into the new platform to allow them to be found by users through search and browsing activities.  Leave all Perishable content in its current repositories, to be decommissioned at a future date.

Production of all future Perishable materials should move to the new platform,  but should now be subject to life-cycle guidelines based on the nature of the content that outline how long the content will exist before archival or destruction.  The decommissioned content should still remain available after the cutoff for a specified amount of time, to IT staff or through a self service read-only search.

2. Artifact and Limited Perishable Content Migration
This strategy is more common than the one above.  Move all artifacts into the new content management system, but critically evaluate certain business processes that produce Perishable Content to understand if their production needs to be moved to the central system.  Often times Perishable content is tied with key processes for critical day-to-day business functions that need to be immediately moved to the new platform or continue to reside on the legacy platform with an end date for use defined.  An example of this may be project collaboration documents.

Bringing a new content management system into a business requires not only a technical effort, but also an educational effort around the content creation and management processes that will run on the new platform.  When reviewing the various content types and processes in legacy systems it is important to carefully qualify what will be moved over to the new platform vs discontinued or in some cases persisted in the legacy system.

Results of Migration
By classifying content as Artifacts or Perishable it is possible to pragmatically approach content migration onto a single, enterprise caliber platform in a time and cost efficient manner.  Migrations do not need to be wholesale for value to be gained and with some basic analysis it is possible to quickly understand how various pieces of legacy content should be dealt with.  Post migration IT teams should have a much lower cost of ownership over content within their organization, as now a single, centralized location will exist that can enforce content life-cycle guidelines and allow open access to the materials from a variety of other enterprise systems.

The above mission statements are ultimately empty and provide no guidance or control over the execution of tasks that will take place to fulfil them.

In his book Winning, Jack Welch emphasizes the need to take a pragmatic, no-nonsense approach to mission statement development if any real value is to be gained by it.  Mr Welch states that “Too often, these exercises end with a set of generic platitudes that do nothing but leave employees directionless or cynical. Who doesn’t know of a mission statement that reads something like, “XYZ Company values quality and service,” or, “Such-and-Such Company is customer-driven.” … Give me a break—every decent company espouses these things!”

To make the most out of a project charter’s mission statement it must be meaningful enough to provide business justification, focus the project execution and provide a high level metric to objectify project results.  If developed correctly, a mission statement will act as an excellent compass by which to deliver a successful project.  This is done by clearly defining

As I have written many times on Infotechaligned – the only thing that matters is the ultimate business value that an application is delivering. The most value can be gained from even the most mundane technical solution.

How does one define a great technical solution?  The best technical solutions solve a business problem with the least amount of technical effort.  This includes effort from a full lifecycle standpoint – design, development, implementation, education, operation, maintenance and decommissioning of the solution.  A few years ago I worked with a company that demonstrated this point so clearly that I had to highlight it in this post.

This particular organization lends money to low income families at below market rates to aid them in home purchases.  For a few years they had been using portal technology that from a development standpoint was focused on business users.  This technology required little programming to allow them to further develop their extranet and intranet environments that connected their customers on the lending and purchasing sides of their business.

A need arose within the organization to provide executives with a summary of call activity from their sales team to judge the effectiveness of various calling campaigns.

The IT team spent time deliberating over what course of action to take to solve the business problem.  It was decided that the executives could be best served via a dashboard that would roll up various pieces of performance data around these calls made by the sales team and surface the information via their existing intranet.

The following two options were arrived at assuming that the requirements gathering for the solution was already complete, irrespective of the technical solution

Solution 1

Extend their base CRM system to support tracking this data and develop an integration to aggregate and present the data.  This solution would require the following development efforts

1. Extend the data model of the base system to account for the new reporting needs
2. Develop a presentation layer to gather the relevant information for the business users based on this data model
3. Create a presentation layer to allow executives to view and sort the information
4. Integrate the presentation layer into their intranet
5. Complete a quality assurance cycle on the solution and resolve any issues found with the technological implementation

Solution 2

Use an out of the box – MS Access like – portal component that is already available to capture and present the information.  This solution would require the following development effort

1. Configure the data model and forms relevant for the data collection around the business needs
2. Configure the presentation layer for the end users to expose the required reports

The above comparison might be deemed biased, but it is important to note that in the 2nd solution data would now be entered into two distinct systems by the sales team and the organization will not have complete control over the presentation format beyond a series of basic, caned reports.

After lengthy deliberation the IT team was strongly in favor of using the first solution due to it giving them full control and confining all sales team activity to the CRM system, but estimated the time to completion at around four months of effort.  This effort would detract from having their developers work on core offerings within their extranet to drive business leads to the sales team.  The development and QA time, not to mention possible adjustments that may be needed after an upgrade of the underlying system also added to the overall “cost” of the integration.

The first solution would require around 8 hours of effort to configure and 10 minutes from the sales team each week to summarize their call activity, which would be required regardless of the technical solution selected.  It would be created on top of an out-of-the-box technology and require almost no quality assurance testing, but require the sales team to end their day outside of their CRM system and leverage the intranet for summation of their calls.

In a perfect world we would have the deep integration of the first solution, married with the ease of development within the second solution. Unfortunately that was not feasible and the business team was requesting a solution as soon as possible from IT.

Ultimately the IT team went with the second option.  If more complex needs arose that the configuration based solution could not meet they would have to revisit the solution, but for now they were able to meet 100% of the business needs with this stop-gap effort in a very short time span.  Given the limited effort and accuracy in addressing the problem, this had tremendous positive impact with the business.

This example of success is perhaps one of the most powerful, pragmatic solutions that I have come across in my enterprise software work.  This is an extreme example, but hopefully there might be a space within your organization that allows you to provide this same level of success with minimal effort.  Using simple, configuration-based approaches to development whenever possible is an outstanding way to provide value.  They may at first seem too lightweight and due to their technical ease may be overlooked at first pass by a development staff, but never count them out for their ability to provide a big win for your business teams.

Once within a discussion it is even more important to constrain the volume of each participant if the discussion is going to be effective.  There should be one message and all supporting materials shoudl directly support the main message.

For the purposes of relating the dinner party group discussion to an intranet page, we can continue our example from the “arrival” scenario described above and think of this as a detail page describing expense policies for automobile rentals that was accessed from a page outlining all expenses policies.

The pyramid above illustrates the increased focus that is needed to make a detail type of page effective for the guests.  The supporting information on the page only supports the main point.  Any of the other material generally does not have more detail than a nagivational link to another section of the site.

I hope that the above explanation can help people to convey the importance of contrast in their designs in order to make a guest’s experience as efficient as possible.  For information around prioritizing, organizing content and messaging on a page take a look at Intranet User Experience Design.

In the world of corporate web portals user experience tends to take a backseat during a project.  After all – with the requirements gathering, coding, configuration and additional tasks that need to be completed, who can bother setting aside time to deal with something wildly subjective like user experience?  What intranet team has a dedicated user experience person on staff?  Besides – we are going to be showcasing all of the difficult integration work and sophisticated development and content that we have created, right?

User experience is an inherent part of an intranet project – whether it is consciously addressed or not.  Generally intranet deployments or deployments of a project within an intranet are carried out by the technical team supporting the technology and with their existing workload it is difficult to entertain putting into place another process or piece of paperwork that stands in the way of “getting the job done” (for a better approach see an alternative, pragmatic, delegated approach to portal development).  The downside of this is that great technical solutions, regardless of their brilliance could have only a fraction of their value ultimately realized by the end user community.  Your production line may have produced the Mercedes of technical solutions, but it is imperative that we do not skimp on the door handles, upholstery and paint job.  In the context of a corporate intranet the following items often need answers that a purely technical approach cannot address

Retail Chain Store Project

ABC Retail Chain Franchises relies on a central corporate intranet to connect their various locations to central information.  Headquarters has been struggling to provide their franchises with better information and guidance so they can be successful with their operations and respond quickly to changing market conditions.  Currently ABC Retail Chain keeps inventory levels in their mainframe system and wants to make this available to the stores to help them gauge their stocking needs and allow customers to understand when an item might be arriving if it is out of stock.  This information will also help the stores to plan when and how they will stock their shelves.  Further examples of this guidance might include changing end caps to highlight top selling products or posting advertisements in the store tied to a particular promotion.  Headquarters would also like to make sure that instead of holding many management to employee meetings throughout the week that they can maximize their communications using a single delivery channel where information is stored, so that it does not need to be repeated.  Based on feedback from one franchise that created their own web forum for employees, ABC Retail Chain has learned that allowing peers to asyncronously ask questions with each other was very helpful to quick problem solving and increasing productivity amongst workers.  In a similar vein – a staff directory of names, phone numbers and email addresses has been very popular in helping employees to connect and resolve issues and has been photocopied and sent to each franchise.  There have been problems keeping this book up to date though, as the stores frequently have employee turnover due to seasonality.

ABC Retail Chain’s IT department was put in charge of the project and knew that they could aggregate all of the data requested and create an intranet for the franchises.  What they struggled with was how to place it all together for the end user.

Tom the IT project leader was responsible for delivering the project under tight deadlines and was getting a bit lost with how his team was going to be able to cobble everything together in some cohesive manner for the users.  He pulled his technical team into a meeting and after a few hours they had hashed together the following diagram of the portal that they were comfortable in delivering.

After the meeting the design still did not seem correct, but Tom did not have an expert on his team to tackle User Experience and was short on time.  Desperate for some guidance he began to search the web about corporate intranets and struck upon an article on the User Experience Bull’s-eye.  Fortunately Tom is collocated at headquarters and he was able to quickly pull together a meeting with his project sponsors and a few local franchise owners and within a hour had created the following Bull’s-eye.

The pain generally becomes apparent when trying to figure out why old content exists within the intranet or how to restructure content after reorganization. I have had the luxury of being part of many corporate intranet developments and privy to the management teams and activities behind them. Based on what I have seen there are a few quick and easy gems that help to reduce the management overhead of running an intranet. Please see below for the series of tips that collectively can free the time of an IT staff to focus on more pressing needs.

Tip #1
Content Owner – always include a link to contact information of the content owner, their manager and department on the pages that they have created.

Why?
Inevitably your intranet will grow over the course of many years. Over this period of time employees will leave, change departments, etc. It is guaranteed that people will periodically wonder why certain content may be out of date or if it still belongs within the intranet. You now have a simple fix.

Tip #2
Empowerment – an IT department is not allowed to post content for the business.

Why?
Due to the maturity of content management systems it is counterproductive to have IT posting business content. Their time can be much better spent looking at ways to automate process for the business or reduce the amount of time it takes to access and use certain systems. Learn more about how business and IT can collaborate to maximize value.

Tip #3
Peer Education – if someone wants to post content on the intranet they are required to take a quick course on the basics of how it is done. Once a member of a department or project has been taught – they are now responsible for empowering others in the group who wish to use the technology.

Why?
Just like tip #2 an intranet is going to be most successful when the content maintainers are empowered to manage their own content. By supporting bad habits and shortcutting the proper process the reliance on IT for these tasks will be reinforced. Learn more about Maximizing Portal ROI – Education, Production Capacity and Stewardship Delegation.

Tip #4
Search – add metadata to content to provide clean search results.

Why?
Tending to Metadata might sound impractical and create a high level of overhead for content contributors – but it is an essential part of making sure searching for data within the intranet is painless. This is especially true when then same keywords can produce a result set with irrelevant information. A good example might be people that work with products and or services that have various version numbers. Chances are that when you run a search the result set will contain very old data, in addition to the new data that you are looking for. This can be frustrating as we potentially can only search on relevancy or date, not both at once so by adding some simple metadata to indicate the version of the product or service that we are searching for. Learn more about Portal Governance.

Tip #5
Feedback – make it easy for users to send their feedback to content owners (see Tip 1 above)

Why?
If there is an issue with the content or a request about it, the owner can be quickly reached. This saves time for people trying to connect with various parts of their organization needed to complete their job and generally enhances the quality of the content within the intranet on the basis of feedback.

Tip #6
Insight – if your intranet platform has available search logs check them periodically

Why?
This provides a wealth of information about what is important to your users and indicates how the intranet and business teams might be able to better help them. If people are searching for various topics that do not have corresponding content within the intranet, it can potentially increase the value of the intranet for the end users by including content around what they were searching for, but could not find.

I hope that this list has been helpful and uncovered one of more items that have not been considered for your intranet deployment. Do you have any tips that you would like to share? Please feel free to drop me a line with your thoughts.

I marvel at the complexity of various finely made timepieces.  I cringe at the complexity of various projects.  A timepiece is generally valued by the number of “complications” or moving parts that it has. Conversely, a project is punished by the number that it has.  Unfortunately the possible surface area for project issues grows exponentially as the number of tasks within a project increases.

Working in technology consulting all of my professional life it might seem that it would be to my benefit to sell and manage a variety of large, complex projects to drive revenue.  It can actually be detrimental and somewhat like a race car going too fast in the corners.  If a project looses control and never crosses the finish line both the client and I have lost.  I am not a management consultant, but clearly understand that is not a good approach to doing business.

The key to winning is to deliver the project in smaller, cleanly scoped and controlled phases.

Most importantly – the project must really be approached in a phased manner – it cannot just be lip service from the project team.  At the end of the day a business sponsor will be expecting some business value to be produced from the project efforts and steering away from the phases approach in any regard blurs the lines around that sponsor’s expectations and can derail the project.

Consider these steps in order to help support and create a pragmatic, phased approach that I hope can assist you in delivering predictable benefit to your project sponsors.

Pragmatic Phases Project Approach

1. Projects only begin to provide value once they start to support or produce for the business that they are designed for:

• Fight the urge to bundle all of the business value into a single, monolithic development effort.  If that efforts stumbles or is halted, the business value is impacted
• By phasing the project value can be provided to the business much earlier in the overall project life cycle
• In almost every project it is possible to decompose and prioritize various business benefits that will be made available by the project completion

a. Review the list and sort it by the priority of each business benefit

• Observe various dependencies and finalize the list c. Schedule your project into phases on the basis of the list
• Treat each phase as a traditional project: a. When complete each phase should yield a working deliverable available for review, revision and release. b. Continuing to think pragmatically each release does not need to be made public, but should be treated as though it were final given its place in the overall project life cycle.

Hopefully the above tips help project teams avoid trying to “boil the ocean”.  There are many good project teams that have fallen short of their potential by trying to address all requirements in a long running project and ultimately failing to deliver a working product.  By approaching those same projects in a strictly phased manner they could have greatly increased their chances at getting their projects out of the door.

I look forward to additional thoughts on pragmatic approaches to project management for larger projects.  Please feel free to drop me a line or comment.

Organizations are beginning to recognize the value of deploying consumer Web tools to obtain basic benefits like internal knowledge sharing. This being said, they often overlook deeper benefits that the elements, and, more importantly, their methodologies of collaborative contribution can provide. Due to their ease of use, organizations can leverage these tools to allow for natural participation within their traditional application-development processes, allowing both developers and business analysts to jointly contribute to solution development.

Natural participation is an agile, cost-effective, and logical participation model made possible by portal or portal-like frameworks that let business analysts design processes, content, structure, and other elements of a solution in parallel and in participation with a traditional software development team. A tremendous amount of business value can be gained from the speed, ownership, and maintenance in a solution-delivery model that stresses participation of the business units involved in creating the overall solution, while not relying exclusively on a development team to carry their vision to completion. Natural participation can be thought of as “Agile Development Plus” to further accelerate overall solution delivery.

As an example of how natural participation could be applied to a non-technical task, imagine multiple participants actively assisting in creating a painting on canvas. Based on their strengths, the participants would contribute their various degrees of skill and help where it made sense. Perhaps a particular team would focus on painting trees from a template to free up the highly skilled artists to work on the complex and unique details of the people in the painting. When the work was done, viewers would appreciate a single painting for its overall qualities, not knowing that multiple authors with various competencies were involved.

Whether developing an online mortgage application or a business-to-consumer Web site, this participatory method is made possible and effective by leveraging Web 2.0 principles of contribution.

The Frozen, Monolithic Past

Applications have historically been deployed by IT teams based on the waterfall development model, which results in monolithic, often cumbersome solutions. All elements of an application have been controlled by the development team including textual content, taxonomies, site structure, surveys, dashboards, and other elements. Although many great solutions have been built this way, unfortunately it has cast the development team as the bottleneck.

Here are some drawbacks of the traditional development model:

• The team is slow to react to business needs.
• The development team becomes the bottleneck for initiatives.
• There is more code to maintain.
• There is more code to test.
• Regression testing is needed for application updates.

It we take the monolithic model to its extreme, it could take weeks to adjust the destination of a simple hyperlink within a Web-based application. If an item of content needs to be changed or the structure of the site requires adjustment, the development team is always tasked with this effort, reducing available resources for other projects. A series of regression tests may also be needed to ensure that the application is able to continue functioning without being affected by the recent change.

Once again, many outstanding solutions have been developed this way, but we can all agree that this process is not without significant drawbacks.

Passing the Baton

Members of application development teams take great pride in delivering solutions to the business, and rightfully so. They have worked hard to gain thorough insights into complex systems that they weave together to meet the needs of the business. This can also make it difficult to relinquish control over portions of applications and move to a more iterative, natural participation model of development.

When it comes to control, it is only logical that concerns over development efforts running wild without the steady hand of IT would abound as business analysts begin to have further levels of participation. To combat this fear, enterprise vendors have been careful to not overlook governance and security controls, establishing approval processes, appropriate access, and auditing possible within their new tools.

Once IT realizes that their efforts are best spent focusing on high-value strategic tasks to drive their own efficiencies and cost reductions, resistance to this change falls away.

The Big Thaw: Natural Participation in Action

A fictional corporation called Blue Walnut Realty (BWR) had a public Web site that allowed customers and business partners to connect with them at www.bluewalnuthomes.com. The Web site had a public-facing section that contained marketing material to help generate sales leads and showcase their services. In addition, the site had two secure areas that allowed home builders and home buyers to access an online application.

The customer application helped potential home buyers keep track of favorite properties that they were interested in purchasing. The secured home builders section of the Web site let builders add and update their property listings within the BWR database so that potential customers could browse and add these property listings to their favorites.

Historically, BWR had used the waterfall development method to support these applications and had released new functionality or adjustments to their Web site on a bi-yearly basis. All development efforts were handled by their development team, which met with business analysts to transform the latest business requirements into solutions.

Over time, BWR had seen their growth slow as smaller, more nimble competitors began to offer similar functionality on their Web sites and more quickly adjust to meet consumer needs.

Recognizing that their Web presence was a crucial element of their overall business strategy and that it would help them grow their business, the BWR CEO and CIO committed to investing in a more flexible Web framework and to researching ways to leapfrog their smaller competitors. To support this new business initiative, BWR also revisited their development processes and began investigating agile development methods. During their investigation, they came across the principle of natural participation in this new framework and decided they would also leverage its methodology.

The results were significant. By adopting a natural participation method of solution development, they quickly found themselves accelerating their initiatives at speeds they hadn’t thought possible. With developers and business analysts collectively contributing in parallel, which was not possible earlier, the same number of resources could now produce much greater results in a shorter time span.

Within a week of moving to the new platform, a new feature was added to the Web site that allowed potential home buyers to start a discussion with BWR staff around potential homes on the same Web page where they stored their favorite listings. This added a much more personal touch to the Web site, and the potential customers were very pleased with the new functionality. The development team invested no effort on this initiative as the business analyst team used native framework tools to create the new interactivity for the prospects.

BWR also wanted to strengthen relationships with the home builders. Immediately after adding the discussion forums, the business analyst team began to weave in targeted marketing materials explaining the benefits of working exclusively through BWR alongside the application that home builders used to add and update their listings. In addition to these materials, the team created specific contact forms to allow the builders to show their interest in specific programs offered in the marketing materials.

A few more weeks down the road and using native portal tools again, the business analyst group set up individually branded logins for all of the major builders to bolster relationships with them. This required no developer assistance or regression testing from the development team as it was native framework functionality. The individually branded logins were something that none of their competitors offered, giving BWR a distinct advantage.

What about the application development staff at BWR? Throughout this entire process, the development team had been freed up to focus on more strategic technology projects. They are now preparing to release a new tool within the site that allows potential home buyers to download their favorite available properties to a GPS device that can easily guide the prospects through a tour of the properties. This is a feature that no competitors have and something that was made possible by using the time not spent updating site content, adding new interactive site elements like the discussion forums, updating site structure, building uniquely branded login areas, or deploying marketing materials for the builders.

How to Implement Natural Participation

Leveraging principles of natural participation requires coordination from a business and organizational standpoint, as well as from a technological standpoint. There is no perfect approach to its implementation, but the overall goal is to obtain benefits from a pragmatic, agile approach to development with multiple parties. Below are some key steps that will help organizations begin to embrace this ideology for projects.

1. Secure executive sponsorship — Change is difficult. Even though many benefits exist from implementing a model of shared participation for solution development, it will take a compelling executive voice to reinforce the new strategy. In the absence of this support, people will gravitate toward the status quo where they are comfortable.
2. Know all facets of your application framework — It is crucial to look for areas within a development framework where non-developers can contribute and manage part of a solution. This frees developers to focus on more crucial initiatives and frees the business from the bottlenecks of waiting on the completion of long release cycles to make minor adjustments to a project.
3. Challenge the current Software Development Life Cycle (SDLC) and release management approach — Too many companies do things “because that is the way we have always done them.” Step back and examine if a traditional model makes sense given the evolution of platforms and their ability to now develop more modular solutions where multiple audiences can manage different segments of a project.
4. Explore delegation and define governance — Just because a development team may no longer code an entire solution does not mean that it has to result in a loss of control over content. Modern development platforms can provide workflow, auditing, and other methods of managing segments of a solution in a secure and controlled manner.
5. Identify obvious candidates for delegation — Content, information structure and layout, high-level security, and workflow are just some elements that business users can manipulate within a platform. The business can focus on these portions of a project without affecting development efforts and offloading a significant amount of work from a development team.
6. Keep all parties informed — The development and business teams should participate in regularly scheduled, brief meetings to inform each other of their project activities at a high level. This will ensure that any change in overall project direction or business requirements will have minimal impact on the work that both parties are doing and how that work is integrated between them.

Conclusion

By leveraging the principles of natural participation, it is possible to thaw enterprise application development, making the most of a portal framework and native tools that enable contribution by non-developers. Each initiative can be evaluated as to whether it makes sense to begin traditional development work for a segment of the solution, or if it is possible to involve members of the business-analyst team to paint that part of the picture. This process leads to greater business agility and allows development teams to focus on higher-value strategic tasks, while business analysts become empowered to “naturally participate” in the overall solution development and increase the business value that IT can offer to its organization.

In this exploration we address the latter of these two scenarios, in which business user empowerment allows knowledge management solutions to quickly be constructed and the barrier to effective knowledge work to drop within an organization. People are hard pressed to deny the “cool” factor of these new tools, but these suites inherently pose some tough, critical questions about their business value. Between the practical application of these technologies, challenges around governance and security, and issues around education and adoption, it is easy to see where an organization has to think long and hard about implementing these tools and ask important questions:

• Where do these tools fit into the enterprise?
• How can we govern the usage of these tools and manage the data generated by these tools?
• How do we leap the user education hurdle?
• How can these tools generate business value, thereby justifying a potential deployment?

Once you are able to address these points and understand what makes sense for your enterprise, you can identify where these product sets can provide value. You’ll be able to see that harnessing these tools makes it possible to accelerate knowledge work through the capture and presentation of information through user-authored spaces. It will also be possible to calculate an objective return on investment by measuring key performance indicators that satisfy the justification for the toolsets. Ultimately, this allows you to unlock value from enterprise knowledge management for your organization, granting you new levels of knowledge sharing and efficiency.

Fitting Into the Enterprise

A medium- to large-scale enterprise has an electronic mail solution along with a host of vertical applications implemented to address core needs like procurement, financials, and other common line-of-business needs. These tools run the gamut in the way they allow users to produce and manage an organization’s data.

Email is the essence of unstructured data and, conversely, vertical applications manage and host rigidly structured data. In organizations where knowledge work is occurring, these tools fail to provide a platform to act as a workspace to facilitate the dynamic, ad hoc collaboration around business challenges.

Although written from a sales and marketing standpoint, Chris Anderson’s book The Long Tail details dormant economic value that goes unaddressed by large systems. Only when a vehicle exists to cost-effectively address niche needs will this value ever be realized. We’re continually presented with projects that have technical solutions falling somewhere between unstructured email and highly structured vertical systems like SAP. Enterprise 2.0 collaboration technologies support the needs in this middle ground that never could have been managed or cost-effectively addressed before.< /p>

This middle ground, or “whitespace,” has traditionally implied custom development effort, and generally it took six to eight months to develop a solution for even the smallest of business problems. When business users need a tool to manage this middle ground, it is not feasible to justify custom development, and the business makes use of the only tools at hand to tackle the problem. These have traditionally been email and other tools that are not well suited to knowledge management work.

User-driven product suites shine under these circumstances and provide a framework for teams to quickly create and manage these situations. When business users are able to identify a need that the traditional application space does not address and quickly satisfy those needs with these toolsets, value is realized because they do not need to engage development resources from the IT arm of the organization; instead, they can respond at near real-time speed. This allows IT to focus on more strategic projects around their core business that do require precious resources, and business users can work efficiently within a managed space in the enterprise.

Governance

With highly dynamic collaborative tools, mitigating fears of misuse is not a trivial matter. Within most organizations, any electronic information outside of email and casual office documents requires some degree of formal regulation.

Often, a battle ensues between business teams and technology management teams as to how best to use the tools. To make the most of the toolsets and to obtain the greatest business value, a reasonable, but not overzealous, level of governance must be placed around them. When we think of governance within a highly dynamic collaborative environment, some basic principles can be followed to smoothly manage the processes, while still allowing business users to create value.

Like a traditional IT initiative, obtaining executive- or departmental management-level sponsorship is crucial to the success of the initiative. Just because the toolsets enable fast solution development does not reduce the need for sponsorship. In addition to the sponsorship, the purpose of the deployment needs to be clearly defined. It is not enough to deploy a project with the toolset just because of the features available within the toolset. Feature-driven projects are destined to fail.

After the solution is in place, it will need to be maintained. This means that a clear owner must be defined for the outputs of the project. This owner will need to obtain any requisite training to support and enhance the solution going forward.

Based on the purpose of the deployment, it is essential to identify what information will be committed to these spaces. Will a space contain information that is sensitive and in need of being secured? Who will have access to modify, edit, or add information to this space? What level of auditing needs to be put into place? Knowing the answers to these questions upfront will allow you to set up the correct access permissions to enforce business policies within the workspace.

Finally, a plan for periodic review of the project’s outputs needs to be defined. This review acts as a checkpoint to make sure that not only technical but also business process rules are being adhered to. The review should also contain procedures and metrics that measure when a space should be discontinued due to nonuse.

Outside of security, at the end of the day, much of the governance with toolsets that pose a low barrier to entry will boil down to business processes. People in organizations need to be responsible for their actions at a business level beyond the technology. This is where a clearly defined plan based on the above elements is crucial if people are to succeed with enterprise 2.0 technologies.

Education

User-driven products that provide expedient gratification with regard to the reduction of daily burdens and processes have exceptionally high levels of adoption. Public examples of such systems underscore this trend, including the social networking site MySpace and blogging tools like Blogger and WordPress; these are definitive examples of tools that self-educated users have quickly adopted and gained value from, without extensive formal education.

The low barrier to usage can be attributed to the toolsets’ small, but often highly used feature sets. For users experienced with complex enterprise applications, this is a refreshing change. At first seemingly confining, the limited feature sets allow for maximum usability. Tools like Basecamp from 37signals also embody this ethos, providing a small, but often used feature set. This drastically reduces the need for education and increases the rate of adoption and speed at which value can be delivered.

That being said, it is beneficial to offer formal training classes to outline the available functionality of the tool and review how it might be applied through an examination of a series of use cases in order for the end users to obtain the greatest benefit. Once an initiative has been able to conform to the governance requirements for a project, a quick boot camp-style training curriculum led by an experienced user or company teacher is an excellent way to jumpstart the project in an effective manner with minimal resources.

Value

Given the current unmanaged whitespace within organizations, these tools provide substantial value from both a business and information technology management standpoint. Business users are able to realize new value by quickly reacting to their current and emerging business challenges, and authoring solutions for them. Blogging and wiki-style mechanisms provide an excellent platform to facilitate knowledge transfer and knowledge management not possible before, allowing for the actualization of all-important tacit knowledge. Information technology management groups can benefit from cost savings by consolidating some existing, moderately used applications and from a never-before-possible degree of auditing within the whitespace.

Complex decision making

Tools that allow the business to paint a canvas of dynamic collaborative functionality allow for an endless possibility of “applications” to be created. Imagine a situation in which a major decision needs to be made among a number of players from across the business. The decision might hinge on information from a CRM, ERP, or custom application. This critical data can then be incorporated into a space where users can contribute to a wiki or share documents and various other artifacts around the data to ultimately make a decision or select a strategy on the matter. This would have historically happened in a disjointed way across email where the process would take longer and the knowledge work potentially would be lost beyond the final decision.

Collection of tacit knowledge

The creation of a low barrier to the collection of tacit knowledge cannot be understated and can have a direct impact on the bottom line of a business. Imagine a vendor consulting group that is helping to increase product sales. Ensuring their field methodologies, such as best practices and critical product issues, are easily captured and shared among resources, can have a direct impact on deployment success. This deployment success translates literally to increased customer satisfaction, which, in turn, increases product sales.

Value through iterative contribution

User-driven authoring really shines when we examine how quickly we are able to realize value throughout a project. User-driven collaborative frameworks accelerate the time in which business value is delivered due to the ability to iteratively author. Unlike building with traditional software, requirements do not need to be completed for the business to begin constructing a solution. This allows business users to continuously focus on small, high-value components, which lets them realize value early and often throughout their process.

Cost savings and control

As IT departments attempt to keep costs down and monitor what transpires within their systems, controlling application sprawl is a top priority. We can look toward these new tools to act as a platform for consolidation of existing, lightly used legacy applications. This reduces cost not only from a server perspective, but also from a code maintenance perspective. Potential “would have been” custom development initiatives can now be handled through the framework. This can also stunt ongoing development maintenance costs as development efforts can now be directed at furthering core elements of the business and not providing the “one off” solutions that the user-driven collaborative suites now fulfill.

To measure the value that the suites deliver, key performance indicators such as email usage, the amount of resource and time to onboard a new employee, and the length of time to resolve a problem or complete a research assignment can all be captured. Additional quantifiable justifications can include servers and the knowledge, staff, and time to maintain many small, infrequently used systems.

Final Thoughts

Enterprise 2.0 collaboration suites are an investment in an organization’s production capacity. The possibility of being able to harness and navigate whitespace within organizations through business user-authored environments is an exciting, powerful vision. To drive these efforts and expose new business value, both education and governance must form the pillars that the newly created solutions will stand upon. In addition, a business champion must be able to firmly grasp these concepts and understand that value will not be delivered on the basis of the toolset’s features, but on solving key business problems and using the toolsets to manage the solution. With this foundation we are on our way to unlocking the value of enterprise 2.0 collaboration technologies.

* Originally published on BEA System’s Arch2Arch 03/05/2008