Design & Development

Design and development of products and platforms

Evolving ideation into social collaboration

Note: This post was written before this concept evolved into what is now known as crowdsourcing (or crowdsourced software for content development). It was also written before the evolution of private social production platforms like HipChat and Slack

What Web 2.0 brings to the table

Often I am asked, “What the heck is Web 2.0?” by my non-technology friends (most of my friends are not technologists).

Here is the answer I give:

Web 1.0 let organizations publish information that could be accessed easily by all of us when we needed it, at our convenience. This changed entirely how we read the news, looked up movie times and checked stock quotes or the weather. The problem with Web 1.0 was that it was biased towards making it easy for large organizations to share information. CNN could easily setup a web site to share news and opinion. However, if *I* wanted to share information with many other people in this fashion, I had to setup my own web site, publish content, figure out how to control access to it, etc. This was too hard for the everyday person (who had “more important” things to worry about in his or her life).

Web 2.0 changed this by making it easy to share my views and information–and to control how I share it. Now I can use Facebook to share my vacation pictures with my friends (but limit my contact information to my professional colleagues). I do not have to build a web site, administer it, share the URL with my friends and get them to bookmark and visit it. Instead, I can rely on the fact they will visit facebook as part of their normal life and see my updates there (the network effect). It makes it much easier for me.

Enterprise 2.0 and Government 2.0 do the same — but directly in support of the missions of public and private enterprises. They let stakeholders share information and views regarding how industry and government should work (instead of simply proclaiming, “I feel blue today.”)

I have had pretty good success with this definition. It is short and relevant enough not to bore them and detailed enough to not insult their intelligence.

If you keep this in mind, it does not take a large leap in logic to see that the Web 2.0 communications medium can be used to create new services to help manage businesses and public organizations. These types of services will be ones that leverage the network effect, i.e., interaction with members of the community to find information, measure opinions, foster collaboration or share ideas…

How Web 2.0 an evolve ideation into social collaboration

Ideation is a defined as the process of forming or creating ideas (hence the terrible portmanteau). People have been using various ideation techniques for years to design more compelling products, processes and campaigns. The problem is that ideation has been limited by how much input you could manage in a collaborative efficient manner. This typically limits you to working face-to-face (ideation over conference phones — even tele-presence units — is not efficient) in groups no larger than 8-12 people. To get the input of many, you have to incur travel costs and hold many workshops or focus groups. This is slow and expensive. Here is where Web 2.0 comes to play.

Using Web 2.0 technologies and communications practices you can manage ideation in a way to lets people from all over the world participate in the ideation process — with far more speed efficiency:

  • People can participate when they the are ready
  • They can do so remotely, looking at content you have made accessible on line
  • They can interact with each asynchronously, e.g., I can make an idea at 2pm in Florida and someone else can comment on it twelve hours later in during normal business hours in Tokyo

About five months ago I began using the name “Social Collaboration” for a social networking business service to manage this:

Social Collaboration |ˈsō sh əl kəˌlabəˈrā sh ən| (noun)
A Business Service that enables—

  1. Enterprises (business and public sector) to call their stakeholders (customers, employees, and citizens) to action to solicit their input and ideas
  2. Stakeholders to respond collaborate with each other to build on each others ideas and drive preferred ideas to high level visibility
  3. Enterprises to gain understanding and insight into their stakeholders’ ideas and demonstrate that these ideas have been heard and acted upon

Abbreviation: So•Co |ˈ’sō kō |

SoCo can be used in many arenas to improve product research, service delivery, customer loyalty, business change management and public policy outreach.

What makes a good social collaboration business service

Several companies are working on building ideation-related SoCo services. The ideal SoCo service will have the following characteristics:

  • Be easy to use — from anywhere, by anyone
  • Support multimedia-based ideation (so people can collaborate using videos, pod casts, documents and pictures)
  • Enforce structured ideation, i.e., automatically organizes collaborative input, content and preference (without this you will not be able to manage large-scale collaboration)
  • Based on the network effect: if it does not work in a manner that leverages the power of the network you will gain no benefit from going beyond small working groups
  • Require attribution (to reinforce the natural process of person-to-person collaboration and enable direct follow-up)
  • Enable multiple levels of moderation (to make the ideation safe and ensure it remains focused on the problem or challenge on hand)
  • Readily support analysis (to enable you to find the most popular, most unpopular and most controversial input so you can take informed action and ultimately realize your business benefit)

Two-thousand-nine, the year of Change (political, economic, business and technology) may ideal time and place for Social Collaboration. Using it, we can figure out how best to be more efficient, develop our infrastructure, work globally and recover from our current recession.

Follow-on Note (January 2010):

By the end of 2010 this line products coalesced around the category name of crowdsourcing. At Neighborhood America we combined both our ideation (e.g., Microsoft Public Sector On-Demand) and YouTube-like UGC contest products (e.g., Kodak Idea Center–now ShutterFly) into a category set of crowdsourcing products.

What it takes to successfully implement COTS enterprise apps

That dreaded failure number and its root cause

As soon as you start planning for an enterprise program you will almost immediately begin to hear some variation of the following quote:

“You know, X% of [enterprise vendor name’s] implementations fail or are canceled before they ever make it to production.” (Where X% is usually around 50% or 60%.)

I will leave communication of the exact number to groups like Gartner. Nevertheless, many enterprise programs fail. Nearly all exceed their recommended budget and time allowances, even for their scoped-down first phases (I will get into scope control in a whole other series of posts). The single most important reason for this I have seen is the following:

