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.

Over a series of various online community and corporate intranet deployments, heuristics have emerged as to what will make the community a “success” and provide a return on the investment. These heuristics can be used with a broad array of deployments within your corporate platform to gauge what business value is created for the end users of the platform.

These guidelines can be condensed into a workbook format to help us to understand and prioritize development activities on the basis of the value that they provide. The workbook includes a series of questions that fall into five basic categories outlined below.

• Content – knowledge workers require access to various documents and materials that are analyzed and synthesized in order to perform their job functions.
• Process – a task or series of related tasks that can be represented as a workflow that workers need to interact with at some frequency in order to perform their job functions.
• Access – can potentially present a barrier to use if complex or redundant authentication to systems is required.   Conversely, if multiple systems become available from a single authentication value in the form of time savings can exist.
• Application – various line of business systems are critical to employee’s ability to perform their jobs.   This category relates to these tools that are often specific to collecting and referencing data for a particular department or job function.
• Time – acts as a well understood, easy to convey metric to evaluate possible savings from projects.*

*Please note that this workbook will only touch lightly on time savings.  Time savings is a byproduct of various efficiencies that an intranet potentially offers users.  The workbook focuses on the underpinnings of what delivers the time savings.

The workbook has a variety of line items associated with each category. Within each category there are groups of line items that need to be marked with a y or n indicating if they are applicable. For each group select only one line item can be answered. As the workbook is completed a running tally is displayed in the upper right hand corner of the sheet. If when finished the score is above zero – the project that you have outlined will provide solid business value and give your end users a compelling intranet space.

Download Intranet Success Workbook

I would be interested in feedback on the workbook, as there are many additional line items that could be added.

If you have never read Seven Habits of Highly Effective people you are missing out – especially when it comes to making the most out of an investment in portal. Specifically, I am referring to the concepts of stewardship delegation and production capacity, both of which can be developed through an educational curriculum and guidelines aimed at empowering business users. Simply put, in order to gain the most value from a portal deployment the business needs to understand how to fish.

Stewardship delegation places the responsibility for project results onto the business participants. This ability to participate is gained through platform education and agreed upon guidelines for contribution, thus increasing their production capacity, commonly known as effectiveness. This will maximize the return on the technology investment.

Although at first intimidating it is possible to grow production capacity within the user base via a formalized gating process users. In order to have business needs met through the portal the business must actively participate in some educational offering and obtain rudimentary levels of knowledge with the toolset, before being allowed to complete the deployment of their project. This process should be mandated by way of portal governance. With this being said it is understood and accepted that a less mature portal deployment might not have a robust governance framework yet in place and we may need to begin the process of education with more pragmatic measures.

Common Roadblocks to Building Production Capacity
Beyond executive sponsorship the primary roadblock to building production capacity generally sits with the fallacy that the portal team “cannot afford to take time” to educate their user base how to self-serve. Remember that we need to focus on effectiveness, not efficiency. It will always be more efficient to have the portal team do the work directly, but it will not scale. We need to build effectiveness.

This is somewhat akin to owning a race car, but never taking time to learn how to drive the car properly – you have made the investment, but will never unlock the full potential of the investment. This is why investing in an organization’s production capacity makes so much sense. The portal team can still continue to produce results for the business, but some of their time needs to be spent building the production capacity of business teams themselves.

It may seem obvious, but this approach goes a long way towards
• Allowing the portal solution to scale throughout the business
• Providing faster response times to business needs
• Allowing the portal team and development staff to focus on more strategic initiatives and less day-to-day management of the platform

The beauty of this model is that after experiencing success with it the business is unlikely to want to wait on the portal team to laboriously build out solutions that they can configure themselves. Just imagine a solution development system where a portal team spends more time developing reusable or strategic components and evolving the governance model!

Getting Started with Stewardship Delegation
In the book Seven Habits of Highly Effective People the concept of stewardship delegation is introduced and is alarmingly similar to portal “Governance”. This style of delegation takes time and patience on the part of the educator, but the end result is a rewarding relationship where the student (the business) walks away able to effectively contribute to solutions. You may ask why this is different that any other form of education. Good question!

Per the Seven Habits, Stewardship Delegation requires an up-front mutual understanding of and commitment to expectations in five areas. The following areas are taken from Seven Habits of Highly Effective People and updated to directly relate to portal initiatives.

1. Desired Results – Have the person see, describe, make a quality statement of what the results will look like and by when they will be accomplished with their project. This should be achieved through a formal request stating the mission of the initiative, that is vetted before a portal steering committee or project approval board.

