Monetizing Value of Social Computing in Traditional Industries

Whether you call it Web 2.0, P2P, Live! or whatever, the excitement surrounding Social Computing is building exponentially. Social Computing is no longer just Wikis, Forums, Blogs, music downloads, and RSS feeds.  Social Computing has hijacked the Software as a Service (SaaS) and Service Oriented Architecture (SOA) movements and we are seeing the formative stages of a Global SOA that blends Social Computing with machine consumable information processing and retrieval capabilities.  The possibilities are almost as endless as the number of articles, columns, and blogs on the subject.

Social Computing is already hugely successful in many circles, ranging from not-for-profit networking and to commercialization in certain industries.  Yet, despite this rapid and far reaching success we see it having difficulty penetrating traditional brick-and-mortar corporations.

We recently gave an invited talk at a large corporation for their senior IT leaders.  The subject was Web 2.0 but the talk covered the breadth of modern Social Computing trends with an emphasis on monetization.  Like always there were some enthusiastic questions but no serious call to action from the room and no general agreement that Social Computing ought to be urgently pursued.

That was just one in a string of situations where we’ve encountered that response, even from groups in completely orthogonal industries.  For example, we’ve been the invited speakers at several large DoD functions where instead of hyping the monetization scenarios we outline some very compelling benefits from the perspective of collaboration and content exploitation.  Now, for those readers who don’t know the present DoD and Intelligence Community; content exploitation is a huge subject that always gets people’s attention.  You’d think they’d be all over this stuff.  We always get lots of questions and business cards; but in the end there’s no real call to action on behalf of the senior decision makers to make Social Computing a focus of future investment.

Please don’t misunderstand my observation here, I’m not complaining that nobody is hiring our firm for Social Computing projects; that could just as easily be a business development problem, market timing, bad breath, or something else.   The lack of interest seems more fundamental than a dearth of signed contracts; there’s just no interest in committing to an investment.  Moreover, the seniors in both the commercial and government sectors seem genuinely concerned about losing control, even on closed networks, making the whole concept a non-starter with many.

Why the lack of serious consideration?  There's certainly no apathy towards new technology.  Every direction we turn recently we find another SOA initiative, where by the way – most are floundering to meet any objectives.  Yet there is only minor institutional interest in Social Computing despite all the hype in the tech news and from power players like Google and Microsoft.

There are obvious and compelling monetization scenarios for Social Computing in the new industries; primarily those industries that sell over the Internet.  There are also obvious monetization scenarios for any brand or product that relies heavily on fan clubs; such as the entertainment industry, motorcycle manufacturers, video games, and etc.  In many cases consumer products are starting to fit this category.

However, these industries are but a tiny fraction of the overall market.  Most clients we meet are well established brick-and-mortar firms that sell boring things like insurance, hotel rooms, financial products, professional services, and etc.

What is the monetization story for Social Computing in these corporations?

How do you approach a VP of Marketing at a large insurance company and explain that a chunk of CY’06 marketing dollars needs to go toward this “computer based phenomena” that, oh by the way, is on a completely different dimensional plane than the self-service website they have today?

ROI is how most people would sell the idea.  Getting a grip on the “I” is fairly easy, but pointing to a compelling and yet realistic “R” is where someone needs to eat their Wheaties.

This is where the Global SOA comes into play.  What is Global SOA?  Basically, it starts by porting the back-end services that public websites sit on and making them into secure services that are machine-callable over the public Internet.  Keep in mind that this is different than simply making machine-callable services out of the functions a website offers users, it is more about the services behind the website than the services of the website. In pushing the Global SOA and Web 2.0 institutions are publishing relatively fine grain services, an API if you will, to let third party developers recreate many capabilities of their website.  The power is that a third party can mix services from your site with services from other places, creating a completely new offering that is itself a machine callable service.  With recently evolving sophistication even non-technical users are able to blend their own mixes of services.  This, theoretically, can lead to non-obvious sales channels and access to more customers through micro markets.