Program sponsors (and their program teams) forget to include much of the work required to implement a successful off the shelf product

As a result, they need to come back to Capital Review Teams or their CFO to ask for extra money to complete their programs. In good times, they get this money (but reduce or eliminate their IRR), in bad times they can see their programs severely cut back, delayed or killed outright. Most companies are not in good times right now.

Buying off the shelf and integrating does not eliminate as many costs as you might think

My last post outlined everything you have to do to built applications in-house. Buying off the shelf and integrating eliminates many of these (in lieu of licensing and integration costs). However, it leaves many tasks that are often underestimated in the traditional “build vs. buy” analysis. It is easiest to highlight these by directly comparing the tasks for each:

Activities by project discipline area (i.e., not a Waterfall plan)

Key: Struck-out = Eliminated by purchasing and integrating an enterprise application. Red = added to successfully integrate the enterprise application. Italics = Clarifying note

  • Scoping (About half the time vs. building it yourself)
    • Negotiating contracts for acquisition
    • Negotiating contracts and Statements of Work for integration
    • Defining Concept of Operations or Vision Document outlining how the application will work at a high-level
    • Negotiating scope and phasing of capabilities over time
    • Estimating cost and time for this
  • Requirements Management (About one third of the time vs. building it yourself)
    • Capturing Use Cases, translating these into technical feature configuration and integration requirements
    • Determining non-functional requirements – performance, reliability, scalability, availability
    • Negotiating sign-off and prioritization by phase
  • Design (About one quarter of the time vs. building it yourself)
    • Designing an top-level architecture
    • Designing the logical data model. Specifying the configurable meta data for the application.
    • Designing the object model.
    • Designing the software architecture (what is internal vs. external, what is the software vs. the database, etc.)
    • Designing interfaces with external systems
    • Designing the User Interface – a huge one from determining style conventions, wireframes, mockups, usability analysis, Section 508 compliance and lots more. Specifying configuration settings for the User Interface (much easier than designing “frem scratch”)
    • Specifying the business and workflow rules to configure in the system
    • Designing the systems architecture – how you will handle maintenance, scaling on-the-fly, backup and recovery, disaster recovery, elimination of SPOFs (Single Points of Failure) – this task is so large that I built a whole portion of my career doing this for utility-class systems (always-on systems with reliabilities exceeding 99.999% and scales exceeding 10,000 transactions per second)
  • Infrastructure Management (Often LONGER than building it yourself as your infrastructure team will have to learn how the application is architected)
    • Capacity planning – how much hardware to you need, where should it be, when do you need it
    • Hardware acquisition – Selecting and ordering your hardware
    • Systems Integration – Installing the operating systems, patches, and base middleware. Integrating hardware into your network (configuring IP settings, adding to your routers and switches, much more)
    • Setting up your monitoring and production support teams and systems
    • Doing this for EVERY environment – development, integration, certification and production (your environments will multiple post-launch as you will have systems under development AND in production)
  • Construction (About one-third of the time vs. building it yourself)
    • Setting up the code repository
    • Setting up your continuous build process
    • Defining your interfaces and configuration management files. Defining exactly how existing systems will integrate with the new system
    • Building your databases
    • Building your database scripts and stored procedures
    • Building software modules
    • Building hooks for monitoring and business intelligence
    • Defining and executing your unit test cases around configured metadata, business rules and work-flows
    • Integrating and verifying the integration of your software modules with your databases and external interfaces the application with the rest of your environment.
  • Certification
    • Tracing your configuration requirements (functional and non-functional) to Test Cases
    • Building Configuring your Test Harnesses
    • Conducting verification testing, sending configuration builds back for repair, integration and certification/regression testing
    • Optional – usually done for highly-integrated mission-critical applications only: Conducting load and performance testing, including analyzing and repairing performance and scale bottlenecks
  • Training & Support
    • Developing training documentation and curriculum (for end users)
    • Setting up your Help Desk – including your knowledge base of how-to resolve expected questions
    • Setting up a Center of Excellence to manage the application after implementation (you will need to build or rent as your internal staff will not have the expertise to do this)
    • Training end users
  • Project Management
    • Developing the plan (tasks, durations, assignments, critical path, etc.) to do all this
    • Managing and resolving all those issues that come up with something this complicated
    • Estailishing governance for decision-making and issue resolution – requiring lots of time from your executives
  • General Management
    • Getting approval for the money to do this – Capital and Expense (often requiring you to in front of your Board of Capital Review Committee)
    • Managing the RFI, RFP and contact negotiation process for your Integration Vendor
    • Getting (or reallocating) the staff to do all of this – usually this is now external staff such as Integration Vendors (pro: you do not divert as many of your staff, con: they are more expensive than internals)
    • Managing the staff for requirements, design, development, integraiton, testing and installation (acquiring resources, approving vacation, backfilling departures, etc.)
    • Managing the capital and expense expenditures, including all the invoices for purchases and services and weekly or monthly reporting to your Finance organization
    • Handing all those items like staff departures (people quitting, not performing, getting sick, etc.) – This is reduced as you have “outsourced” a good fraction of it to your implementation vendor

This is still a lot of work — and a lot of time you could instead focus on the core of your business. Some will be done by internal staff. Much will require you to hire an external integrator (as your internal staff will not have the expertise to do this). The good news is that this frees up more internal staff than building it yourself. The bad news is that external implementation staff often cost 1.5x to 2.5x as much as your internal staff (making schedule overruns very costly). The cost of these overruns increases exponentially based on your degree of under estimate – this is known as Parkinson’s Law. Using a SaaS model avoids many of these costs.