Using Enterprise 2.0

Continuing from my previous post, this one is more in line with the actual talk I gave on the 13th April at The Internet Show in Melbourne. We will be putting the actual transcript and slides of that talk (and video if the quality is good enough) up for people to download in the next week or so.

If you are interested in Web 2.0 and social software then you should have a look at Enterprise 2.0, which could be thought of as just Web 2.0 within the enterprise, although the originator of the idea, Andrew McAfee has a more precise definition for it:

“Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.”

He places particular emphasis on the idea that it should be emergent, and for this reason excludes traditional intranets as part of the Enterprise 2.0 toolset.

“Emergent means that the software is freeform, and that it contains mechanisms to let the patterns and structure inherent in people’s interactions become visible over time.”

The whole idea of emergence is a tricky one, but a good example is the way Google assesses the relative merit of web pages based on the number (and quality) of inbound links, something which emerges over time as people find a page useful and link to it, rather than something pre-planned and orchestrated. A more concrete example is the idea of not placing paths in a garden up front, but allowing people’s actual movement to determine where paths should be placed – hence having them emerge as real patterns of use are known.

A point worth noting is that this means that the early structure or format of an Enterprise 2.0 tool can be expected to change over time. Initially it may seem somewhat useless, and not the sort of quality resource the business hopes it will be. This is a good thing as this quote from Art & Fear illustrates:

“The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the ‘quantity’ group: fifty pound of pots rated an ‘A’, forty pounds a ‘B’, and so on. Those being graded on ‘quality’, however, needed to produce only one pot -albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the ‘quantity’ group was busily churning out piles of work - and learning from their mistakes – the ‘quality’ group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.”

The point about emergence is that it usually leads to a more appropriate and higher quality result than something meticulously planned from “theorizing about perfection”.

It is important to realise that the interactions that will take place, and help the emergence of patterns and structure, will be around ideas and especially the communication of ideas. Any Enterprise 2.0 initiative must have as its basis the ability for people to express, challenge, endorse and modify their and other’s ideas.

It can seem that some of this is a waste of people’s time, creating yet more ideas (some rubbish) for them to have to trawl through and interact with. We should remember that what ultimately matters is how it helps to optimise overall organisational effectiveness, not necessarily the impact on individual efficiency. Efficiency is one of the items that gets addressed as complexity emerges in the unstructured content that Enterprise 2.0 deals with – good tools will help you deal with this complexity.

What Can Enterprise 2.0 Do?

One of the biggest differences in Enterprise 2.0 tools is that they bring broadcasting to the average employee. This means that everyone can take advantage of the virtues of pull versus push publishing. Instead of identifying who should see something, and then pushing it into their email inboxes, or onto their IM clients, pull publishing allows the idea to be pulled into someone’s attention when they want it to be. Key enablers for pull publishing are RSS feeds and feed-readers, easily browsable content and micro-blogging enterprise tools like Yammer.

Another key difference is that most Enterprise 2.0 tools have come out of the consumer marketplace. That means they are highly usable and are designed from the ground up to be easy to learn. It turns out that’s a really important point, because it makes adoption across an enterprise much easier than most enterprise software. One key point is that the tools should address security and legal concerns, unlike most Web 2.0 tools, the content being dealt with is commercially sensitive.

Here are some business problems that Enterprise 2.0 helps address better than many other tools:

• Bring new employees up to speed
  Wikis allow corporate knowledge to be easily captured, reviewed, edited and re-published as necessary so that new employees can quickly see the latest information. Internal blogs can operate the same way, but have the additional bonus of making it obvious who knows what, which gives the new employee someone to connect with.
• Accurately forecast something
  Some cutting edge applications of Enterprise 2.0 include crowd sourcing from within the organisation, using internal prediction markets to identify probable issues or forecasting delivery dates or prices.
• Help customers
  One of the oldest Enterprise 2.0 ideas, and something pre-dating Web 2.0, self-help community forums enable customers to be helped by other customers acting as a volunteer helpdesk.
• Make things findable
  Blogs (and intranets) that implement folksonomy tagging well allow users to easily tag things to find later and make content more browsable. Good enterprise search solutions that cover blogs, wikis, intranets and other Enterprise 2.0 tools also help make things more findable.
• Broadcast ideas (pull not push)
  As mentioned above, RSS and Yammer allow users to publish content in a way that broadcasts it outside their normal circle of influence, without creating disruptive interruptions as push publishing tends to.
• Transparent project progress
  Using a wiki, blog or a simple project management tool like Basecamp to track project progress both allows the emergence of patterns and can make those visible to people outside the immediate project team.
• Communicate to the rest of the organisation
  Department blogs can act as venues for communications between components of an organisation, and capture the discussions around those communications for future users to review and understand.
• Helping upcoming leaders network
  It is well established that upcoming leaders do better when their networks are more diverse and cross organisational boundaries. Internal blogs, the comments around them and a good flexible corporate directory tool can help upcoming leaders get noticed outside their existing teams and make the connections they will require to succeed.
• Enhance employee self-learning
  I’ve mentioned before David Maister’s opinion that most training is useless and the current focus of much etraining is actually on how to teach the individual to become a better learner, rather than pushing particular content at them. Wikis, blogs and social bookmarking all place a part in enabling better self-learning.