See the problem yet?

If you represent a hotel chain what are the scenarios you might construct the “R” out of?  Perhaps a third-party firm mashes feeds from weather services, travel services, airlines, and etc. to anticipate when travelers will be unexpectedly stranded.  The firm might take preemptive action by reserving blocks of hotel rooms, arranging van service, and pushing offerings to stranded traveler’s Blackberrys.  In this case your hotel chain might get a regular flow of non-discounted room sales that it otherwise might never have seen.  This would be a competitive advantage if your competition hasn’t yet invested in Global SOA.  Moreover, the Social Computing aspects of the third-party site might provide opportunities for discussion forums, linking & paging services, and other things that ultimately link customers to your reservation services.  It all contributes to helping you tap the micro market of stranded travelers.

This scenario sounds pretty good; that is until you consider the next scenario.  In the next scenario a third party developer represents an escort service that among other things bundles hotel reservations with what it sells.  While this could be a source of additional business for your hotel chain, it absolutely is not the market positioning your brand wants to be associated with. Moreover, if there are intermediaries it could take months or years before you ever learn of your “B2B association” with this escort service.  In fact, it might take a concerned consumer to write you a letter before you ever know about it.

To most executives, that’s nuff said. Social Computing seems too wild and out of control for brick-and-mortar industries.  In the end they gaze on it with passive curiosity but elect to wait until things mature more.

Combine the loss of control with the fact that other sites, possible competitors, or other commercial business will be using your IT systems as “their infrastructure” and that will really turn executives off!

Ultimately, I think the monetization storyline for Web 2.0, Global SOA, and the entirety of Social Computing has yet to be written.  I don’t think that we will see compelling monetization scenarios for the traditional brick-and-mortar industries this year.  In the meantime, we should expect Social Computing to flourish in other industries, and for many it is already a big factor.  Examples of commercially effective Social Computing investments range from video game firms to manufacturers like Harley Davidson and other consumer-based companies with a fan-club type marketing focus.  Fan-club marketing creates niche micro markets that are extremely effective for sales; in many cases surpassing brand-loyalty as a consumer decision factor.  We’re sure to see this exploited more in the coming years.  But what about Insurance, Hotel Rooms, Banking, and etc.?

At least for a while longer at Sphere of Influence we are preserving the distinction between Agile and Lean for our internal training.  Here are the definitions used within the firm:

• Agile : (1) an intense closed loop feedback circuit for the people requesting system features and functionality; (2) emphasis on accountability to business objectives & priorities; (3) minimal bureaucracy and ceremony.

• Lean : (1) streamlining productivity and quality by having less work in a pending or unfinished state and by controlling the rate each type of work enters the process; (2) pull-based one-piece flow and zero defect development processes; (3) delighting customers with speed and quality.

People are starting to associate Agile with being fast, but that’s not necessarily helpful. Agile projects are not automatically faster on paper, meaning that we don’t plan ultra-short schedules on the Gantt.  In practice, Agile projects finish earlier because the on-paper schedule tends to be more consistent with the reality of execution.  Agile projects move at a consistent pace with less slippage and greater changes of being accepted at delivery.

The real value from Agile comes from standing up a closed-loop feedback circuit and the intense re-prioritization that occurs on a daily basis.  Because of these, Agile delivers features and functionality that are spot-on in terms of matching business need with a minimal technical footprint.  Compared to requirements-up-front approaches, Agile generates fewer features but the features are more potent; thus requiring less end-to-end time in development.  That’s very different from the “waste anything but time” vision people are starting to have about Agile projects.

When it comes to moving faster, that’s the dominion of Lean. Lean focuses on purging inefficiency from the development process, mostly by cutting work that is either throw-away or do-over.  The more advanced an organization is at applying Lean - the shorter those Gantt charts can be on paper.  Lean really does affect productivity in a serious and measurable way.

The arts of Project Management and Product Development are both deeply rooted disciplines in their own right.