2. Guidelines – Identify the parameters within which the project group should operate. Keep the responsibility for results with the project team that has been empowered. This should include the responsibility for participating in a portal education session. The project team should not be able to commence work until they have completed the education session and had their project request approved.

3. Resources – Identify the resources available to accomplish the required results and who will maintain the solution once it has been created. Although seemingly simple, long term ownership can be very challenging. When solutions are built without clearly defined long term ownership they detract from the end user experience, cluttering it with out-of-date or irrelevant content.

4. Accountability – Set standards of performance to be used in evaluating the results and specific times when evaluation will take place. This represents a layer of governance present in more mature portal deployments that should be placed around any project that is undertaken within the portal.

5. Consequences – Specify what will happen as a result of the evaluation, including rewards and penalties. In the above example this might relate to the community being discontinued if traffic levels fall below a certain level. These metrics need to be agreed on by the parties ahead of time and will be used to ensure that the project outputs (perhaps a community) stay on track well after completion.

Governance is complex and the above illustration of the five areas only scratches the surface for what is needed to successfully run and manage a portal deployment. It is clear, however, that the common thread is the participant’s commitment to agreed-upon desired results.

My hope is that the above elements can jump start a more formalized approach to deployment success within an organization. The participants realize that they need to be place genuine commitment behind their initiatives, but also understand that they will be rewarded with the ability to have a generous degree of autonomy and control over their projects if they commit to the five areas above.

Going Fish – Making it Happen in the Real World
It is obviously easy to write about the merits of the above model when we seemingly find ourselves constantly bailing the water out of our canoe so we do not sink. Just as when we are working diligently at jobs there is never a “good” time to take vacation – but we just need to do it to protect our production capacity.

Once an organization has made an investment in the portal platform it would be doing itself a disservice not to start engaging in stewardship delegation to enable its user base to increase its production capacity through education and adherence to agreed upon guidelines. The following items represent some practical steps and guidelines to help begin the journey of increased production capacity

• Design a community request form that addresses each of the five areas highlighted in the “Getting Started with Stewardship Delegation” section above

• Find a request suitable for a pilot project that the portal team can mentor the business team to develop themselves

• Make it mandatory for anyone who requests a community to actively participate in a portal 101 class and demonstrate a fundamental understanding of the toolset

• Hold lunch and learn workshops to enable business users to get a better sense of what business value can be provided by the platform and where it has been successful in the organization

• Develop a community that contains a wide range of sample portlets so people can get a sense of what platform tools exist to meet business needs

Implementing the above concepts through stewardship delegation will go a long way to ensure that an educated, empowered business team has an optimal production capacity and can make the most out of the portal investment. This will allow the portal team to then focus on developing the vision and strategy necessary to continue to support new solutions for the business in a timely, effective manner, making the most efficient use of portal.

It is time to revisit business analysis basics and be careful to make sure we have not started focusing entirely too much about the perceived need for these tools, opposed to a specific need. These tools are powerful and attractive, but we really need to understand if and how these technologies should be leveraged – pinpointing where they can alleviate business pains. In the work that I have done with a range of enterprise software deployments there is a consistent trend demonstrating successful implementations result when done to address a specific need, tools that were put into place because the technology was in vogue failed. Web 2.0 technologies in the enterprise fit the same bill. Do not look to implement them because eWeek magazine or another publication has labeled it as the thing that other IT executives will implement this year.

I hope to clear the air in this post by outlining the virtues of each tool (specifically tagging, blogging and wikiing) and through a series of questions add clarity to where they would make business sense and allow the virtues to be realized.

Tagging
Social tagging technology excels at handling large amounts of unstructured data that is not served by traditional knowledge management systems (i.e. folders upon folders buried in a large, somewhat static hierarchy). Given this power it needs to be considered as part of an overall knowledge management strategy for information workers, but it also needs to specifically address some pain or a specific need of the business.

As information volumes continue to rapidly expand in the enterprise it is very difficult to organize and catalog assets, even with the support of full-time librarians. Additionally, in a world of M&A and constantly shifting organizational structures, it can be all the more important in helping people to reign in and make sense of this data. It is not uncommon for users to spend an extra fifteen minutes searching for an article within traditional search engines when they could not explicitly state their query to return satisfactory results. By contrast, tagging technologies have allowed them to see what other, related categories materials might fall into, speeding their searches drastically. Here are some questions that may help your organization determine if tagging would support the business by meeting specific business needs.