• Improve innovation
  Innovation is done by creative people, usually passionate creative people (see my previous post on passion) and Enterprise 2.0 helps them do this by making it easy for their ideas to be shared with internal audiences to inspire and call forth more ideas from them. Any Enterprise 2.0 tool can help innovation, but the best ones are often internal blogs.

Below is a great slidedeck that illustrates how someone might use these tools:

Meet Charlie - what is Enterprise2.0?

View more presentations from Scott Gavin.

What Do I Need in an Enterprise 2.0 Tool?

What should you look for in an Enterprise 2.0 tool?

You want to start with one that is more of a toolbox than a single tool, a good start is to look for something that offers blogs, wikis and a well-integrated corporate directory. You want something that is expandable, so you have the option to add more tools later.

Any tool you choose should play nice with other enterprise software, so you should find something that offers single sign-on (SSO) with your particular network, for example Active Directory/LDAP integration and that satisfies your IT department’s security needs.

Playing nicely with other Enterprise 2.0 tools is also mandatory. In this case that is mainly done by providing (and consuming) RSS feeds and integrating with your chosen enterprise search tool, but integration with a corporate directory offering will become necessary.

Basic functionality to allow emergent behaviours is also necessary, at a minimum this requires tagging and the ability to comment on anything, but micro-blogging and social bookmarking are also good candidates for this.

If you want to try something without involving IT, then you can look at various hosted solutions (such as Yammer), but eventually you should make sure that IT is happy with your choice of tools – especially of it ends up being something that you need to host yourselves, or if it will contain content vital to the continuity of the organisation in the case of a disaster.

Do I Need It?

Small companies, or larger ones faced with large amount of routines tasks and few opportunities for passionate creative work, might find that Enterprise 2.0 offers less robust ROI than most IT purchases, but even they may benefit from using Yammer or similar low-cost, hosted tools.

Companies in highly competitive environments, where the ability to be agile and quick to react to change is important, or organisations seeking to ignite the passion of their employees and find more effective ways to work will find that these tools are indispensable in helping flatten the organisation and efficiently distribute ideas.

Untapping your people’s passion

I’m in the midst of preparing for The Internet Show in Melbourne, 13-14 April 2010. As a sponsor my employer, Elcom Technology, has several slots for presentations. We’re doing a case study on a social networking startup and a CMS clinic, but most importantly for me I am also doing a session on Web 2.0 and Social Media within the enterprise. These are the key ideas behind that talk, although this is more detailed than I will be on the day.

Passion is one of those wonderful ideas, it is hard to quantify or measure, but unmistakable when you meet it. In the business world we tend to think of it as messy, disorganised, hard to manage, hard to inspire and hard to control.

However, passion is one of the greatest competitive advantages, with something they are passionate about, people will spend more time, think more creatively and fight harder than they will with other things in their lives. It is also well-recognised that passionate employees create passionate customers, and that’s something any business should be interested in.

Deloitte’s 2009 Shift Index says that “Passion is when people discover the work that they love and when their job becomes more than a mode of income.” They describe the need for passion in terms of competing for employees:

“Why does passion matter? Because staying competitive in the newly globalized labor market requires all of us to constantly renew and update our professional skills and capabilities. The effort required to increase our rate of professional development is difficult to muster unless we are passionately engaged with our professional activities.”

A History Lesson

Around 100 years ago the Ford Motor Company implemented an assembly line in order to boost the production of the Model T. Initially, Ford raised the wages of assembly line workers to keep them interested in the innovations they were rolling out, but now we think of assembly lines as places where cost is minimised by reducing the complexity of the work across many simple steps, and therefore minimising the training (and wages) required for employees.

By simultaneously innovating to a lower price point and creating a middle class that could afford their product, Ford managed to reach a dominant early lead in the production of motor cars. This precipitated a movement from craft production to mass production and in large part was based on scientific management, a term coined by Frederick Taylor.

The motor car industry might have continued in this vein forever, except for the advent of the Toyota Production System (TPS). The founders of Toyota were unimpressed with Ford’s assembly line, but found a way to improve it greatly. Their ideas were wildly successful and a host of studies tried to understand the core ideas in the TPS in order to apply it in the western world. Thus we received just-in-time manufacturing, total quality management, continuous improvement and lean manufacturing.

Most of these ideas have failed to find as fertile soil in the west as they did in Japan – however the evidence is that the difference is not cultural (Toyota runs plants in America run as well as they do in Japan), predicated upon Japanese corporate solidarity, or based on some secret sauce hidden from researchers. In fact the key items were in plain view all the time, but hidden by the biases the researchers brought with them.

There are two key differences they ignored:

1. People Management

The first key difference was the way people were treated. In the TPS people at all levels are valued and given control of their area of work. For example, an assembly line worker is able to shut down the entire line if they find a defect, and will then be part of the team tasked with finding the root cause of that defect and solving it.

2. Practice Makes Perfect

Another key difference is that the Japanese understood W. Edward Deming’s statistical process control methodology, and saw their assembly lines as being imperfect and in need of continuous improvement, rather than the perfectly defined processes that scientific management assumed.

An illustration of this is the pottery class that was split 50/50 between students who were told they would be judged on the quality of a single pot at the end of the course, and ones that were told they would be judged on the quantity of the pots they produced. The ones who focussed on quantity ended up producing better quality pots because they learnt from each one they created, whilst the others got stuck in trying to create the single perfect pot first time.