It has been a long standing tradition for IT departments to place Project Managers at the helm of software projects.  This practice originated years ago with government projects, principally from the DoD, where modern templates of large-scale software development and integration were etched, patterns that were later imitated by private sector corporations.  By the 1980’s government policy makers and academics were united in encouraging the view that project success and failure was predominately a function of managing the Iron Triangle (scope, quality, and cost).  It was thought that Quality could be inserted by rigor and brute force, a.k.a. Six-Sigma, CMM, ISO-9000. Attentions were turned to the Project, not the Product, as being the most important thing to manage.  The art and science of Project Management as a distinct discipline evolved rapidly and Project Management as a leadership function was incorporated into almost all government funded projects; and surprisingly, into many corporate IT (formally known as Data Processing) shops.

Despite the widespread trend, part of the commercial sector resisted putting Project Management at the top of the food chain.  Many successful technology industries, outside of IT, did not put Project Managers at the helm of projects.  Instead, they pick product champions as leaders.  These people own the “whole product” and its development end-to-end, inside and out, soup to nuts, budget to bolts.  They manage with the philosophy that the Product is the center of importance, not the Project.  The titles given to these leaders range from Product Development Manger to Chief Engineer, Head Designer, Product Lead, or Product VP.  In a “product-centric” environment, the Product is important, not the Project.  When the difference in role is more than just in name only, the Product is managed, not the Gantt; ROI is achieved, not estimated.  This approach has driven engineering productivity and product innovation in industries ranging from cameras and TVs to automobiles and everything in-between.

In places where product-centric management competes head-to-head with project-centric management, the competition is a smack down.  Whether it is Toyota’s ability to design a new car model in slightly over 1-year (whereas GM takes almost 4-years), or Burt Rutan’s building of an operational manned spaceplane for $25 Million when it takes NASA over $1B to build a barely flyable scale mockup, the results are almost always unambiguous: Project-centric management simply fails to deliver on either cost efficiency or innovation.  At the end of the day, what else is there?

The results are even more skewed when looking at software and IT products.  It is common to find cost differentials of two orders of magnitude for the same or similar functionality between projects where product-centric leadership goes head-to-head against project-centric leadership.   (Example: Page 27 of this link: Florida vs. Minnesota’s SACWIS).

IT projects are about creating products, usually one-of-a-kind products.  Success or failure is determined by a collage of factors.  Some of those factors are project management in nature such as meeting external commitments, planning resources, and adhering to budget.  However, most of the factors driving success and failure have to do with the product itself.  With an IT project, factors like meeting schedule are most affected by the content of the product and the techniques used to synthesize that content.  The content of a product and how you go about putting it there influences schedule, cost, and quality even more so than the raw productivity and the PERT.   

With due respect to the art of Project Management it is completely inappropriate for leading the typical IT development effort.  Project Management is indented to be administration, not leadership. Its purpose is to formulate plans, track progress against a plan, collect and analyze measurements, contain costs, control productivity, and apply formal risk mitigation strategies to cope with variances between assumptions and reality.  To any development effort these are all necessary administrative skills and a great PM can make a significant contribution to almost any project.  However, you don’t put a traditional heavy-weight PM at the helm of product development.  E.g. Burt Rutan doesn’t work for his PM, the PM works for him.

That’s not to say that some people with the title Project Manager aren’t secretly skilled as Product Development Managers, because many (in my own personal experience) are.  Sadly though, the practice of relying on the title “Project Manager” as the leadership role actually discourages the use of Product Development Management at the helm of a project.  In reality most project-centric environments produce mediocre products and yield projects that appear perfectly well managed until they slip near the end of the Gantt, mostly due to issues with inadequate flexibility and customer acceptance (or lack thereof).

PM’s should be at the helm of certain types of projects.  PM’s should run projects where execution is largely driven by planning and when efficient Gantt execution is the key discriminator between success and failure.  Donald Trump (on the TV show The Apprentice) uses high-dollar Project Managers as leaders quite effectively in his companies; setting up events, overseeing construction projects, managing B2B relationships, and etc. There are many types of projects in the world that can be effectively run by PMs, just not in IT.