• Is your company currently experiencing quantifiable issues finding documents or other digital assets within your network? Is it a big enough of an issue to act on?
• Is a technology like social tagging something that your organization’s culture would embrace? Is the user base directly asking for it? It is important to keep in mind that tagging will only benefit end users if they are willing to contribute to the tagging of document. As enterprise tagging matures it is likely that it will gain acceptance in much the same way instant messaging has within the enterprise.
• Is there any research or knowledge intensive work at your organization that tagging may accelerate through more effective discovery of information?
• Are there opportunities to use this technology to help external customers more easily do business with your company?
• Would it be possible to designate someone to own and manage the platform from a business standpoint at a department or enterprise level?

Blogging
Blogs are great tools to rapidly publish and share expertise within an organization. Unlike email, a blog posting persists and is generally visible to a large audience which is able to engage the author in a dialog with comments or questions for everyone to see. Unlike a discussion forum, a blog posting provides detailed information around a particular topic, rather than a brief comment or question. A blog is also generally associated with a single person, allowing them to gain recognition in their organization or respective field. In your organization it might be a software developer, operations specialist or researcher that is able to provide a significant amount of value with this tool.

It may sound strange, the key to enterprise blogging is not about creating blog entries to be consumed by the entire enterprise, but about providing a single, unified platform that specific business participants can use to write posts for discrete audiences. Blogging within departments or to specific niches where the information is most relevant is the most valuable use of the technology. One of my prior postings (Niche Cooking for Portal Success) details a philosophy aligned with this approach which will work equally well for blogging. The following questions will help you to identify if it makes for your organization to deploy this technology.

• Do you have experts in your organization that have pointers that others would benefit from in a measurable way?
• How often would there be something that someone would blog about that people across the enterprise could really benefit from? Our foremost needs revolve around what it takes to get our work done, so any blogging that takes place in an organization has to help meet this need. With rare exception anything else is not providing value that can justify putting a platform into place and taking the time to manage it.
• Would connecting with customers, partners or external constituents add value for your business? Would it be worthwhile enough for the investment?
• Would people be allowed to have time to contribute to their blogs during work hours?
• Would your organizational culture be tolerant of people posting with limited supervision?

Wikiing
Due to the allure of ubiquitous knowledge capture and propagation, a wiki deployment requires an extra amount of careful thought as to why and how it will be deployed to the enterprise. Given the potential, as demonstrated publicly by Wikipedia, many companies entertain having a wiki tool whose content expands into all sections of their business. This risk is that this generic, organization wide deployment, would most likely bring little business value to the enterprise and leave people wondering why they ever made an investment into the technology.

Similar to blogging technology, Wikis are going to be most effective when deployed for a very specific reason. A deployment could occur within a department, across departments or even with areas outside of or around the company, but should always tie back to a specific need that the tool is supporting. Wikis do an excellent job of helping knowledge workers collaborate on projects or support a function or process, by capturing tacit knowledge, sharing “facts”, presenting methods and or publishing best practices. Instead of being done by a single user, a Wiki allows a team to work together – enhancing and updating areas to evolve with the business. There is no better “living document” than a Wiki. Take a moment to think about the following questions to see if a Wiki might make sense for your business.

• Does your business have undocumented processes or knowledge that could help a specific department or function perform more effectively if captured in a Wiki format?
• Is there a simple place where new employees could go to learn during an on-boarding process? As policies, procedures or reporting structures and processes change within an organization a Wiki does an excellent job of making sure people can get up to speed.
• Does an identifiable bottleneck exist with some members of your organization that could be alleviated if they were able to share their knowledge collectively with other employees?
• Given the categorization that a Wiki imposes would it make existing knowledge more accessible if placed into the a unified format that a group could manage and edit? Since a Wiki can be an authoritative place for a collection of related materials it requires far less maintenance than a series of disparate files to maintain, enhance and manage.
• Would people be allowed to have time to contribute to the Wiki during work hours?
• Would your organizational culture be tolerant of people posting with limited supervision?

Final Thoughts
There is not doubt that a range of social computing technologies in the enterprise can assist businesses to run more effectively. However, we want to make sure that we do not implement technology in search of a problem. The challenge is connecting them with the business in the right way. Do not find a use for tagging, blogging, wikiing. Find the business need or pain point – then examine what technologies best support meeting that need or eliminating the pain point. Hopefully some of the above questions can help your organization to focus, clarify and be successful with where and how these emerging technologies can benefit your company.