Eventually in the mid-80’s, Ford asked Deming to help them turn around their quality problems. They were surprised when his focus was on their management methods, but his influence was quickly seen in the profitable Taurus-Sable line.

Today these principles are working their way into other areas of work, through Agile software development and the general concept of Lean. An important key concept is the idea of waste – whether it be spare inventory, transportation, defects, unnecessary motion, over-production or over-processing. The well-known Scrum methodology lists three important pillars for empirical process control:

1. Transparency
   Know what is happening and be able to measure everything.
2. Inspection
   Regular and frequent inspection of the process to ensure it is functioning without waste.
3. Adaptation
   Adapting the process to remove any waste.

So What?

A big part of Deming’s management principles was helping people re-discover “pride of workmanship” (or passion!) in their work, and removing barriers to them doing this (e.g. work standards, quotas, annual ratings, management by objective, etc.), substituting leadership for those barriers.

Whilst Deming’s methods have transformed the manufacturing industry, with companies like Dell and Boeing taking lessons from the TPS and applying them well, there are many industries where Taylor’s scientific management methods still rule, mostly because of habit and management (mis)training.

I know that I learnt how to manage very much in line with scientific management techniques (mainly by osmosis from poor managers). Plan, control, punish, reward, etc. The reality is that there is a shift in our working lives, we need more passionate creatives than ever, more artisans or craftspeople than unthinking drones. There is scarcely any industry or business that does not need at least some of their people to be passionately involved, engaged and thinking outside the box.

That last point is key to applying this. For some organisations the amount of passionate creative work that overlaps their routine work is minimal, for others there is almost a total overlap. The trend is towards more passionate creative work, and we will see that increasingly the leaders in their field are organisations that tap into this and harness it properly. Ford’s initial success in keeping their assembly workers by doubling their pay was short-term, soon the rest of the employment market matched their wages and the middle class expanded rapidly thereafter.

Your efforts need to match the amount of passionate creative work that overlaps routine work in your industry – but don’t shy away from finding ways to move away from the industry average and get more creative work in there.

How Can We Do It?

The question is how do we help people tap their passionate creativity in the workplace so they want to stay?

We need to go back to the basics of good management again to find out what really motivates employees. Daniel Pink talked about this at TED in August last year.

 

“There is a mismatch between what science knows and what business does. And here is what science knows. One: Those 20th century rewards,those motivators we think are a natural part of business, do work, but only in a surprisingly narrow band of circumstances. Two: Those if-then rewards often destroy creativity. Three: The secret to high performance isn't rewards and punishments, but that unseen intrinsic drive. The drive to do things for their own sake. The drive to do things because they matter.”

In summary Daniel points to three key ideas for managing people in the 21st century:

• Autonomy
  The urge to direct our work and have some say in what we do.
• Mastery
  The desire to get better and better at something, to make progress and overcome challenges.
• Purpose
  The yearning we have to work in the service of something greater than ourselves.

There was some interesting research reported in the Jan-Feb 2010 Harvard Business Review that supports the power of mastery in motivating employees:

“On days when workers have the sense they’re making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak. On days when they feel they are spinning their wheels or encountering roadblocks to meaningful accomplishment, their moods and motivation are lowest.”

Deloitte’s 2009 Shift Index had similar findings about autonomy and mastery:

“24 percent responded that flexibility, freedom, and autonomy were the reasons they “loved their job.” Similarly, 23 percent of the respondents cited challenges and opportunities for problem solving and creativity as the reasons they loved their job.”

These keys can all be found within the TPS, and are the foundation of any great 21st century business. If they can work for assembly line workers in one of the world’s largest car manufacturers, then surely they can work in our office environments?

More to the point, if we don’t offer work environments that have these keys, then we can expect to see more of our best and brightest leaving to go freelance, or joining that new startup, or even finding a big company that gets this idea.

Getting a Leg Up from Enterprise 2.0

I’m a Technical Director, so of course at some point I want to see just how technology can help us, and in this area as so many others there are some interesting possibilities thanks to Enterprise 2.0.

Learning

Modern creative work places a huge demand on people to be constantly learning, diversifying their experience and increasing their speed of uptake of new ideas and skills. More then ever before success demands that people self-educate themselves, and with information overload and the skyrocketing complexity of our global business environment (where your competitors may just as easily be half a world away as down the road) that is harder than ever.

Enterprise 2.0 offers lots of help in the area of learning and knowledge transfer.

• Wikis
  These are great for helping people record their knowledge, and then allowing that knowledge to be reviewed, improved, updated and generally kept alive.
• Blogs
  Fantastic for putting ideas out there and getting feedback on them. They can provide employees with acceptable avenues for bridging great gaps in relative seniority (e.g. letting a new hire question the corporate vision statement) as they can allow people other than the original author to respond and correct mistaken ideas. The ability to browse posts by chronology and/or tags means that content is more usefully categorised than it would be in an email inbox.
• Social Bookmarking
  Whilst bookmarks can be overrated, if properly categorised and rated, they allow people to make new information available to their colleagues and can act as scent as to who is most interested or interesting.
• Enterprise search
  Having an effective and useful enterprise search tool is a must-have Enterprise 2.0 tool. Most Enterprise 2.0 content is unstructured and a good search tool is essential to ensuring that people find the right content when they need it.

Networking

