One Less Cut In A Thousand

It's not Email vs Social Media, it's tools for jobs

2011-11-25T16:01:00.000Z

This post http://t.co/pTgTLA79 got me thinking and talking to a couple of customers this morning. In it:

Mark Zuckerberg talks about replacing email with something more immediate and clearly, for him, Facebook's new messaging service is it.
The Microsoft guy then pours cold water on it - understandable given the amount of revenue Microsoft get from licensing Outlook, Exchange and the servers that power corporate mail all over the world.
The (ex IBM) guy who invented MIME points to (IBM's) LotusLive, which is lovely and largely irrelevant to most corporates for whom Notes is a tainted if not poisonous chalice of end user computing proliferation.

I totally buy a few things in this article. I think the move towards conversations in a shared, protected environment is going to continue as users see the benefits of being passive participants in conversations; the 'ambient information transfer' argument. Users will also become more comfortable in such an environment, meaning they'll contribute more.

The argumemt, "email vs social media" strikes me as a bit bizarre. It's like saying, "Is a letter better than going to the pub with your mates? Or having a meeting?".

Well, it just depends what you want to achieve.

For a start, the idea that email is somehow going away doesn't fly - but there are plenty of things done with email today which it isn't that great at. Products will come along that replace things users currently do with email.

This is already happening; before Twitter, how else would you share an interesting link? Blog it? Email out your blog?

And it will happen in other areas.

For example, it gives users control of their workflow; often users will create filing structures within email to allow them to rapidly locate information. I did it myself until around 2008, at which point search and filtering got good enough for me to find what I wanted without filing it. Normally, if I can remember the context of an email then it can be retrieved, even if if means searching on a name, then spinning through a couple of pages. Better than being a filing clerk.

Another example: email is a singularly terrible way to talk about anything to any volume of people. If you're not on the list, you don't know it's happening. If it's in your inbox and nowhere else, it's impossible to share the knowledge. Replies get crossed all the time ("with respect to Dave's point in his third para").

A decent collaborative enterprise platform kills both of these uses of email. But it will have to ensure that:

Collaboration has to be based around work; it has to be in shared data & communication environment rather than simply a messaging environment - it has to be real-time, capable of dealing with multiple conversation threads
Communities of users are able to freely form and create new knowledge from existing data, so the user community becomes the filing system
Enterprise search is powerful enough to render filing a waste of time

Email remains pretty good for private communications - personal or enterprise confidential items you don't want to broadcast. (Of course, it's sensible to assume that everything gets leaked eventually.)

But in all other areas, it just needs the right product to topple it.

Lessons from teaching myself to run again

2011-11-11T16:00:00.000Z

I've been running on and off for nearly 30 years - but more off than on. My whole family have had been runners at some point, undoubtedly due to Dad who's still a dedicated runner now as he gets towards 70. In my teens I was quite into it and could do an 11 mile run over pretty serious terrain at the drop of a hat.

So I've always been working off a base of assumed competence - like a lot of organisations. No-one ever taught me to run - certainly not Dad, who could 'just do it'. As so often seen in other disciplines, if it comes easy to you, you've probably not gone through a learning process to become expert in it, and so you're not best placed to teach excellence in it.

But my running has been more off than on. Allowing for a mis-spent late adolescence and early adulthood, it's been off and on for two reasons; lack of pace and recurrent injuries.

Over the last few months we've finally nailed the right asthma medication for me. Of course, my asthma was fine; I was running every other day, usually comfortably. But the nurse said, 'all very well but you're running to your limits', i.e., without the right meds there was no knowing what my potential was.

The other breakthrough was finally teaching myself to be a forefront striker; I now land and push off on the balls of my feet rather than being a heavy heel striker. Heel striking is all very well but you have to roll forward onto your forefoot to push off which increases the risk of pronation/supination, but also seems to massively increase the shock to your system with every step. Every time you land on your heel it's like a car crash; the force travels straight up your leg.

So forefront striking has really reduced the injuries. I've been running for a couple of months now without injury.

The final key is not to overdo it. Instead of thinking, 'yeah, 11 miles used to be no problem…', the right way for me has been to limit it to half an hour every other day of walk/run, building up to complete sessions of running. The aim is to get the muscles and mental capability developed gently.

I think these lessons have relevance for organisations too.

What medication does the organisation need? Is there a tool or process that will delimit the capacity of a process?
Can we make simple changes to reduce friction and risk at the point where work is actually done?
Can we make lots of small steps to increase capacity, rather than a single, high-risk change?

How we made the 'minimum viable product approach' work

2011-11-05T10:17:00.002Z

Seth Godin describes why the minimum viable product approach doesn't always work; you can't go through the try/fail loop without support of a community of users.

This is borne out by our experience at Sabisu. In our case, what we had to do was build the community before the product; find something that meets a community's needs, pitch the idea and perhaps a prototype and construct a community to support you.

That community is essential for a few reasons:

It's validation - plenty of people will tell you your crazy, so it's nice to have some people around of a different opinion.
It's a feedback network - so you can be sure

You start by addressing a real problem rather than something vague and perceived.
You continue to address real problems instead of going off at a tangent.

If it's a great idea then users may support you in other ways (expertise, for example) in return for early adopter benefit.
You get case study opportunities very early, as opposed to launching then waiting a year.

Why call the blog 'One Less Cut in a Thousand' ?

2011-10-28T04:00:00.000+01:00

Is there anything more dully self important than writing a post on why you called your blog a certain thing?

However, I was asked, so here's the answer.

You may have heard the expression 'death by a thousand cuts'; it derives from a barbaric method of execution used until 1905 in China but generally the phrase is used to describe 'creeping normalcy', or negative change which happens slowly in unnoticed increments.

My career so far has been spent on the inside of enterprises of all size. In my experience the most inspiring visions, innovative ideas and game changing technology fails to be adopted not because of a considered architectural or strategic decision to reject it but because of 'creeping normalcy'; the organisation fails to improve because there is inertia and apathy. Great ideas simply fail to find fertile ground - or, worse, we drift, apathetic, into creating terrible, unethical organisations.

Likewise, improvement projects fail not because of a considered decision to close them down - in fact, this is a successful scenario - but because lots of small negative actions chip away at the business case, or reduce uptake, or invalidate assumptions.

There are thousands of negative actions that reduce an organisations capacity to change, to improve. When I started the blog, my aim was simple; every post should have something positive a reader can take away that helps them to change their organisation; something positive to counteract the thousands of possible negatives.

Every post should be one less cut in a thousand. Perhaps one day we'll never make the first cut at all.

Real world enterprise social networks; why quality trumps quantity

2011-10-24T09:00:00.000+01:00

I thinkthe uptake of social media within the enterprise is really interesting. Thereare few independent studies (and lots of sponsored ones) so it was interestingto see the adoption of an experimental, completely unsupported and unpublicisedenterprise Yammer implementation – it would be inappropriate to say when, whereor how.

Whathappened was that following an initial burst of activity where the recruitmentof new users went viral, it then went silent for about 9 months. There werevery few messages, very few new users. Then the activity picked up again of itsown accord; users would put up more messages and the join activity started torapidly increase.

I mustadmit that having read about the Twitter new user ‘9 month bounce’ last year Iwas expecting it – basically, users go quiet after joining and then come back. This resonated because it’s exactly what I did with Twitter.

Ofcourse, Twitter’s new user activity is obscured by the continuous near vertical(but linear, apparently) user number growth. In a limited environment any slowdown in growth is much easier to see.

So whythe dip? Why the pickup?

I thinkthe dip was down to a few things;

Public nature of posting– people were a bit shy/wary.
Users unsure what topost, or why.
Insufficient followers –you post more when you have followers. Probably it's something to do with 9mthsbeing the amount of time it takes to get enough followers as a new user inorder for it to be worth tweeting.
Growth by spam; it waspointed out that on joining the platform spammed you to invite new users. Theseusers might join but weren’t necessarily engaged.