When working with powerful, versatile technology it is not uncommon to loose sight of the human element that we need to cater to for success. The “because it can” factor is tough to ignore and often initiatives tend to gravitate toward this. In order for a deployment to be successful, people need to walk away from their experience with added value. Using a restaurant analogy, this added value differentiates the quality of a portal deployment from an outstanding four star meal to an unappealingly average fast food meal.

A Grand Opening
Just as with a restaurant opening, a portal deployment goes through a series of phases that ultimately will determine if the investment (servers and software licensing) is worth it.
1. Grand Opening
2. Quality Assessment
3. Reputation Establishment
4. Patronage Level Establishment
5. Patronage Fluctuation

Grand Opening
When a new restaurant opens its doors people are drawn by a mix of marketing effort and personal curiosity. In our case we are most likely going to get exposure through a corporate email or newsletter that lets people know that a new project has been deployed with the portal.

Quality Assessment
What happens next is absolutely crucial. Users visit, or in the case of our restaurant, people eat there. This might seem obvious, but when we look at a corporate portal it is easy to overlook since we have a tendency to be drawn toward and tout features over the applicability of an experience, or meal, to the individual.

Reputation Establishment
Users need to have a rewarding, compelling experience. With the ability to quickly communicate and multitask via email and other electronic means, people have tight schedules and are generally unwilling to incorporate an additional tool if it does not provide significant value. When they experience the portal deployment they will ask themselves a few simple questions: “Did this make my life easier? Cut down on my workload? Enable a process more effectively that my traditional communication and information management methods?” The portal will not grow or assist the business through its novelty, but by the outcome of this hard, black and white examination.

Based on this assessment a reputation is established about the value provided by the new service within the portal or the portal itself. This provided value is where our target audience becomes so crucial. Did we just cook generic food in an attempt to satisfy a wide range of people? Or did we cook a specialty food that directly targeted a particular group of enthusiasts? The word that spreads throughout the enterprise is based on this crucial experience. It will ultimately come down to either satisfying a small group of people who will become vocal advocates, or frustrating a large group of people with a mediocre experience and creating a stigma around the portal platform.

Patronage Level Establishment
If we were able to deliver a satisfying meal we will have done our job to establish devoted patrons. Having this group of individuals will allow us to have sustained value within our portal deployment.

If we did not provide a good meal, people will say “Yeah, I have eaten there, but it was nothing special.” This means that whatever value we provided was quickly realized and then lost, leaving our organization with an “Empty Portal” or failed project.

Patronage Fluctuation
Assuming that we did provide a good experience for our users by adding value, we will pick up positive word of mouth. This will ideally open a good dialogue between these patrons and our business and technology teams. With this communication channel we can continue to invest in shaping value for this group of users, growing out patronage. Beyond this, as more people become advocates of the platform, we can continue to develop solutions for the business members we are serving and gain even more return from our investment with additional, iterative, focused releases leveraging the portal framework.

Getting the Recipe Right – Tips for Success
Continuing with the restaurant analogy, we need to make sure that when they ask for a soufflé we serve it to them instead of crème brulee (as good as our crème brulee might be). The portal is a “top down” tool and that means the business needs to dictate the direction of development initiatives with these needs. In order to make sure that the platform can best assist in driving us toward our business goals, the following items are imperative for success:

1. Invite Food Critics – Get participation from the business unit that you are targeting. These are the people who will be eating at your establishment. This is about what they need, not the buffet of things that you can place in front of them.

2. Serve Bite Sized Pieces – Remember that small is manageable. Let your menu evolve based on the demands of the business. Do not try to pack it full of choices from the onset.

3. Time Food Preparation – Great restaurants have impeccable timing to ensure that their dishes are served in the proper order and correct temperature. Be sure to heavily weigh the benefits of any major development portion of a project. Having one piece of the project get away from you could ruin an otherwise good project as the business will be eager to complete their meal.

4. Maintain Great Ingredients – Governance is essential to maintaining value for a deployment. Just because we served up a great meal the first time does not mean that we are set and can move on. We need to put controls in place to ensure that the quality of the meals stays consistent or improves over time in order to retain patrons and grow our business.

Final Thoughts
Thinking back to how all of this applies to the overall value that we can provide, it is apparent that a large scale launch, although seemingly impressive, serves up less value in the long run if we are not focused on serving targeted, high value tools to our audience. We are sometimes tempted to do things just because we have the ingredients, but in order to build a thriving business, it is vital that we listen to and deliver the great treats that our customer base is interested in.