There is a need for us to connect with ever greater numbers of people, and being increasingly time-poor to find the right people to connect with. Research has shown that high performing individuals maintain better networks than others, and in particular that their networks are more diverse/disconnected. This allows them to “see the big picture better, generate innovative solutions by integrating the expertise of those with unique backgrounds, position their efforts well, bypass bureaucratic gridlock and obtain necessary resources and support.”

Enterprise 2.0 makes it possible to find the right people in your network by reviewing their ideas and following the commentary and discussion about those ideas. It also helps people develop connections beyond their immediate team or management hierarchy.

• Corporate directory
  Having an active and useful corporate directory, one that tracks projects worked on, positions held and teams an individual has belonged to can help identify key people.
• Employee pages
  Giving employees their own page to talk about themselves can be risky, but for those passionate creatives it can offer a way to get their ideas out there, attracting others that have similar interests and passions.
• Blogs
  The commentary and discussion facilitated by blogs, along with their attachment to individuals (and hopefully the corporate directory), makes them an ideal place to connect with others and find out who else you should connect to.
• Yammer
  Internal tweeting tools like Yammer offer interesting possibilities as people can follow who they like within the organisation and find out who is following them.

Managing Autonomy

One of the main reasons people fear worker autonomy is that they will lose oversight of what is going on. Obviously implementing transparency properly means this is not an issue, but there are problems with managing transparency when collaboration is limited to email inboxes and offline meetings.

Enterprise 2.0 offers ways for collaborative work to be both done at a distance (of either time or place), and to be recorded in ways that allow for relatively easy monitoring by managers who want to help ensure that responsibility is taken seriously and known problems are not repeated.

• Wikis
  Tracking progress on a wiki gives managers insight into what is happening and an avenue for querying ideas and outcomes.
• Online document collaboration
  Collaborating on a document online makes the draft version available to people beyond the immediate team, often in a read-only version.
• Basecamp
  online project management tools like Basecamp are highly regarded for their ease of use, simplicity and ability to facilitate complex project discussions and task workflow.
• Google Wave
  Still in Beta, and with real performance and usability problems still, Google Wave offers interesting possibilities with low-overhead asynchronous conversations organically evolving into rich document collaboration opportunities and even real-time conversation.

Making Progress

We have seen that a key motivator is the sense of making progress, achieving real results and conquering challenges. One way our current systems can rob us of this is by interrupting our state of flow and causing us to drop out to check something that turns out to be unnecessary – it is estimated that a 1 minute interruption kills 15 minutes of productive time. Two deadly forms of this are unimportant emails and face to face social desk visits.

Enterprise 2.0 tools can help reduce the amount of email flow by moving items to more useful forms of communication that rely on a pull method of distribution (where users choose to use it), rather than the invasive push method employed by email.

• RSS feeds
  By eliminating the push nature of methods like email, RSS feeds give a generic method for tools like blogs and wikis to make their data available for the user when they want it.
• Yammer
  By bringing micro-blogging to the enterprise tools like Yammer remove the instant interruption hassle of instant messaging (IM) and provide an outlet for broadcasts of ideas that may be useful, but don’t need to be considered immediately.

Enterprise 2.0 tools can help move social interaction away from invasive face to face time in the office to more asynchronous means, or at least ones that include less wasteful interruption time.

• Yammer
  Social engagement via micro-blogs like Yammer is ideal because it is asynchronous, based on the push/broadcast mode of communication and carries an implicit understanding that it is not important content.
• Intranets/Wikis
  Placing social event information online, and providing interactive photo galleries can help reduce the amount of social interaction that must occur face to face.

In Summary

Deciding to manage work empirically, through transparency, inspection and adaptation can help give your employees the sense of autonomy, mastery and purpose that is necessary to untap their passionate creativity.

There are key ideas I have not covered here, such as the willingness to accept failure as learning experiences, the need to align authority with responsibility, and responsibility with ability that must be addressed for this to work well.

However untapping passion is not only possible, but well within our reach. It fundamentally depends on the willingness of senior management to set the direction, free their people and unleash their own passion.

Finally, Enterprise 2.0 offers some interesting tools to help manage and enable this change in our organisations. But as ever, technology plays an enabling and supporting role rather than being the driver of true change.

Thanks

There is a lot packed into this particular post, but a few people were key in helping me understand these issues.

Jason Yip, from ThoughtWorks Australia, whose passion for Lean got me interested in looking at Agile software development and whose ideas and blog have helped me work out my own thinking.

Lachlan Heasman, also from ThoughtWorks Australia, who runs the Sydney Scrum Meetup, and is a good friend and great Scrum trainer.

Craig Bailey, who in a year as my boss ignited hope in me for great managers once again, and who has gone on to embody following your passionate creativity wherever it may lead.

Chris Scoggins, my first great manager and a great example to me of how to mentor and build leadership into your staff.

Daniel Pink for bringing the hidden truths about motivation into plain view, and pointing out the Emperor’s New Clothes of management.

My Dad, for always making me question what is true, and helping me understand my own passionate creativity.

Goals, Behaviours, ROI and Testing Ideas

You're developing a great web application, training course or social software strategy. You cost it and it looks like a substantial piece of work, so you need to get executive approval. Putting together a list of the benefits you find to your dismay that the list is full of terms like "easier", "more efficient", "more usable" and "collaborative". You know your executive will ask questions this list doesn't answer, "How will you know you're successful?" and "What's it worth to us?".