Why thepickup?

Just mythoughts but:

It took 9 months to findthe right users; a couple of users popped up out of nowhere and began postingon a regular basis, making the community active and therefore:

Useful
Accepted behaviour (cf.Gladwell’s ‘The Tipping Point’, particularly sections about ‘permission’.)

Personal social media penetration; users are relaxing about posting stuff. Without doubt enterprise users will get burned by posting inappropriate comments – and learn from it.
Viable network size; one of the reasons that Yammer wants to drive network growth (see 4 above) is that they’re aware that a big network is more likely to be robust and active, hence useful, hence endorsed by the enterprise.

Now,fascinatingly the relationship between the size of a network in the earlystages of development and it’s activity was almost (could be?) mathematical:they correlated precisely. It was almost as if every single new post added auser, even though that user wasn’t addressed.

Infact, the number of messages was far below what we might expect; perhaps thequality of the network and network activity didn’t match the growth; perhapsquality drives quality, as growth drives growth.

Thetake away for me is that to build a quality network is more difficult andrewarding building a big one.

Where I've been going wrong with IT strategy

2011-10-14T16:02:00.000+01:00

I love strategy. I love the idea. But it's only recently that I've come to realise where I've been going wrong all these years.

I've yet to see a company who has a non-IT core business define and execute a successful IT strategy.

By 'define' I mean clearly describe the vision, the goals/objectives,

By 'execute', I mean delivery of the strategic platforms and the solutions that sit on them; effective communication; mass adoption; proven benefit; everything defined delivered.

Sure, we see organisations deliver components of a successful strategy but never the whole hog.

Why?

Well, I don't think strategies are sufficiently agile. Certainly small, modern, agile enterprises seem to express themselves in terms that make big, mature, static organisations wince. Which is a bit strange seeing as they're both reliant on the same species to function.

Often, strategies don't actually mean anything. As soon as someone says the word, 'strategy', it seems to be the green light for academic techniques that don't actually resolve in anything a user would recognise. It's like even the communication of the strategy is FUD driven and scared of someone deconstructing the buzzwords.

Because they don't mean anything, they don't engage users. The guys on the ground floor don't care. The guys in the middle are busy being squeezed by the guys at the top and the guys on the ground floor. Vague, long range planning is your enemy. It doesn't translate into the real world.

Often, an the people within an organisation doesn't know what it cares about; what it stands for; what it's principles are. Think this is outlandish? Check out John Oliver, Grow Your Own Heroes.

So, strategists:
1. Make your strategy agile.
2. Eliminate buzzwords, be simple.
3. Engage users with tangible objectives.
4. Know what you care about.

As I said at the start, I love strategic thinking and know what a well chosen strategy can do. It's only now I'm at Sabisu that the importance of it - and the way to make it really work - is becoming a little clearer to me. Here at Sabisu we're working up a bit of a guide on how we think strategy should be done and over the next few weeks we'll get round to putting up some ideas.

Why self-service BI is falling short

2011-10-07T16:00:00.000+01:00

Having spent some time over the last couple of weeks introducing companies to Sabisu, it's clear that 'self-service' is seen as a big win - though the precise definition of what that means differs.

Every enterprise appears to have the same problems; complex business processes, a wide variety of often proprietary data sources, heavy use of IT expertise in integrating systems so that end users have the data where they want it. These problems result in duplication of data and a dependency on IT that destroys agility. How can you respond to incipient situations when you have to wait on an IT release schedule?

Everyone we've spoken to sees the answer in shifting capability out to the masses; empowering the end users by providing pre-configured reports or cubes where an end user can build report on-demand with recent data. Limited menu, often reheated data, but hot all the same - like fast food. This works to a degree, particularly in a slow moving environment, because you can schedule report generation or cube maintenance and the data will be 'recent enough'.

But it's not quite self-service. There's a long tail of requirements that the pre-built cubes aren't going to satisfy; all the IT department can do is invest more time, money and effort in building ever larger cubes as each new requirement is uncovered. Before you know it the costs associated with BI are spiralling, so the likelihood of tackling non-relational data or proprietary format manufacturing data is slight.

The end-user experience is often not great. User queries get invalidated as cubes are rebuilt (usually for IT reasons). Reports generated by different users don't tie up because different fields from different systems are confused - and implementing a data dictionary is often not viable, even if you can get cross-department agreement on a single version of the 'truth'. End users have to become proficient in what is, in effect, a development environment for building reports.

All this points to partial adoption at best on the grounds that the service just isn't great. It's got to be better.

I'm looking for:

End user driven platforms, so no IT involvement - particularly none that could invalidate a trusted, end-user designed report
Genuine end-user driven data access without needing to train everyone first - it's got to be built around modern UX principles
Real-time, or as near as makes no difference
Direct access to source data - if we're going to have a debate about the data, let's at least be clear on what we're looking at
Some way to action BI; curate it for a community, make it actionable, collaborate on it
Controllable expense - there's no way the enterprise should be penalised with increased expense or complexity for a user wanting to extract or share data

The perils of over-engineering

2011-09-30T16:00:00.001+01:00

A couple of weeks ago, as referred to obliquely in our Sabisu blog we upgraded our development and QA environments. Our hand was forced because we lost the development environment irretrievably due to over-engineering in the earliest days of the company; something that couldn't possibly harm us in the future did.

The lessons learned can be summarised thus;

1. If you do experience an exponential increase in activity, you can probably find the funding for more capable infrastructure.

2. Advanced technology steals time. Use the simplest technology you can find that will do the job.

3. Only use technology you understand and have a track record in configuring successfully. If you're an infrastructure guy/company, fine - if not, stick to what you're good at and outsource the rest.

Anyway, here's the story.

When you set up a company, particularly a boot-strapping start-up, you are short of everything apart from ambition - that's what makes it fun. The two things you're critically short of are money and time but you can't help planning for the 'hockey-stick' eventuality; a graph that suddenly swings from gradual linear to exponential growth.