In the real world of one-of-a-kind custom technical systems the day-to-day tradeoffs are far more complicated than scope, quality, cost, and schedule.  The tradeoffs require a deep thorough understanding of the science, skills, steps, methods, and risks inherent in that type of product.  Making wise compromises depends on adhering to a robust and cohesive vision.  A compromise to one aspect of a product must be offset by something excellent in another aspect.   

What about the Gantt?  

Gantt is not and has never been the silver bullet to project administration.  Nuff said!

Project Management is a serious discipline requiring years of training and experience, it is a career and a specialty in itself - focused on project administration and business operations.  Product Development Management is also a serious discipline requiring years of training and experience – focused on evolving ideas into technology, turning at-risk dollars into successful products acquired.

I always get asked why so many IT projects appear to be circling the drain. 

Inevitably, if a project is having trouble it is because it does not have a Product Development Manager or equivalent at the helm.  That single factor makes more of a difference than any combination of things you might otherwise do to fix or save a project.

 Agile vs Lean Software Development

What’s the difference between AGILE and LEAN as they relate to software development?

This is a common question that involves more than just a simple one-line answer.  And, depending on how you define LEAN, it could have several answers.

LEAN, at its core, is a management approach for streamlining production systems.  Lean is responsible for colossal improvements in productivity and quality over the past 32 years and is used successfully by industries that range from manufacturing and logistics to product development. 

AGILE is more of a philosophy than an approach and is very specific to software projects.  Agile encourages higher productivity and increased accountability to customers by placing emphasis on producing “real software” vs. plans, schedules, and paper.  At its core the Agile philosophy does three things:  First, it assumes that specification cannot be codified at the beginning of a project and uses intense iteration and customer interaction to identify features.  Second, it imposes extremely rigorous disciplines for quality control.  Third, it depends on having “professionals” skilled in performing key jobs efficiently.

Lean is a generic streamlining approach for all production systems, but Agile is specific to product development environments.  Agile is considered an alternative to traditional product development methodologies that emphasize BPUF (Big Planning Up Front), or as others have put it “PERT-based project management”.  Many people regard Agile to be the philosophical antithesis of the Project Management Institute’s favoritism towards plan-centric management.

Lean has a more complicated history than Agile.  Many people regard Lean to be well-established and even old because of its heritage in manufacturing and logistics.  However, there are many forms of Lean – some old and some new.  Modern Lean has three main evolutionary branches: First is Lean Manufacturing; second is Lean Logistics (a.k.a. Supply-Chain Management); and third is Lean Product Development.  Software projects should mostly be concerned with the third, Lean Product Development.

The most recent is Lean Product Development, developed byToyota Motor Corporation’s design studios.  This variant of Lean is specifically intended for designing products, not for manufacturing them.  Thanks largely to Mary & Tom Poppendieck’s fantastic book on the subject, Lean Product Development is making a strong appearance in the software industry.

At Sphere of Influence Inc. we regard Lean Product Development as more fundamental to stimulating productivity than Agile.  We generally recommend clients start with Lean and then move to Agile.  Lean Product Development initiatives tend to be more useful to the business as stand-alone items and generally pave the road for a successful Agile initiative to come later.  Agility involves a lot of religion, meaning that the menu of Practices is long and the tradeoffs are complicated with sparse evidence of what is minimal yet required.  Lean initiatives, on the other hand, focus on the core task of identifying and eliminating waste while driving key decisions outward in the development cycle.  By eliminating waste from production systems (called Value Streams) the overall objectives are more efficiently accomplished; even when Non-Agile management methods are employed.

That was the short intro.  Read on if you want more details...

AGILE