There are two common (and wrong) approaches to this question:

1. It's Web 2.0/training/social, it's intangible and can't be measured.
2. It should add to the bottom line, so just measure revenue changes.

The first one incorrectly assumes that intangibles can't be assessed, but market analysts know that they certainly can, and indeed regularly are, just ask what Google's stock valuation is based on.

The second one jumps to the über-goal and ignores the fact that as everything the organisation does can potentially affect revenue, it will be nigh impossible to really know whether any change in the bottom-line is the result of this particular web application, training or social software strategy (you can easily have a great success in one area cancelled out by a horrible mess in another).

Fortunately this problem is well known. Unfortunately the answer is hard. That is, hard as in deciding what you want for your birthday, not hard as in needing a PhD in Applied Rocket Science.

Find your desired user behaviours

The bottom line is that you need to find what change in user/trainee behaviours will support your business goals and then use that to derive metrics that can be measured (and eventually valued).

David Maister talked about the importance of identifying desired behaviours in his article Why (Most) Training Is Useless.

There is no point putting on skills training if there is no incentive for the behavior; the people don’t believe in it and they don’t yet know exactly what it is they are supposed to be good at! ...

What behaviors by top management need to change to convince people that the new behaviors are really required, not just encouraged? If the behavior is going to be optional, then so should the training be.

In other words, if we don't know what behaviours we want training to encourage, or if we don't actually support the display of those behaviours (e.g. through measurement and feedback) then we can't expect our training to actually help our business goals.

In exactly the same way software applications (not just web or social ones!) are often built without thinking what change in user behaviours is really desired or how the change in user behaviours will be measured - thus guaranteeing that even if success is achieved there is no way of valuing it.

ROI for difficult stuff

Adaptive Path introduced a way of valuing user experience by reflecting on the change in behaviours we desire to solve our business problem. They gave us the graphic below as a way of envisaging how business problems map to user behaviours and how they in turn can be mapped to valuable financial metrics.

 Source: Adaptive Path

via Marina Chiovetti at ThoughtWorks

• Business Problem = a specific problem you want to affect
• User Behaviour = a change in user behaviour that would introduce the effect desired
• Behaviour Metric = a way you can measure the change in user behaviour
• Value Metric = the dollar value we can apply to the behaviour metric
• Financial Metric = the expected amount of user behaviour change to come from the project, multiplied by the value metric and compared to the expected cost of the project

A specific example might help make this clearer. Imagine you want to increase leads and you decide to do this by improving your website's ability to elicit customer responses via the contact us form:

 Source: Adaptive Path

If we add some case studies to the website, and then place the contact us form at the bottom of each one as a call to action then we might expect some increase (assuming this was a new initiative for our website).

The behaviour metric for this is the number of leads received from the website contact form per month. Our sales team has estimated that 1 in 10 leads becomes a sale, worth on average $1,000 to us (whether revenue or profit depends on what you are most interested in - the smart money is on profit though).

Based on our website's traffic patterns we expect to increase our leads from 7 per month to 20 per month by implementing this measure. If we are happy to get a breakeven return on investment (ROI) over the next 3 months then we could invest $1,000 * (20 - 7) * 3 = $39,000 in the project.

Before someone tries to tell me I don't know how to value project returns, I know that you could use Net Present Value (NPV), Internal Rate of Return (IRR) or other methods to ensure this is comparing apples with apples across projects, time and investment opportunities - but that's not the point of this post.

Now we might well spend a fraction of that on case studies and a contact form, but if we wanted we could now justify getting a professional copywriter to help shape up our case studies and spend a bit on usability testing to ensure our contact forms get out of the way and give us the leads as easily as possible.

Okay, okay, this is a fairly simple example, with straightforward metrics. After all, we might well not know how much a lead is worth, and often we're asked to solve business problems far more complex than this one.

What if I’ve got no history (i.e. I’m a startup)?

We have used this process with startups to help them prioritise wildly diverse feature lists when they do not have the budget to afford to build it all in their launch timeframe.