So we originally built two hardware platforms in-house on high grade consumer kit rather than industry standard hardware. (This is a problem in itself because high grade consumer kit often has the features of professional hardware but it's less expensive - and that cost saving appears as a time cost as, inevitably, the hardware is less reliable.)

Then we created three virtual environments on each machine; mirrored VMs for Development, QA and fileserver/DC. Each virtual environment was snapshotted in its entirety on a schedule. Data was backed up to a spare hard drive in one machine and the source code was backed up off-site to Amazon Web Services.

(Worth saying that the live system has always been hosted to the highest corporate standards by a third party infrastructure specialist.)

In the worst case scenario, we'd lose a hardware platform but we'd never lose any data.

As a little start-up we didn't have the time or people to define and implement the kind of processes you need to manage this kind of environment. So, the VM paused mid-snapshot one day in something of a dither having ran out of room mid-snapshot.

We didn't expect this; we expected each snapshot to be a few GB at most, because we didn't understand snapshots fully or have the processes in place to monitor storage usage. We had no processes defined to allow us to bring back a failed VM. It was catastrophic.

As a backup, the snapshot was useless; it took several hours of crunching to get the most recent snapshot back and loaded to figure out that it was too old. So the VM was effectively bricked because the data was old - so the multiple platforms were irrelevant.

The VMs were a waste of time. We would have been better with any alternative. As it happens we reconstructed the source code from the online Amazon Web Services backups and each developer's work in progress version. We rebuilt the hardware platforms as decent standalone Development servers, which we understand.

How we set up Trac for agile development

2011-09-23T16:02:00.000+01:00

Following this post, I had a couple of queries about how we set up Trac for managing Sabisu. Hope this helps.

Where does Trac live?
We implemented it onto our Dev server, so we have control over the environment. It could live anywhere but just seemed to make sense. We expose certain elements of our dev environment to the internet through the Sabisu platform, so that's how we get remote access.

How do you divide your product into Trac?
Initially we divided the platform up at the top level, so we had a separate instance of Trac for each major application; platform itself, Chronos time logging, Forms and so on. However, this made it difficult to see ticket allocations across the team so now everything is in a single project.

We then split the platform using into each Component, e.g., Chat, Chronos, Communities Functions, Communities View etc, through to Widget Editor. Every component is assigned to a different member of the team to make default work allocation easy.

Milestones
We use Milestones a lot. Every milestone corresponds to a release and we allocate each a codename because it's easier to say, "We're moving ticket 192 to the Nestor release" and have everyone know what you mean. We try to get a balance of about 20-30 tickets per release and we release new revisions on a weekly basis.

Priorities
Our priorities, running from highest to lowest; blocker, critical, major, minor, trivial, cosmetic. If part of the system is inaccessible, or we can't complete a test, that's the highest priority. At the other end of the scale a cosmetic indicates something that's genuinely cosmetic - if it affects UX in anyway it's major or minor.

Severities
Our severities, running from most to least; Multiple Customer Outage, Customer Outage, Customer Inconvenience, Irritant, Risky to leave, One for later.
For any severity lower than Customer Outage there's generally a work around available. 'Risky to leave' tends to be architectural or infrastructure work but no reason why it should be limited to that.
Also a ticket regarded an 'outage' mightn't be a Blocker; it could be that the functionality is accessible but fails.

Ticket Types
Couple of interesting categories: Defect, Enhancement, Live Incident, PoC.
Of course, Live Incident and Defect are both important categories. However, in conjunction with the Severity and Priority we can properly direct our efforts; a Live Incident could be relatively minor and addressed at a later date without significant impact.
The 'PoC' type is used to denote 'proof of concept' work. This is usually pure R&D work that needs productisation at a later date, usually through a series of Enhancement tickets.

The Priority, Severity and Ticket Types fields work together; the most serious ticket is a Live Incident causing Multiple Customer Outage preventing access to part of the system (a Blocker).

Resolutions
Very dull; Fixed, Invalid, Wontfix, Duplicate, Worksforme, Unable to Replicate.
I hate the Worksforme resolution because it's not a resolution of any kind…but tolerate it because sometimes you just can't reproduce a user reported defect.

We don't use Versions and don't link Trac to SVN, though it's perfectly feasible - it's just not something we've needed to do.

Comments or thoughts welcome.

Five rules for organising an agile, timeboxed product dev team

2011-09-16T16:02:00.001+01:00

Over at the official Sabisu blog we outline some guidelines we use to manage the development of the product. I thought it might be good to expand why we established them , what they really mean in practice, and what they give us.

1. Work to the next release. It’s always next Monday.

The 'release early' philosophy is well established in agile software development; the sooner you can expose your work to your customers and react to their needs the better. Weekly releases allow us to turn around requests, incorporate customer feedback and incrementally improve the user experience.

Early in the lifecycle we tried to go to weekly releases but such a rapid release cycle caused a dip in quality as we tried to work in complex back end code too fast - now we have a mature platform and processes, the weekly releases are more logical. We take care not to expose users to complex functionality until it's usable, but the functionality is being gradually constructed behind the scenes as we go.

2. Incidents first. Defects second. Then enhancements. Always.

Many IT teams will hit incidents first; if your customers can't use your product for some reason, that needs to be sorted.

However, we only work on enhancements once we've got through defects; only defects waiting on a third party are put on hold.

This is in stark contrast to a lot of development teams where enhancements and defects are worked simultaneously. The problem with this approach is that (i) no one wants to work defects over enhancements and (ii) regression testing is tough.

Our approach does mean that in some releases there's little new functionality. We think that's a good thing; we concentrate on quality.

3. Every work item & every update goes into Trac.

Our defect/incident/enhancement/release management tracking tool is Trac. It's open source, simple but full featured tool that's our day to day management tool. Everything is logged, graded in terms of criticality and severity, assigned to a developer and allocated to a release. We tend to work about 25-30 Trac tickets into each release, with some developers taking only 2 or 3 effort intensive tickets.

Developer updates, testing notes, screenshots and anything else relevant goes into Trac. If we need a progress report, need to write release notes or are affected by a live incident, Trac will tell us what changes to commitments have to be made. Of course, it's all auditable if we need to trace the route of a change back through the process.

This means that we can forecast when a new feature or defect fix is going to be made available and if it should move, then all the relevant parties are informed.

4. The work plan gives the high level resource allocation.

Basically, the development team moves too fast for project plans to remain current, so we have a high level work plan that simply shows who's allocated to what customer (if they're off production) or release (if they're on production).

Having spent a lot of years as a project/programme manager trying to squeeze huge plans onto a small screen in Primavera/MS Project or whatever it's difficult for me to say this but...it's not something we do at Sabisu.

Basically there's no point. We work on such short timescales that a detailed project plan isn't much use beyond 3 weeks and all the detail is in TRAC anyway. All we'd be doing is shifting data from TRAC into a Gantt chart. By the time we've shifted the data the work's done.

So it's easier just to hit TRAC for a report of what's done and what's assigned to the next release. As long as we can get the 'big' bits of functionality into the main code trunk in a safe and sensible way we'll be ok.

You might legitimately ask how we plan the implementation of significant amounts of new functionality; there's a planning process implied in order to get the work into the build. The answer is simply that it happens offline, outside TRAC and the work is broken down into simple, achievable pieces of independent functionality prior to entry into TRAC. If a function is too big to be completed inside a release window, it gets broken down further into chunks that will fit.

Any bespoke customer work is dealt with the same way; we chunk it, tell the customer when they can expect each chunk and go for it.

(Now it's particularly interesting that back in my day at Motorola, we were expected to give the PMO a four week forecast for task completion, separate to the plan. I wonder if the data from the Primavera implementation didn't quite cut it?)

Beyond the high level work plan we have a long term roadmap which guides us in choosing the right features to bring into the product.

Whilst timesheets are done through our own Sabisu application, they're principally done for invoicing customers as we do some bespoke work; we can be very accurate about how much time we've spent on each task.

5. Flex enhancements out to meet the release date (timeboxing).

Finally, we flex scope all the time. Making the Monday release with quality code is more important than shoehorning in new functionality. Generally, it means the new feature is delayed a week and we've never encountered functionality that's so time critical that it's worth endangering the quality of the code for.

The limits of metadata in the manufacturing enterprise

2011-09-09T16:02:00.003+01:00

Moving on from the previous topic of curation being a better fit for manufacturing needs than 'conventional' BI, we should really look at the other data produced in large volumes within any enterprise: documents.

Documents tend to be produced by a fat client on an end-user OS, both of which imbue them with metadata and place them in a taxonomy.

Often both the metadata and taxonomy are of varying usefulness and accuracy as taxonomies are corrupted, folders duplicated and metadata rendered invalid by server processes. At least an end user can make a value judgement about the document and an enterprise search tool has something to index, meaning that from a list of apparently similar documents returned by a search query a user can make an educated guess as to the valuable item.

Once that valuable item has been located, the user might well share the location of the file with a distribution list...

...and that's curation picking up where enterprise search has failed.

When ERP data is considered, you'll find little metadata of value to the end user. Again, it would be a common scenario where an enterprise search returns possibilities and the end-user selects and publicises those of value to the wider community.

Manufacturing systems also generate very little metadata as they're designed around a single purpose, e.g., to log data in real-time. The metadata is limited to that which is necessary to make sense of the reading - you could argue it's not metadata at all. Clearly, in these instances enterprise search has nothing to offer here but expert end-users do; they can identify the key trends and highlight them to a wider community.

Of course, there's an network effect as more curation takes place; as more data is linked together by expert judgement, the value of the network increases exponentially with each link created.

Just as internet search engines are devalued by systematic metadata corruption (link stuffing, spamming, or any other 'black' SEO practice) so enterprise search is devalued by closed, proprietary or legacy systems producing unlinkable data.

And just as on the internet the value of curated content (usually) outweighs that of content returned by a search algorithm, so it will be in the enterprise, where the editors or curators are experts in the technical aspects of their business.

Why conventional BI fails manufacturing enterprises but curation succeeds

2011-09-02T16:02:00.001+01:00

Back here I was describing what the terms democratisation, syndication and curation mean in the Enterprise 2.0 environment.

Of these, curation is particularly important to the process industries and perhaps to manufacturing as a whole. And here's why.

The data generated in a manufacturing environment can be thought of as broadly falling into the following categories; documents, ERP data and manufacturing data.

Whilst tempting to exclude documents from any BI discussion it's false to do so; whether in Lotus Notes, SQL or elsewhere, this is where day-to-day manufacturing decisions, events and instructions are stored. They represent a key data source for understanding trends yet are often ignored by BI solutions.

ERP data is typically proprietary and stored deep in an inaccessible database designed with system and process integrity rather than data reuse in mind, to be accessed only by a vendor specific MIS client.

Manufacturing systems data is generally generated with very little metadata by proprietary systems that are designed around a single purpose, e.g., to log data in real-time.

As any business intelligence vendor will tell you, the value of collecting such data is in the analysis of trends; identifying series of points that demand action. Yet the value of such analysis is exponentially increased by deriving relationships between trends, e.g., an interesting manufacturing trend may become a critical decision point when placed against an ERP trend. Causal relationships are what drive effective decisions - decisions which may require considering ERP data alongside manufacturing data alongside operational documentation.

This is precisely where conventional BI fails in the manufacturing environment; it's usually vendor aligned and incapable of dealing with proprietary data from multiple sources.

It's also difficult for end users to get to grips with, which means the enterprise can't leverage the expertise within the wider user base; conventional BI relies on users to be experts in the construction of queries, when their expertise is the construction of manufacturing processes.

It's end users, expert on the business process but inexpert on BI tools, who will spot these relationships and must be empowered to act.

This is curation; without meaningful metadata to make connections algorithmically, expert human filtering and nomination is the only way a community of users can be notified of a relevant trend. This is the real data that needs user collaboration, selected by a user that appreciates the nuances of the community's shared interests.

These users must have easy access to data from multiple proprietary sources; a level playing field that promotes mash-ups and comparisons. End users must be able to identify their own causal relationships and share their findings immediately with the wider community, driving quick decisions and developing knowledge that is in turn utilised in the future. There can be no reliance on IT to enable this process - it has to be in the hands of the end-users so they can act quickly.

In this way, data can be socialised; business intelligence can become social business intelligence; communities can benefit from shared expertise, expertly applied to their data.

Syndication, democratisation and curation of data within the enterprise; killer combination

2011-08-25T16:02:00.000+01:00

Syndication

If we take syndication to mean making content available to other sites/subscribers (e.g., web syndication) then although enterprises seem to be happy with the idea of syndicating public facing content such as press releases, articles or white papers via social media, the idea of syndicating enterprise data isn't yet mainstream.

So the definition of data syndication would be that data is published simultaneously in a number of other channels - those channels could be outside, or inside the enterprise.

If you're inside the enterprise it makes it more likely that whatever channel is preferred by a user, the user gets the exposed to the data. Perhaps more importantly, it ensures that whatever the data source is, there's a common way to access it. By syndicating the data into multiple channels, the data can be event driven to the user, who can then take control it - it's there on demand as opposed to needing to be found. So the benefit is speed; awareness; engagement.

The case for syndicating data externally is potent. Firstly, it's transparent, so it builds partnership and trust; for instance, the near instant visibility of customer demand down the supply chain can reduce the 'bullwhip effect'. In addition, real-time situational awareness speeds up vendor response. Perhaps organisations will want to bring customers into the product/service development process even earlier than they already are. Or customers could take a complete, cradle to grave view of product quality.

Democratisation

Democratisation concerns the spread of knowledge amongst end-users as opposed to a hierarchical broadcast mechanism. Kevin Rose (@kevinrose) makes some interesting points about the sheer volume of data on the internet and how democratisation is the masses deciding what's important or relevant.

Users in the enterprise face the same challenges as users on the internet; the volume of data is huge and increasing. (This is why enterprise search is big business - HP are buying Autonomy, Google are pushing their search appliance and Microsoft are working their FAST acquisition/Bing into the enterprise where they can). The enterprise needs the same democratisation capability as the internet. Users need to be able to find and through sharing 'vote up' those key trends and issues that need attention, whether it's the trend of data from a manufacturing plant instrument or an unresolved safety audit finding.

Democratisation means the right attention can be given to the right issues at the right time.

Of course, this is a tough thing to do; the nature of data in the enterprise is different - the historical lack of enterprise-wide search means metadata is lacking or inaccurate and vendors have spent years implementing protected, proprietary, and closed systems. But with intelligent design we can overcome this.

Curation

And so to curation. Buzzword du jour. There's a definite move away from the academic definition to curation as a development of the democratisation of internet content, usually via social media. The key factor is that content is filtered and organised by a human for a community of people with common interests, rather than aggregated by an algorithm designed to respond to a single query.

This is a logical step; faced with huge quantities of available data, there's just got to be some way to make sense of it all; what's worth reading and what's worth keeping? An algorithm can't answer those questions because it doesn't appreciate the nuances of the community and those shared interests. You need a curator to take the step from the personalisation around their interests (dealt with in Web 2.0) to the relevance of content or data to the wider community built around shared interests.

As I write this in August 2011, there are few content curation solutions out there - most are in private beta and all are aimed squarely at the internet and socialising content.

Just as it's the next logical step for the internet, it's the next logical step for the enterprise. The enterprise is full of communities, from those with a shared interest in cycling to those with a shared interest in energy and sustainability, or safety. Communities are reliable, robust and inclusive; they lead to better decisions and by their very nature engage users and ensure that the relevant data gets to interested parties. A well curated community kills a reliance on email, or any other form of serial information delivery. Developing the idea of curating syndicated data mentioned above opens the door for expert third parties to be consulted or offer services.

Altogether now…

Simply put, I believe that democratising syndicated enterprise data through user communities is a good thing. Each enterprise and each employee that works within it can be more autonomous, more expert and better connected. It's a killer combination.

The job of your staff is to populate your to-do list

2011-08-18T16:01:00.002+01:00

....not the other way around.

What the hell…? The job of my staff is to do the stuff I tell them to, surely?

Well, no. The problem with a CxO/manager telling the staff what to do is that the staff are closer to the customer. Or the systems. Or the problem.

Now, this isn't intended as a recipe for corporate anarchy, or some sort of democratic leadership. The CxO has a job in terms of putting in place the structures and processes which ensure that the work gets done. (cf. 5 Rules, 8 Commandments). From that point on, the CxO/manager's job is to respond to what the customer/problem facing team is telling them - or needs from them.

So, the CxO/manager having decided that they/you want, say, an agile development team where the focus is on frequent releases at a production level of quality with low risk, it's the CxO/manager's job to get in place:

The simplest tool you can find.

The simplest, clearest, fewest guidelines necessary.

The simplest, clearest, smallest organisation structure you can define.

Then, let the guys on the ground talk to the customer, do their job, work within the tools, guidelines and org structure that's been prepared for them. The CxO/manager's job is to support them.

(You don't need someone to draw really complex processes that look great and never get followed.)

(You don't need to invest in something expensive or complex.)

(You don't - and as a former Programme Manager this pains me - need MS Project.)

For instance, managing a small development team on an agile software product development project, we have:

Tool: Defect/issue management software TRAC (an open source solution).
Guideline: We flex enhancements in favour of defects for a weekly release.
Org structure:

One person takes responsibility for the crucial production trigger points
Everyone has a specialism.

Our sales team approach is looser as the team's smaller:

Tool: Salesforce.
Guideline: Find new & interesting people to work with.
Org structure: One person per sector.

The beauty of this approach is that it's scalable. Want to expand the sales team to talk to more sectors? Duplicate it. Again and again. Want to scale up development? Duplicate it.

Every time you duplicate you increase the value of the information the CxO/manager supplies their teams as it can be used by each duplicated unit. Therefore you increase the value of every question that's asked of the CxO/manager.

Therefore you increase the value of every item your team places on your to do list; you increase the value of your contribution to the company.

I'll let you know how we get on.

Four things I say a lot to my team and what they really mean

2011-08-12T14:28:00.002+01:00

Those around Sabisu are used to hearing me say;

1. 'Tell me what you need'

Nothing's worse than screwing up when it could have been avoided. I hate the phrase, 'if only'.

If we're about to lose a sale because we don't have a one page summary describing how great Sabisu is for supply-chain collaboration, then it would be nuts not to ask for it.

Equally, if a customer needs to know why we've gone with functionality A and not B, or any other difficult question, then put them straight through to someone who can help; clear the decks.

Delegate upwards so those at the sharp end can focus on what they need to do.

2. 'Show me what you've done'

I see this as pretty close to Terry Leahy shopping in his own Tesco stores, or a chef working the pass; it's all about checking the quality. It says in Rework: everything is marketing. So everything has to be high quality.

By constantly reviewing what the team is doing, you don't need to check what the team is doing as much in the future; they'll get used to the possibility of a review and up their game to meet a higher standard.

For me, this is nothing more than the 'test first' approach of, say Extreme Programming, or the 'go to production early' approach of any agile methodology extended backwards into the pre-production lifecycle. Get it in front of the customer early to prevent defects being found expensively late in the development cycle.

3. 'Good job.'

Or 'nice one'. Or 'thanks'.

(Or 'good stuff'. Or 'rocking'. Or 'awesome'.)

Being enthusiastic. Saying thanks a lot. It's just the right thing to do.

4. 'Riiiiiight...?'

Never smack down an idea until you're absolutely sure that (i) it's been expressed fully, (ii) you understand it, and (iii) you understand its implications.

I suppose it's about pre-judging an idea. It's easy to do - particularly when you're tired, the kids are playing up at home and the dog has developed a horrific bowel ailment or whatever, but I try to remember that the guys in the office are great at what they do and most of the time their ideas are good.

So, 'Riiiiight?' really means 'tell me more'. They get that.

Guest post for MMUCFE

2011-04-15T12:43:00.000+01:00

Lead Us Not Into Evil: my thoughts on ethical leadership - guest blog post for MMU's leadership programme @mmucfe - http://bit.ly/e6kYbK

Why the time is right for the Networked Enterprise

2011-03-04T14:48:00.001Z

Here I blogged about the cloud as an enabler for the ‘networked enterprise’.

The reasons why I think the concept will take off now are:

The emergence of truly collaborative platforms that leverage the enterprise network.
(Disclosure: I’m the owner manager of http://www.sabisu.co/)

Only now is the technology in place; social business software (or Web 2.0 or Enterprise 2.0) situated in the cloud is the only way for the networked enterprise to return value.

Without these technologies enterprises are back to building specialised point to point bridges with increasing expense blocking implementation and complexity nullifying returns.
Studies are beginning to show the benefits of deploying web 2.0 and cloud technology; this should convince the pragmatists that the emphasis in ‘social business’ is on the ‘business’ part. Until this point, they've had ample anecdotal evidence to belittle the impact of social networking. It's the arrival of studies like this that should change things.

Of course, the social networking side of things is important but without point 1, the collaboration platforms, you've got nothing better than LinkedIn (which is great, but to a point). If the 'networked enterprise' concept is going to return value, you need the collaboration capability too.
People are ready; Facebook/Twitter/LinkedIn have rocketing user numbers – each of those users is getting a starter course in the power of the network and the ease of using a web 2.0 application. Collaborating with a user in another organisation isn't scary when you've already LinkedIn with them...and even if you haven't, the very existence of these platforms gives you the permission to work beyond your organisation - the psychological barrier has been removed, so the boundaries fall too (as explored in Malcolm Gladwell's The Tipping Point).
Corporates are (almost) ready:

Deperimiterisation is coming as Execs start to drive adoption of ‘consumer’ technologies (oh go on, I’ll mention the iPad) in the enterprise. This removes a psychological boundary; they expect at work what they get at home, but crucially vice versa.
Savings seduce: IT departments are seeing the time, cost and hassle savings. If an end user can get the service they need direct from the cloud - and for very low cost - then the temptation is to stay out of the way.
Corporates are beginning to understand that the biggest security risk is people, rather than some esoteric hack attack.
Corporates understand that the ‘cloud’ is an extension of ‘vendor hosted’ and generally they have experience of this already. So it’s not too scary.

Of course, there are obstructions and gaps which will slow adoption. But those who do adopt will have a significant competitive advantage - and now for the first time, they can.

Does the cloud mean enterprise relationships will mimic personal ones?

2011-02-25T14:20:00.000Z

Until now, the usual behaviour for enterprises is that they work together for the duration of a contract then they part. The concept of the 'Virtual Enterprise Network' is a good example; a temporary affiliation of multiple enterprises to achieve a given aim.

Contractually that might be the case, but an enterprise doesn't actually do anything; it's the people that make up the enterprise that do things, and even though the affiliation is contractually temporary, the relationships between people are permanent.

Cloud computing can change this; it can provide a common demilitarised zone that many organisations can share. Whether it's a virtual private cloud or a 'public' cloud is irrelevant; for the first time there is a place that's permanently online, always on tap and can be made to hold to common standards. Until now, it's been a case of choosing a partner and investing in development to connect and exchange data with that partner, hoping to offset the whole lot with an ROI calculation that someone with a pot of money believes. Now, you can describe the data exchange in a common standard, hook up to a cloud solution and wait for everyone else to join in - the investment is made by the guys the enterprise pays to host your cloud solution.

This allows enterprises to form links that are more like the links people forge between themselves. How often do you de-friend someone on Facebook or LinkedIn? You don't; you keep them in your network 'just in case'. Enterprises can keep others in their network, just in case.

So the position of the cloud between organisations should allow those personal relationships to be realistically represented at an enterprise level; the links between organisation can left in place indefinitely, to be used as required, with little cost implication.

This would support Kevin Kelly's argument in What Technology Wants that over time technology trends towards complexity, for if the cloud is indeed a common DMZ then the future looks very complex with every single organisation generating more connections and never deleting old ones.

The implications are many but here are some that occurred to me:

The walls around an organisation are destined to become ever more porous. It's unavoidable that there'll be multiple external cloud solutions that the enterprise will want to connect to.
Independent consultants and SMEs (with the emphasis on the 'S') could find themselves on a level playing field with much bigger organisations.
Ultimately the enterprise could become dominated a loose affiliation of knowledge workers, rather than dedicated employees.

And it means that there's no such thing as a 'virtual enterprise network', or a 'collaboratively networked organisation', or any other variant: there's simply a networked enterprise.

Further thoughts on MMORPGs & collaboration

2011-02-02T21:37:00.000Z

This is a great blog post:
http://shanleykane.wordpress.com/2011/01/31/online-collaboration-sucks/

For me, that's what blogs are all about; a personal mash-up of experiences shedding light on something new.

I totally buy it. Back in '92, MMORPGs were MUDs and were all text over Telnet; I was a heavy user of Razor's Edge (a CircleMUD in Liverpool) and Infinity (based out in the US somewhere) at the time. Now, at that time MUDs migrated into being 'talkers', which were literally just text chat rooms. This didn't have the same attraction to me because on a MUD you were doing something, whether it was trying to level-up, get hold of a particular bit of kit or whatever. The attraction was working (gaming) together, in a shared environment, with instant communication and the right toolkit for the job...

Anyway here's how I'd extend @shanley's blog into the corporate environment:

1. Collaborators need the raw data

Most workplaces are much duller than the environment created in WoW. Corporate life is spreadsheets and docs; it's data. So when @Shanley describes it as a 'shared experience', for the corporate it translates simply into access for all collaborators to the data that describes the work to be done. It absolutely can be a shared experience though; you just need a single place where everyone can get to the same data at the same time on their terms..

...which means that IT departments need to move from compliance and control, to enabling and de-obstructing; the modern IT department function is to get the business data to where it needs to be - which might be somewhere outside the enterprise...

Perhaps the one place where you could justify a rich graphical interface is where the physical environment is important, say, if you're trying to collaborate on a problem with physical constraints. This could be valuable in hazardous manufacturing, petrochemical or nuclear plants. Real potential for 3D WoW interfaces there.

But for most office workers I think that in practice the interface has to be a portal variant; whilst the experience may be shared, each user needs access to the data, tips and tricks that allows them to add value - in the same way that a user on a MMORPG has particular capabilities or tricks up their sleeve.

I think that's a pretty good analogy for a day at the office.

2. User Autonomy Means Increasing Complexity

So it's going to be awfully difficult to hold everyone's personal configuration isn't it? Well, I don't buy that. Technology has moved far down the path of personalisation but it's not going to stop any time soon. I accept that a corporate is going to want to set users off in the right direction (e.g., everyone in a particular role starts with the same UI layout) but if I can re-configure it to make it work better for me, why can't I?

As Kevin Kelly says in 'What Technology Wants', the technology trends towards increased complexity; that complexity is everyone in the world doing it their way.

If every user is forced to look at their work - a document, project or whatever - in the same way, you lose the illumination that a shift in perspective can provide. The data may not change, but I might choose to view it in a different way...of course, this will root out those who depend on presenting data in a particular format to support their position.

3. Communication Features != Collaboration App

Couldn't agree more. Every application trumpets it's collaboration capabilities. Without the sharing of the data that describes the issue/project/work item itself, you can't collaborate on it, because what you're actually doing is going after the data, copying and pasting it into a messaging system (email, OCS, Lotus Notes, Google Docs).

You have to have the raw data to hand so that you can have that 'shared experience' and truly collaborate.

If that's the case, how many collaboration systems are really out there?

4. Sounding Off

I think finally the technology is mature and the corporates are looking to the value and competitive edge of working closely with their partners, suppliers and customers. The solutions are just beginning to become available; the value propositions are only just being clarified and supported with case studies and benefits evidence.

The main obstacle is in the minds of the risk averse IT departments, who are still blocking Facebook/Twitter/LinkedIn, and have yet to realise the power of the network.

WikiLeaks & Transparency

2010-11-29T15:01:00.000Z

As suggested in Jeff Jarvis' blog, we shouldn't kid ourselves that this is the beginning of any kind of change; we are not on a road to transparent government just because Wikileaks got hold of lots of secret political communications. I'd argue we could only be on a road to transparent government if those in power decided it suited them best and moved in that direction. This has not and will not happen because there is no universal acceptance of what 'transparency' means and therefore no clear indication of what benefit those in power would gain from increasing it.

The only reason this data has been made available is that the US government hasn't controlled it properly; a decision post 9/11 to improve data sharing across agencies has seen political communications which were originally limited in scope opened to an audience of about 2.5m US government users. As soon as that happens, a leak is inevitable. If these communications had been limited access as they used to be, a leak of this magnitude wouldn't have happened.

There's a lot of data which is still very much controlled and we'll not see for another 50 years or so. Only that which suits the current government's agenda will be released; sure, some other stuff will find its way out as it always does, but it's just as likely to force governments to tighten up controls as it is to increase transparency.

The interesting thing for me is that the technology involved to get this data was basically antiquated: CD-ROM and USB key. This is a failure of basic security rather than a master black hat hack (or white, depending on your point of view I suppose). At a time when corporates (my line of work) and governments are really worried about the security of new technology, it's the old stuff that trips them up every time.

The easiest way to get data out of an organisation quickly? I reckon it's email. Until recently, attachments over 2MB or so wouldn't reliably go through mail gateways, whereas now much bigger attachments get transmitted just fine. Perhaps the next big leak will get out that way.

The Apprentice: Choose Life

2010-10-06T21:49:00.000+01:00

Paraphrasing Heisenberg and Lord Acton, if measuring something corrupts, then putting it front of a TV camera corrupts it absolutely. And so the Apprentice starts again; the most inaccurately named and badly conceived programme since the last one.

The BBC hyperbole machine is already spinning at maximum again, with the web site, radio appearances, spin off shows and blogs all present and correct. Every newspaper is in the process of being fed appropriately outrageous stories guaranteed to cause pain and embarrassment for anyone unfortunate enough to be related to or a colleague of one of the vapid contestants. Then they'll crop up as a 'talking head' on business issues all over the BBC, holding forth on issues that are actually important, or perhaps fronting a dumbed down business programme for a world with the attention span of a...oh, whatever.

The worst thing is that no one cares. We're now at the long and painful arse end of the reality TV cycle where the format is exclusively consuming itself to such a degree that Big Brother is cancelled, with virtually the entire audience inured to the hype by a fresh brand of tough cynicism and a couple of mildly amusing Ben Elton books. Thus the feedback loop is cemented and furthered as the extensive promotional mill demands further grist, achieving ever greater heights of exaggeration to get the real ultimate prizes; revenue generating votes, half witted opinions from viewers at 10p a shot.

Therefore the public gets what the public wants and vice versa; every time a viewer votes for a self aggrandising fool - so much more so for subjecting themselves to the editing razor of a machine that places them at the bottom of the hierarchy of importance - the tactics employed by these programmes are validated and extended. Television is discredited as a medium and we blindfold ourselves with dire consequences because we reduce the impact of everything we see through the big LCD in the corner of your living room; it's not just a television, it's a Lowest Common Denominating machine.

So what to call shall we name our beloved programme? What is it? It's a stupid and loud job interview with a load of obnoxious idiots so I propose; "JobCentre Plus: London", which would permit a new JobCentre plus franchise in not just every country, but in every city in every country. Now that's a model for growing a brand.

Next time, I'll be describing how Lord Sugar can benefit from the secrets of the immortal living dead.

Tread carefully, for upon these pages you stake your future

2010-10-03T09:02:00.000+01:00

At present I find Gladwell's arguments on social media hold water and Mirani's Guardian article by turns supports and contradicts it with it's examples, despite the headline. Both comment on the current use of social media rather than the future.

The future is a quite different thing because social network connectivity is only a fraction of the equation. Much more important is the data; your opinions, expressed in a medium which is permanent and accessible.

Schmidt (Google CEO) was only half joking when he said that in future, people would change their identities to avoid being linked with their past indiscretions online. Suddenly, the post you put up in Facebook in your crazy early twenties will be used against you when you're going for a highly paid job in your mid-thirties.

What this means is that how you use your on-line identity will take on much more importance. You will think twice about supporting controversial causes because you'll have heard stories of those denied an opportunity because of causes they've joined or opinions expressed on-line.

The consequence of that is that the act of putting your name on an on-line petition or publicly supporting an opinion will increase in importance and the links described accurately by Gladwell as being weak at the moment, will become stronger.

Tread carefully, for upon these pages you stake your future.

Lessons from Max, the Lego spaceman

2010-08-20T11:19:00.002+01:00

My daughter's off to Legoland Discovery Centre in Manchester today - her second time. Last time we were there I bought this little guy, who we'll call Max (because my daughter likes 'Where the Wild Things Are').

Max took me back to my childhood in an instant. Space Lego in particular was my toy of choice for what seemed like years. Other toys may have got a look in but it was building numerous spacecraft variants from just the Galaxy Explorer set that I really remember - and it looks like I'm not the only one.

Couldn't resist showing you this, it's great:

I now understand that as a child it teaches you some great lessons. In fact, only now is it clear that the lessons apply to many areas; developing ideas, strategies, managing people...

Here are the ones that occurred to me today:

Components come in two families; infrastructure and individual. The infrastructure delivers that which is necessary; the individual delivers that which is desirable. You need just enough infrastructure to keep the individual in place.

(In Space Lego terms, just enough plain blue 1x4 bricks to keep the yellow angled windows in place.)
Following the instructions is enjoyable but it's more rewarding trying to produce something new; building things and breaking them, then keepnig the best groups of components.

(If you've found the optimum configuration for some hinging vehicle doors you're going to use it again and again.)
...which means that sometimes you don't have to design.

(All you have to do is to try bolting together the optimum components groups in a few different ways - you'll get something useable.)
It's a training ground for creatively spotting synergies; bolting items together from different kits teaches you to try the less obvious.

(For example, you can stand Max on his tip toes...I'll leave you to figure out how.)

BTW, my daughter (aged 2 and three quarters) insisted on a Lego Woody figure (the informed Toy Story choice) and a pink brick for mum. I think it might be time to scour eBay and get her started on Classic Space; the only Lego that matters...

Enterprise Architecture As Strategy - book

2010-06-30T13:59:00.000+01:00

Heading into this book, my hopes were high. Particularly encouraging were the opening definitions of enterprise architecture and it's positioning as a business rather than IT issue. This makes increasing sense in today's world and fits with what I perceive as an increasing tendency to clearly separate business focused 'value add' IT from 'business as usual' or 'maintenance'.

Perhaps I've over indulged recently on Enterprise 2.0 texts; the first 100 pages feel predictable and pedestrian. There are some fine principles in there but they're expressed without objectivity; for instance, is it likely a CIO would pour scorn on a multi-million dollar enterprise resource planning (ERP) software implementation delivered under his leadership? Or give a negative assessment on his involvement in IT strategy? Hence, when the CIO waxes lyrical about his own capabilities you've got to take it all with a pinch of salt. It would have been more revealing to focus on CIOs giving mixed messages, or perhaps the experience of the customer and internal end users.

The first 100 pages fails in it's aim to be a handbook & guide; it needs to prove traction below the CxO level to do this. Indeed, it's hard to pick out the real lessons because it's hard to spot a pattern between strategies; perhaps the authors are trying too hard not to be prescriptive, but the end result is somewhat inane. For example, by the time in your career that you want to buy and read a book like this it's kind of obvious you need your IT function to be responsive to the needs of the business.

Published in 2006, much is made of the success of those companies who have pursued an enterprise architecture as strategy approach without really saying how they did it in any detail. Cemex is called out as an example of great growth due to this approach, yet the book notes that it grew by acquisition and the much referred to 'agility' seems to have made the company insufficiently agile to avoid the stock price thumping seen by many other companies in that sector since 2008's crash.

At various points you might get the impression that a whacking great ERP implementation would deliver lots of benefits, such as technology and business process standardisation, yet would allow your organisation to remain agile; the IT equivalent of having your cake and eating it. Indeed, throughout the book, you get the impression that this is a very ERP friendly approach. Considering it's 2006 publish date, failing to address the various innovative approaches of the time is, well, shortsighted at best.

The book reads like a research text written by academics; the kind of thing beloved of MBA courses everywhere.

Past page 100, it gets better as it starts to talk in some detail about lessons from real life. There are some great

The 8 Commandments

2010-05-19T16:37:00.000+01:00

Think platform, not software.
Create functional software to extend the reach of the platform and drive platform adoption.
Build functionality first.
If the user can do it, the user has to be able to see it.
Aggregate, don't consolidate.
Independence; browser and O/S.
Elegance rules; speed, simplicity, immediacy.
The user's needs are the most important thing

Anyone doing the above will never really have any competitors; different organisations are always going to develop original (or not) spins on the same function.

However, if an application is a means to getting a user to the platform...then all applications are good news, no matter who generates them.

Everything Is Miscellaneous - book

2010-04-30T19:58:00.000+01:00

Well, I'm not sure it had what I was looking for (secret of eternal youth, tip for the 3.30 at Ascot, designs for a real autoplane) but it sure was enjoyable getting what it did have.

In a sentence; modern technology means it's ok for everything to be messy - you can tag it and get it back later somehow.

(Thank goodness, because I really am terribly disorganised.)

Part of the book that struck me in particular was the atoms vs bits debate. Perhaps that's because it's relevant to me right now. It's not news that bits are weightless, have no dimensions and are infinite whereas atoms are constrained by the physical world - they need to be moved, stored, used, stored somewhere else and so on. Certainly it's been explored in a lot of the other Web 2.0 literature. Yet, really this is the fundamental difference between the pre-digital and post-digital age; atoms are atoms, but everything else can benefit from the weightless, infinite, immediate properties of digital. Weinberger states it elegantly, along with the ramifications for how we organise and use information in the future.

Where he doesn't choose to go is to look at those processes in the digital world which simply mirror physical processes. The assumptions behind them are invalid - the organisational walls that are breached will one day come down altogether and with them, a lot of our clunky existing systems and processes.

The 'include then postpone' concept is equally interesting - and equally extensible. It struck me almost as a digital motto and certainly my mind went to Google, Twitter, Facebook et al in that they first included everyone and everything they could, postponing monetisation and data use until much later. Weinberger chooses (rightly) to focus on data; it's natural to want to order things, but we must include messy data first and postpone the introduction of order until later.

There are clear themes in common with Chris Anderson's The Long Tail, Jeff Jarvis's What Would Google Do and other recent books; give control back to the people, promote creation by the masses, provide platforms for people to organise themselves elegantly.

Perhaps the only area that needs exploring more is the detail of the interface between physical and digital. The analogue to digital path is well understood I'd argue; capture through, say, a camera or microphone, add metadata, upload, share. However, the path back from digital to physical perhaps needs the most work; Weinberger references RFIDs and I started to think in terms of QRs, augmented reality and so on, but without too much success.

So I thought it was a good read. It's already part of the modern tech lexicon and rightly so. Another one of those books you'd like to distill and install directly into the memory banks of all your colleagues. It would be messy, but in a good way.

Insights into corporate innovation

2010-04-27T15:53:00.000+01:00

Last week I was over in Leeds at a Corporate IT Forum day dedicated to Innovation. The presentations were from those who were shortlisted for awards last year at the Real IT Awards - we were lucky enough to win.

It's great when you turn up at these events to find a bunch of like minded individuals and if willingness to innovate was a realistic economic indicator, the national debt would be history by this time next year (well, ok, the year after).

After presentations from ourselves (SABIC Petrochemicals), Virgin Atlantic and Co-operative Financial Services, we had a number of open discussion sessions. Some common themes came out.

1. Creating time to develop an innovation is more important than funding

2. Invest small, fail fast

3. Innovations have to prove themselves quickly in delivery

Now, to my mind that reads like a list a start-up would make, rather than your average corporate. Perhaps the difference is relative scale.

For example, the corporate guys have a multi-billion pound turnover of which a relatively insignificant amount is dedicated to innovation. Start-ups have a relatively tiny turnover but most of it is dedicated to trying new things.

Corporate innovation teams are very small and very light. They typically use agile approaches to achieve something quickly and are very good at taking square pegs (both systems and people) and making them work in round holes. Start-up teams have less room for manouevre both in terms of systems and people; every blind alley or failed development is so much more expensive to them.

But it's clear that the corporate guys are learning lots from the typical agile startup. They're creating the time and space and trying to fill it with the right people. The number of attendees that referred to 'disrupting' tech was very notable.

Here were the key points from my presentation (prz available if req'd):

Focus on what you do; no point innovating in widget design if you're not a widget company
Approach innovation consistently
Key point: Take the straightest line to business value

Processes

How do you initiate change?
What happens to it then?
Ensure strategic alignment - or otherwise validate - and good oversight
Stretch evaluation into the business
Try lots fast

Culture is the result of a feedback loop

Let's not reorganise!
Don't try to mandate creativity
Give your people space and time and guide them in filling it
Improve capability and focus it on your business

Enable the business to add value - to itself

Provide open platforms, not closed tools
Encourage users in extending platforms inexpensively to get continual return for minimal investment
Do what you do best...and link to the rest
Focused trojan mice
Use platforms that encourage co-development and formation of communities

I think most people could take these key messages and build something around them for their organisation.

Cheers
Tim

Engage or die; why Amazon needs Facebook

2010-04-01T09:19:00.000+01:00

Marc Benioff of Salesforce.com makes some good points (and stretches others) as to the future of cloud computing here, where he refers to Facebook replacing Amazon. Surely most Facebook users look at the tool as a simply as a free social networking site, many times removed from the clear online retail experience at Amazon. Rather than second guessing Marc's thoughts, it seems obvious to me why Amazon should be concerned.

Amazon's added value is it's user reviews section; if there are two identical products - identical picture, price, description - but with differing reviews, you'd be mad or deliberately contrarian to buy the unfavoured product. In fact, a terribly unscientific survey of one revealed that customers would rather pay more for the guarantee of a good product as opposed to facing the hassle of returning a bad product (or even worse, nor returning it).

The only problem with the Amazon reviews section is that a customer is taking a risk by trusting the reviews section at all; it could be skewed deliberately by paid product evangelists, by a particularly bad run off the production line, or by reviewers that aren't the true target market. Because the internet gives a veneer of anonymity (albeit ever thinning) you might never know the product you're about to buy is a total lemon.

Facebook is powerful precisely because we trust those who we befriend, to a degree that depends on our own attitude to trust; we choose who we want in our private community, while our privacy and profile settings tell the rest of the world how much we want to be part of each of their private communities. Therefore a recommendation from a friend (say, from @mcflinbob on a movie, or @euan on a book) counts much more than a faceless Amazon reviewer.

Amazon have tried to add virtual faces to reviewers through their 'real names' qualification; if it's a real name then they're more trustworthy right? Well, not quite; it's still just a name on a page.

Facebook is yet to engage it's user base in retail activity on a mass scale but the sheer numbers involved have the potential to turn webonomics on its head. Google has already proved the power of the virtuous circle with something as simple as search hits, relevancy and advertising; replace with sales, trusted reviewers and profiling and you're into telephone numbers. Should that user base then be mobilised by something - anything, good or bad - and it's a potential stampede toward or away from any product at any time.

So Facebook's community focus makes it powerful and Amazon's next move is a test of it's ability to remain agile in a socially networking world. The platform approach - the approach it should take in my opinion - is to build on it's existing credibility and invite integration with Facebook, Bebo, Digg, Twitter and so on; embed itself into Web 2.0.

After all, in a world dominated by social media, viability and engagement are synonymous.

Audrey's lessons for a (dis)connected world

2010-03-25T22:54:00.000Z

For some reason I never pick up a basket at the supermarket when the need for it is marginal; if there's a chance of carrying all the items without one - even if it means balancing a frozen chicken on my head - then I'll go without.

So needless to say when making it to the front of the express queue laden with unnecessary fripperies and a couple of bottles of M&S's finest slipping through one's fingers, it's a bit of a blow to see the Customer Service Representative attending the till run off to help someone else.

As it happens, our CSR has gone to the aid of a lady sat waiting patiently on a nearby bench - a couple of seconds later, I realise she's waiting to be guided out of the store because she's blind. They know each other by name so we can assume 'Audrey' is a regular. Outside they meet a cab driver who again knows his customer by name and is prepared with the cab step down, door open, ready to take Audrey home.

Clearly, Audrey has built a rapport with M&S and her cab company. Probably there are a few companies she trusts to provide her a service and they value that trust because a violation of it would affect the way they feel about themselves, regardless of whether that trust affects the revenue stream from Audrey in the future.

So Audrey's favourite companies will be ones she trusts and her dependency on that trust highlights the problem we all have in a world where connectivity is virtually ubiquitous but opportunities to build trust are rare; where we can claim hundreds of people as friends yet not really know any of them. Robbed of key senses we use to evaluate whether someone is trustworthy we take a gamble on human nature; the optimistic invite everyone into their lives, the pessimistic don't go on line.

This means that trust is the key factor in maintaining relationships. If I were to Twitter something inappropriate (plug: @timjsharpe) then my followers (few as they are) would lose trust in my judgement. I stopped following Boris Johnson because he was boring me to tears (@mayoroflondon if you must). Those with a substantial following often have media careers, precisely because their judgement is considered as sound in some way.

And that's how social networking is working for me; a load of editors that I trust are all editing the internet for me, providing links.

Where it's the web being edited into precise links today, tomorrow it will be business flowing from and to communities of like minded individuals. Trust is the currency of the future.

Time Bandits: Why effort counts

2010-03-18T09:19:00.001Z

Being brought up in the glorious North West of England, the legacy of the Industrial Revolution is part of my DNA; mill towns, factories and grim working conditions...but I didn't expect to find the roots of management consultancy there, which started with time and motion studies carried out by innovators in the field in the late 1800's. Indeed, history may judge the 1900s not as the tail end of the Industrial Revolution but as the start of the Consultancy Era.

So given that industry has been scientifically analysing worker behaviour for a hundred years, it's a shock to me every time I go into a big corporate and it has no time recording function. How can such a key component be missing? In my experience a US corporate is more likely to gather such data and put it to use in project plans, whereas UK companies just don't seem to be driven towards the same rigorous statistical analysis.

Simply put, to ignore effort is to ignore your business and, perhaps paradoxically, the least important information you get out is who's working and who's shirking.

The primary benefit is actually realised months after deploying a time recording tool as the data begins to build up a historical record of task execution. There's an argument for properly structuring the entry of time data and then doing nothing but collect data for months, finessing the capture process and ensuring compliance while the database builds the real management information.

It's easy to see uses for this data but applying it to estimate generation can produce real benefits, as it supports and informs the estimates that technicians produce. With your database behind you, you can play variables into the decision making process; changes in productivity between different project approaches or types of deliverable for instance.

If you're in the business of quoting fixed price projects then you can be more accurate, reducing the contingency in your proposals and therefore giving better value to the customer whilst retaining margin.

More obvious but to be treated with caution is the management hook; "cost visibility". Some visibility is better than none but it's absolutely not a panacea and ill-managed it's a nightmare as the temptation is to react to a perceived statistical trend rather than managing it's root cause. For example, a valuable member of staff can look like a luxury player when in fact they're just being badly managed.

It's not just a service industry focus either. Working with a manufacturing business at the moment, it's clear they have no interest in charging out resources to third parties, or quoting for jobs - after all, they make bulk chemicals. However, two things are in the pipeline; getting third parties to self bill using timesheets and a more active internal market structure aimed at driving operating costs down. So even in such an introverted environment, time recording is seen as a crucial component.

Somehow I think none of these requirements would be a surprise to the mill owners of the late 1800s. Where wool and cotton were the valuable assets, effort and expertise have replaced them. In fact our Victorian ancestors would have no trouble adjusting to a modern manufacturing world (well, perhaps with the exception of Safety, Health and Environment regulations).

Both then and now, effort is just one key datum common to all businesses. Administering it - allocating effort, collecting data and so on - is only an easy first step. As even introverted corporations start to virtual team and social and corporate networks merge, successful management becomes more about people rather than less; efficiency becomes the differentiating factor between avatars if you like.

And so management needs to evolve to reflect these democratising processes. Those we work with are masters of their own destiny; it's a Democratic Revolution. I'll have more thoughts on how this might occur soon.