AGILE is a buzzword and somewhat of a fad, but definitely here to stay.  To the uninitiated an “agile” project evokes notions of being simple, adaptable to change, nimble, and quick (pardon the redundancy).  The term itself suggests paper-thin bureaucracies and minimal documentation; opposite of traditional heavyweight processes such as 2167-A, 496, RUP, and the PMBOK.

This is a good enough description for line-of-business (LOB) executives because it gets across some key values of Agility, particularly to someone frustrated by the foot-dragging pace and poor accountability of traditional software development.  However, this does not accurately depict what Agile really is.  Agility was not conceived from the top by LOB executives trying to make software projects more accountable; it started at the bottom with developers attempting to self regulate the out-of-control quality situation in the software industry by embracing tried and true patterns of success.  Agile was a response from the development community to address the quality and productivity problems that mil-specs, CMMI, ISO9000, and heavy-weight methods had either created or failed to control.  Since developers created Agile for themselves the entire movement tends to be developer centric.  The Practices associated with Agility address developer tasks and situations, and to a degree the tasks and situations of project managers, but do not go far beyond that.  Executives, customers, and other stakeholders are viewed as outsiders from the Agile perspective.

As such, the lofty business-centric ideals conjured up by the word “agile” are close to what Agility delivers, but not exact.  Agility is mostly a self-imposed discipline and QoS standard for use by developers and development organizations.

The Agile Manifesto itemizes its principles:

 

Principles from the Agile Manifesto

 

· Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

 

· Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

 

· Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

 

· Business people and developers must work together daily throughout the project.

 

· Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

 

· The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

 

· Working software is the primary measure of progress.

 

· Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

 

· Continuous attention to technical excellence and good design enhances agility.

 

· Simplicity--the art of maximizing the amount of work not done--is essential.

 

· The best architectures, requirements, and designs emerge from self-organizing teams.

 

· At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

 

Where the non-agile world values Process, the Agile world values People.  Where Documentation and Traceability are key objectives in the non-agile world, Working Software is the main objective of Agility.

 

  

What’s all this really mean?  It means that developers are saying “no” to big planning up front, big processes, big architectures, big binders, and big specifications.

 

However, there’s nothing directly actionable in the Principles themselves.  To convert a living breathing organization to Agile you need more than principles – you need PRACTICES.  That’s where things get messy.

 

Various methodologies (i.e. brands) have appeared, such as: eXtreme Programming (XP), SCRUM, Crystal Methods, DSDM, Feature Driven Development, Adaptive Software Development, and others.  Each of these brands enumerates its own set of practices that should be followed.  Practices include things like Pair Programming, Test Driven Development, Daily Stand-up meetings, and etc.  Some practices are common across brands, while others are not.

 

The jury is still out on how well each of the practices works and in what combination they should be adopted. Yet an organization that is adopting Agile needs to select specific practices and more-or-less adhere to them in what usually is a disruptive change to the organization. 

 

Results are inconclusive.  Some case studies indicate extremely positive results with Agile while others indicate results more consistent with long-standing industry averages.  The reality is that Agile does truly enhance a software project but achieving useful levels of Agility is not as easy as it sounds.

 

Converting to Agile is like converting to certain religions. You might agree with the principles and objectives but you end up spending most of your time wrapped up in doctrine and dogma.  Such is the case many times with Agile.

 

Moreover, executive LOB managers generally don’t wish to understand Agile beyond the simplistic ideals of adaptable, nimble, and quick.  They appreciate those high-level ideals but if you put a list of Agile Practices in front of a LOB manager – most couldn’t care less.  Agile is developer centric and as such will never be truly appreciated by most people with P&L responsibility.

 

 

LEAN

 

LEAN has nothing specifically to do with software; it is about streamlining production systems by eliminating waste, having the “right” process, leveraging people as the most flexible resource in the system, and being disciplined about “when” decisions are made.  Classic Lean Manufacturing is the five-step process of: defining customer value, defining the value stream, making it flow, “pulling” from the customer back, and striving for excellence [J.Womack & D.Jones, Lean Thinking: Banish Waste and Create Wealth in Your Corporation].

 