(Aside: There is a lesson here about launching a simple, compelling product and then iteratively adding value to it based on user feedback, the problem is that in many startup ideas there is usually no simple, compelling offering. It's the fault of funding requirements, but more about that in another post.)

Startups do not have financial history to fall back on, and even with good financial modelling they might only have a guess to give you for their value metric. In this case we take the prioritisation this gives us and keep the rest of the information for analysis of the success of the startup down the track and (as importantly) for helping us identify which changes we should look at implementing later.

What if you don’t know what to change?

The methodology is still useful even when you have a complex situation with incomplete information. If nothing else it focuses your attention where it belongs, on the problem you are solving and the user/trainee behaviours that you think will help solve it rather than on the application technology or the subject matter of your training courses.

Of course you often don’t know what to do to create a particular desired behaviour. In this case a bit of prototyping and A/B testing can go a long way. Google Website Optimizer does a great job of helping you do this with content or separate functional pages, but it does require two separate pages exist, and sometimes you just want to tweak the way a particular feature works (e.g. adding a couple of extra fields to a form).

Assaf Arkin has created a plugin for Rails called Vanity that supports A/B testing in a rather unique way, by creating an easy way for developers to embed the tests into their code and then run them for a set number of iterations and/or exceed a set probability for one option over the other.

By using a simple API, and elegant admin functionality, Vanity provides a very viable way of testing one idea against another. While the time to make such a change is greater than not doing the A/B test – the marginal extra cost is small enough that you do it in order to find out which option really works better.

Assaf has a great post explaining how this is really Experimental Driven Development in action. He explains the cost/benefit tradeoff this way in the comments section:

“You start with an idea for a change that will improve your software. Your baseline cost of development is having both alternatives — before and after the change. Without EDD these alternatives will be separate in time, with EDD you’re going to have some overlap (the duration of the experiment).

For the experiment, you only need a skeletal implementation, you’re not committed to fully developing the feature until after it proves itself. For small changes it makes little difference, the cost is the same.

For complex changes, you can save a lot by not fully developing features that don’t matter. You’re going to know whether a feature matters or not quickly enough, and with data to back up, that you can make the decision to *not* develop it further.

You can also kill unused features early. So these are two ways to reduce development costs using EDD.”

Summary

Get behind whatever you are doing and try to understand the underlying business goals, the user behaviours that would support those and derive the ROI from that. If you are not sure what would best support the change in user behaviours, then try A/B testing to establish which way you should jump. Whatever you do, don’t allow yourself to be sucked into doing something just because your competitors did, or to be “simpler”, or more “usable” in some undefined, unaccountable, way.

When Agile Doesn’t Work

I am a huge fan of Agile software development and since becoming Elcom’s Technical Director I have made it my business to push us to become more Agile at every step. But a few months ago I realised I was pushing a square block into a round hole.

It started with a realisation that most proponents of Agile software development had a common single clause that modified their promises of great results.

Customers must get involved for Agile to work.

In Scrum it’s the Product Owner, and it must be the single wringable neck – the person accountable to the business for the project’s delivery of real value. It is the person who not only understands, but can make decisions about functionality, business needs and the user interface.

Oops.

While this sounds great, and you would think that people paying you tens (if not hundreds) of thousands of dollars would want to get involved, we had found all too often that big promises of ongoing involvement disappeared as soon as the project kicked off. Clients wanted to tell us what they wanted, approve our quote, pay us the money, and then pretend we didn’t exist until we had finished their project. Or they had a committee of thousands that wanted to give us their pent up IT requirements, regardless of whether it was in scope or not, and often in conflict with each other.

To be fair to our clients, we often are simply implementing our software and the amount of customer involvement is quite low – however that didn’t fit the Agile methodology we wanted to work within.

Things became clearer for me when I attended a ThoughtWorks Quarterly Technology Briefing in Sydney, and got the chance to hear Martin Fowler speak about how to fail in Agile adoption. During the Q&A I asked him how he suggested we handle customers who were reluctant to get involved.

Martin pointed out that there are in general two sorts of projects:

1. Strategic: Key to business success, and as such important.
2. Infrastructure: Necessary to do, but not seen as particularly vital for business success.

Immediately I saw that for many of our clients their projects were internally seen as necessary (new intranet, re-skinned website) but were not particularly risky or impactful on the organisation’s success. I mulled that answer over for a while and wondered what it might mean for our use of Agile.

A few weekends later I was re-reading David Maister’s classic book Managing the Professional Service Firm and came across his definition of the three basic types of professional service delivery. He writes for any type of professional service and uses examples from disciplines as far apart as architecture, accounting, engineering and management consulting to make his point.

Brains/Expertise

• Client problem is at forefront of professional or technical knowledge
• “Hire us because we’re smart”
• One-off projects
• Highly skilled and highly paid professionals

Grey Hair/Experience

• Clients require highly customised output, more familiar problems
• “Hire us because we’ve done it before”
• Specialised knowledge in project area
• We sell our knowledge, experience and judgement

Procedure/Efficiency

• Client problems are well-known and familiar, solutions also well-known
• “Hire us because we can do it for you”
• Repeat projects, well understood, standard solutions
• Well trained and supervised junior staff

Maister points out that you can see a continuum from Brains to Grey Hair to Procedure for a range of different service features.

Using this idea, I could see that most of the “infrastructure” projects we had involved procedure or efficiency services. A simple deployment of CommunityManager.NET with implementation of a specified basic website design and some custom styling of forms and other modules. Agile simply slowed these projects down and was generally ignored by the team doing most of this work.

On the other hand some of our custom development work fell into the realm of grey hair or experience services – enhancing or extending CommunityManager.NET for a client. These usually did not need to be Agile projects, but were being forced into our product sprint cycle, even when they were a day or two of custom work not dependent upon enhancements to our core product.

Our product work deserves a mention here. Whilst not for any specific client, this is in fact the work that provides the greatest return on investment for the business. However a need for cash flow meant there was a limit to how much could be done at any given time. We had a settled sprint duration of 6 weeks (5 weeks dev + 1 week regression testing and release preparation), wit 1 week in between sprints, that the team had a good rhythm with. Agile was a great fit for this work.

After this analysis there was a small, but important part of our business. Small in terms of number of projects, but important in terms of revenue. This was the projects that involved significant custom development work and had little dependency upon CommunityManager.NET. Sometimes these jobs could have been delivered without our product at all, but using it gave a convenient head start to the project. These projects were strategic to the client, but as a result often had loose, or non-existent requirements because it was acknowledged that the requirements would change during the course of the project. This type of work suits Agile methodologies, but the business needed to recognise that this work shouldn’t be sold the same way our other services were.

Clearly Agile suited some parts of our business, but was a poor fit for others. Our sales material made a big deal of our Agile methodology, but it was not always relevant or appropriate for our clients. Worse, working in an Agile manner was causing many projects to have a greater chance of failure, and to delay client solutions.

Agile Wasn’t Working

I now knew why Agile wasn’t a great fit for much of our business, but it still had value in some areas. Maister also made the point that when for a professional service firms to mix Brains, Grey Hair and Procedure work successfully it is necessary to create divisions within the firm to allow each to have a management style and culture that fit their style of work.

I really like the way that Jurgen Appelo organises his development teams, with a project manager assigned 3-5 other staff as their permanent team, with them needing to complete each of their projects using that team. By pushing resource constraints to the lowest level (that of the project team) they ensure that other projects’ resource variances do not adversely affect them. However I know that Elcom is much smaller than Jurgen’s company, and such a profound shift would create more friction than it would generate in gains.

I discussed these ideas with my boss and some of my colleagues, but felt that we quickly needed to make a change as a large custom development project was about to kickoff its second stage.

The team structure we are now heading towards is this:

Delivery Team

This is a team made up of web designers, front-end web developers, and .NET analyst/programmers. Their role will be to implement new customers’ versions of CommunityManager.NET as painlessly and efficiently as possible. They will handle custom development work that is tightly integrated to, or built around, CommunityManager.NET. They work in traditional BUFD (big up-front design) projects with well-scoped requirements. Project duration would usually be anything from 1-8 weeks.

Solutions Team

This is a team made up of user experience (UX) consultants, designers, and web developers. It is the renaissance team that is responsible for finding new ways to deliver innovative solutions for strategic client problems using design thinking and Agile software development methodologies. They work in a more flexible manner, preferably with a pseudo time and materials approach, with the client purchasing entire sprint’s worth of work. Project duration would usually be more than 12 weeks, with usually two week sprints.

Product Team

This is a team made with a web designer, front-end web developer and .NET developers. It is responsible for enhancements to, and strategic development of our products, particularly CommunityManager.NET. They follow an Agile software development methodology and are very much the traditional product-centred Agile team. Sprint duration would depend upon the ability to regression test in a timely manner – but for the moment this would be around the same 6 week duration we had used previously.

Right Now

When we first made this change, there wasn’t enough strategic product work for us to justify having a dedicated Product Team. Instead members of the Delivery Team are made available as and when required to work on the product. We still have 6 week product sprints.

The Delivery Team has started transitioning away from Agile, and their time is now more easily shifted from one piece of client work to another (they previously were committed  up to 6 weeks in advance for a particular sprint). Our clients have started to notice that we have become more flexible and responsive to sudden requests. Our project managers have been learning a new resource planning tool which is slightly clunky (built in Excel, requiring double data entry) but that we soon hope to replace with a more effective system.

The Solutions Team has had some success working in a more Agile manner, but they need to learn to do it without the moral, emotional or practical support of the rest of the technical teams. By removing many of the restrictions that product work placed on them, they are now free to explore new technologies and test them in practice before we roll them into our products. For instance they have used Domain-Driven Design (DDD) and LINQ2SQL.

The teams are differentiated by more than just name. They have different KPIs, different management styles and different things to get good at.

The Delivery Team needs to become more process-driven. Too many things are left to individual choice when the best solution is already known and has been tested in practice. Also documenting requirements up front is a skill set that needs to be re-discovered and applied. After all if you are going to do BUFD projects then you need to be good at it.

The Solutions Team needs to become more Agile, and look at ideas like TDD/BDD and more comprehensive automated testing so that short sprints do not lead to a reduction in quality. Selling a job as an Agile development project is proving harder than we would have thought. It seems lip service to Agile is easy to sell, it sounds good and requires few changes in the way clients work. Real Agile development requires an altogether different mindset, and this is much harder to sell up front. We may well need to lead these projects with an initial fixed price project that uses BDUF, and then transition to a more Agile approach once we have some credits in the trust account with our client.

The Future

The Solutions Team will be undertaking a major strategic product initiative for Elcom over the Christmas period and will bring their Agile approach and technical expertise to bear in order to give us a major new element to our product for CommunityManager.NET version 7.0. After this we hope to have another major project lined up, but if not then they may become our Product Team.

If another Solutions Team project does come up, then the next step will be to create a full-time Product Team. We believe that version 7.0 will create enough demand that a full-time team will be justified. An important part of this strategy is to find partners that are comfortable enough implementing CommunityManager.NET that our Delivery Team is not a bottleneck on our sales. One of the keys to version 7’s success will be the way that it makes it far easier for digital agencies and systems integrators to use our product for their own web projects.

After that fame, fortune and fun might consume our days – or more likely we will find ourselves looking beyond enterprise content management to create a new market niche in the manner of good Blue Ocean strategists. Whatever we do, Agile will remain a part of it, but only when it deserves to be.

bCisive gets the Minto Pyramid Principles

One of my favourite Australian software tools is bCisive by Melbourne company Austhink, led by Dr Tim Van Gelder.

They have recently announced that they have “entered into a Memorandum of Understanding to collaboratively produce a Minto software product based on the Minto Pyramid Principle^® and Austhink’s bCisive product”. This is great news as it joins the easiest argument mapping tool (I know, I've tried lots of them, including Standpedia, which looks like it died at the end of 2007) with one of the pioneers of informal argument mapping in the business world.

I first came across Barbara Minto years ago when my Dad loaned me her Pyramid Principle book. I lost that first copy, but replaced it and got my own as well. It really should be mandatory reading for anyone who ever has to write a proposal or training document.

Below is a screenshot of a product strategy bMap (bCisive argument map) I prepared for our TrainingManager.NET product:

The user interface does a great job of getting out of your way, but being accessible when you need it. The two orange buttons at the bottom of the window open panels that help you create and report on the bMap you have created. The zoom slider control makes it dead easy to change perspective and the graphical navigation tools are well thought out and consistent with programs that solve similar problems.

Having just gotten used to Office 2007 I find the user interface style of bCisive to make a lot of sense to me, and it is quite easy to use. This does for argument maps what PowerPoint did for slide preparation - it takes it from the domain of experts (or highly motivated amateurs) and puts it in the hands of everyday business users.

If you want to give it a try, bCisive allow you to use a trial version for 30 days.

Om's got the wrong business model for Twitter

I've been spending a lot of time recently looking at product strategies for Elcom, so I was particularly intrigued by one of Om Malik's latest posts that highlighted a business model for Twitter in the midst of their Scoble Problem. He says that he has “a theory that could help Twitter solve its scaling conundrum and also help the company make money”. What he's referring to, of course, is the rather expensive impact that a popular user like Robert Scoble has on their infrastructure.

Twitter (see my feed in the right hand column of this blog) is self-described as essentially a messaging system built on an architecture that better suits a content management system. This means that every time someone tweets, a record is created in a database, and then subsequent to that, tens, hundreds or thousands of messages are sent regarding that tweet - potentially creating their own database records along the way. Unfortunately Scoble has 25,000 followers, so every post from him involves 25,000 messages (and possibly text messages to mobile phones).

“Of course, Om's answer is completely wrong.”

Om says that the answer for Twitter is to view commentators such as Scoble as cash cows, and charge them for the right to have a certain number of followers. Of course, Om's answer is completely wrong. Twitter needs Scoble much more than he needs them. Why should he pay to have followers there? There are dozens of startups waiting for someone like him to to give them the techies' equivalent of an Oprah moment.

Om is right in one sense, the answer to Twitter's business model is hidden in the Scoble example. Instead of charging Scoble for the right to use their system, they should charge people who want to follow Scoble - beyond perhaps the first hundred or so. This allows anyone to use Twitter (helping network externalities along), whilst ensuring that the really heavy loads on the system are paid for, but by the subscribers to the content producers, not the content producers themselves. Another problem is that anyone could create masses of bot accounts to simply drive up your least favorite twitterer's monthly bill.

“That's almost ten times the income without annoying Scoble”

Instead of charging Scoble $10/month for 1,000 subscribers, giving them $250/month, they could charge the people that want to follow Scoble (past the first 100 or so) 10¢/month each, giving them $2,490! That's almost ten times the income without annoying Scoble, by simply asking people to pay a small premium fee if they want to know what Scoble is thinking right now. With that model they can grow as much as they like, and encouraging people like Scoble to use Twitter becomes a win-win proposition.

They are left with a micro-payment problem, but if people follow more than one interesting twitterer then the payments will quickly add up, and with volume I'm sure you could make credit card companies your friends. Besides, you could probably inflate my 10¢/month to 50¢/month with no great outcry. Now Scoble might get annoyed if suddenly 20,000 of his followers disappear, but then again, at least he knows the other 5,000 place a real value upon his tweets - and that's worth a whole lot more in media terms.

[UPDATE: It seems Scoble's already gotten annoyed ...]

Rewarding failure

In a recent interview CNET's Dan Farber asked Lloyd Taylor, VP of Technical Operations at LinkedIn “how do you create that culture of innovation in these different places that you go, how do you inspire people to kind of break all the rules?”

“The culture needs to reward failure. That is the answer.”

Lloyd Taylor
VP of Technical Operations at LinkedIn

Innovation more diffuse than we think

Scott Berkun is researching innnovation for a book. I've mentioned that before. He has come to an interesting point of view on Gutenberg's contribution to the innovation of the printing press:

“Like many myths of innovation I’ve discovered in researching the book, it was socially and politically convenient for Western society to consolidate the development of printing under the heroic image of a local sole inventor, rather than the more accurate truth of printings development by many people primarily from foreign cultures.

The Internet age is filled with similiar conveniences in assigning credit for things like the Internet, the web browser, and the PC.

Who do you think is overrated in their influence today? And why?”

My money's on Dave Winer being credited for RSS. The difference is that in the internet age people find out about the concentration of credit much earlier (it happens much faster) and some people are just ornery enough to want to make a fuss about it. For RSS, my point of view is that Dave helped create a great platform, but a lot of other people took it beyond his vision to something much more interesting.

Innovators wanted: get interviewed in a book

Scott Berkun, project manager extraordinaire, has put out a call for people with good innovation stories:

“The survey is a scant 15 questions long, and should take less than 10 minutes. If you give high quality answers, odds are high I’ll want to chat with you 1-on-1 over e-mail or phone, and may use your material in the book.”

Please note that the deadline is Friday the 18th of August.

I was a bit depressed to realise that I can't think of anything particularly brilliant to put in - but then I remembered that yesterday my son created a mock flatscreen TV from a picture, some tissue paper and even included a remote control (made of an egg carton).