The main idea behind Lean is to avoid any over-production (i.e. inventories), because over-production is not only wasteful it prevents rapid response to changing customer demand.

 

Where it gets confusing is that the term “lean” was already introduced to the software industry many years ago; long before there was a concept of Lean Product Development, and before Lean Manufacturing had been fully digested by the industrial community.  The early versions of “lean” introduced to the software industry were derived from Deming’s work on team-centric management, statistical quality control, and process improvement.  It become known stateside as Total Quality Management (TQM); and TQM-style thinking was applied to everything.  Embedded as philosophical drivers into ISO standards, CMM, and Six-Sigma - Lean ideas found their way into software development in many industries.  Software projects got a version of Lean that focused on quality, not efficiency, and was ported from Deming’s philosophies on statistical quality control and process improvement and largely omitted the team-centric leadership aspects found in pure TQM.  These early “lean” initiatives pushed the software industry down a path of intense measurement, statistical measurement, heavy processes, and mammoth documentation – a path that bloated software development budgets without yielding any industry-wide increase in software productivity or potency (in fact, many think it did the reverse).

 

Meanwhile the manufacturing world was taking notice of the Toyota Production System (TPS), which began with Deming’s TQM but evolved quite independently in the years between 1950 and 1973.  The TPS became the reference model for what is now called Lean Manufacturing.  Even though you can still see the TQM roots, the core concepts of modern Lean Manufacturing are very different from TQM.

 

Lean Product Development is fairly new.  Developed in Toyota Motor Company’s design studios it is the highly successful approach Toyota uses to design new car models.  Toyota adapted key concepts from Lean Manufacturing to fit the design studio environment, which is radically different than a manufacturing floor.  Toyota’s success caused their methods to be studied and imitated by people in many diverse industries, including software.

 

Lean’s core concept of avoiding over-production appears in Lean Product Development, but takes unexpected forms.  The production of any artifact that won’t be immediately consumed is suspect of being over-production.  This applies to use cases, requirements, designs, test plans, defect reports, change requests, and other artifacts typically found on software projects.  For example, when requirements are over-produced then the project’s ability to respond to change is hampered.  The key is to regulate production of all artifacts to match consumption by allowing consumption to “pull” the upstream production process.  With Lean Product Development, requirements are specified in detail at the latest responsible moment, the moment when the most is known about the requirement and before it is needed.

 

Lean Manufacturing doesn’t make a big deal about “when” decisions should be made, but Lean Product Development does. 

 

A Lean initiative in a product development environment primarily revolves around the elimination of waste and getting quality right the first time.  The techniques employed on a Lean Product Development initiative are very sophisticated and quantitative yet not statistical in nature.  There is no attempt to impose statistical quality controls on the creative, developmental, and engineering processes.  Lean Product Development is not TQM!

 

We find that executives instinctively take to Lean Product Development much more readily than they do to Agile.  This is partly because Agility is expressed in the language of developers, not managers.  Lean, by comparison, generally makes sense at all levels...from developers up through executive officers.  Lean speaks the language of “production” without much regard to what is being produced.

 

Lean and Agile overlap in the concept of accommodating change late in a process.  The old Big Design Up Front methods are criticized for their inability to cope with midcourse change, whereas both Agile and Lean embrace midcourse change.  Lean not only expects midcourse change; it strongly encourages pivotal decisions to be delayed until the last responsible moment. 

 

A software project can be Agile without being Lean, or it can be Lean without being Agile.  There is nothing directly relating the two concepts, yet they fit together nicely in a software organization. 

 

MY ADVICE:

 

I advise clients to start with LEAN Product Development and then adapt at their own pace toward AGILE practices.  There’s a lot more bang for the buck vis-à-vis the bottom line with a partially completed Lean initiative than a partially completed Agile initiative.  Once an organization is LEAN, becoming AGILE is a step that developers can take on their own without requiring much management backing.