A few years back, I traveled to a small town in North Carolina. This town, a haven for indie artists and antique traders, retirees and young environmentalists, had eschewed the more common American symbols – the corporations, the big-box stores, the brands. In the main streets of the downtown area, you couldn’t find a single franchise. There was no Starbucks or MacDonalds, or even a Border’s or Best Buy.

This was a wonderful place, with friendly faces and a calm, peaceful atmosphere.

Not everyone wants to live there. Some people actually want to live in Los Angeles, with it’s sprawling highways and anonymous Hollywood executives commuting band and forth to the Valley.

Asheville, North Carolina creates hand-bound books and home-brewed coffee. Los Angeles makes movies and iPods. (Well, Cupertino makes iPods, let’s not dwell on that metaphor)

In the business world, we have small and medium companies, we have larger corporations, and then we have what everyone keeps calling “Enterprise”.

What, I keep asking myself, is this Enterprise thing?
Read the rest of this entry »

After reading Keith Swenson’s recent post, I’m convined; we really are addicted to email. There’s no doubt about it. Or rather, we’re addicted to the methodology and mindset of email – responding with messages and attachments when and where they appear.
This, of course, causes complications, not the least of which is tracking progress and status. But we also have the issue of mutliple instances of documents, multiple copies of mailboxes if you log in elsewhere, and in the case of the bottomless pit of information that is Gmail, a complete mess of any and all content.

Are we stuck in a rut?

I’ll be honest, it’s difficult to wade through the multitude of solutions available for collaboration and communication, that are supposed to be the end of email.

Even among my peers, I encounter a strong resistance to web apps and online collaboration tools, and they still prefer emailing documents back and forth.

If we are to fight this phenomenon, it’s likely going to be a long and arduous battle. It took email years to work its way into the workplace, and now it seems well and truly entrenched. Education is a critical component, and teaching people to “put their toys away”, as Mr. Swenson suggests, is an important lesson.

But we don’t like to be told we’re wrong.  We like our familiar tools, we like what we know. New things come along, but Facebook doesn’t help most of us get more work done.

Getting over ourselves

What most of the collaborative tools and web apps I’ve mentioned try to do is make using them almost fun.

37 Signals have a design philosophy that makes their applications sexy, in computing terms. On the other hand, it doesn’t look like something that belongs in an Enterprise environment. It’s also not suited for non-project work, such as ad-hoc processes and short-term collaboration.

MediaWiki puts Wikipedia in our hands, but it’s got a tough markup, and getting into using it is a tough hurdle for many individuals whose time is too valuable learning new tools.

Google’s applications are so ubiquitous, it almost makes sense to default to using them whenever you need to collaborate with someone who’s not in the same organization as you are.

While these tools make a lot of sense for small companies, freelancers, and highly tech-savvy teams, the same is not always true for large-scale companies in the Enterprise category. Their employees are diverse in their levels of use of technology, the organization often wants to have a lot of control over access to internal information, and compliance requirements are higher than ever — something most of these tools aren’t concerned with.

From a user’s perspective, they are all far from providing the kind of control that users feel they have with MS Word, Outlook, and a good solid connection to a Windows network drive.

I myself, being a fan of many things web, am not crazy about having to login on a half-dozen different web apps, chucking things into The Cloud, and trying to convince my colleagues that this NEW web app is the one.

The key, apparently, is letting people use what they like and what they’re familiar with. Don’t try to force-educate your users – they won’t appreciate it. Leverage their existing skills, and work in your philosophy through there. The idea that email, and desktop applications like Outlook and Word are going to vanish tomorrow just because Google release a new application, browser and operating system for netbooks tomorrow, is naive. We’re not selling buggy whips just yet (Or so I hope…)

I’m new to Enterprise. I mean, I’ve been at ActionBase for what, two years now? But most of my part-time job was spent in our “recording studio” (really an office with a door that closes all the way), putting together our training and publicity videos trying to explain the new concept that is “human process management”

In the past, I’ve worked as a journalist, the occasional webmonkey, and even wrote my own webcomic for almost two years. I’ve witnessed the web experiencing its own Cambrian Explosion of products, platforms and languages.

Enterprise… Enterprise is different.

In my two years here, I’ve learned that Enterprise tends to require more maturity, where the bleeding edge can sometimes wait until it’s the scabby edge. The shiny, reflective-logo-laden web tends to forsake this reliability for innovation. Which is just fine, thanks-very-much, where geeks are concerned.

But now the Big Thing seems to be cloud computing. Is cloud computing the answer?

Cory Doctorow writes about his issues with Cloud Computing in the Guardian:

[T]he main attraction of the cloud to investors and entrepreneurs is the idea of making money from you, on a recurring, perpetual basis, for something you currently get for a flat rate or for free without having to give up the money or privacy that cloud companies hope to leverage into fortunes.

That’s a serious charge, isn’t it?

Looking at a basic configuration on Amazon — mind you, I took numbers out of thin air for this — I put up a “small reserved instance” running year-round, plus a 5% high-CPU activity, threw in some storage and traffic, and came to about $450 a month. That’s $5,400 a year. Remember, you’re getting a full-fledged, albeit non-existent, computer you need to manage. You’re not getting shared space the way you do with a web host, so you’ve still got the maintenance costs to bear.

When you compare it with buying one of these monsters that Jeff Atwood writes about at $17,000 that doesn’t sound so bad — except that you don’t buy it again every year, and the DL785 probably out-performs the “small reserved instance” on Amazon.

So maybe Doctorow is right. Cloud computing might possibly be nothing but hot air – at least until the network infrastructure catches up with computing power in terms of cost and market competition. But for now, I’m keeping my documents on my netbook rather than on the web, because my cell phone company has a 5GB cap on the “unlimited” data plan, and otherwise charges by the megabyte — the pone-minute for the 21st century.

[edit] Of course – there are other matters to take into consideration. The availability, the ability to scale up as needed (is this sort of spiking a real concern for enterprise?), but do these seriously outweigh the costs – the nickel-and-dime method of charging per CPU-cycle?

What do you think? Is cloud computing the way to go, or is it merely the new Virtual Reality? Where does your company stand on this issue?

I was reading an interesting discussion on a BPM forum about whether innovation is a odds with process. If you understand process to be a rigidly structured, unchanged prescription of how work gets done, then there certainly is truth to that. The main task of those types of processes is to make sure work is standardized, and done the same way. Innovation is frowned upon.

On the other hand if you think of process as including ad-hoc and unstructured business processes (as we do here at ActionBase) – then processes actually help with innovation. If you can gain understanding of how things actually get done  (as opposed to how they are supposed to happen) – then you can use that insight to generate innovation.

Take any structured process (e.g. CRM), and look at the work it generates outside of the system (for example via email). Sometimes the work is really an odd ball one off. But in other cases (especially if it repeats itself) it may be an indication of a new unfufilled need, or a change in the environment that should be handled. Exactly the kind of input you need to create useful innovation.

I think companies are loosing a lot of potential innovation by not capturing and analyzing the exceptions to their main stream processes – I think they would be surprised by what they learn.

I read an interesting article in the last issue of Communications of the ACM on “Evolutionary System Development” by Peter J. Denning, Chris Gunderson and Rick Hayes-Roth. In the article they lament the fact that many large scale software based systems fail (either completely, or fail to deliver on their original promise). Their basic insight is that in order to “minimize risk” before implementing a new system organizations fall back on careful preplanning, anticipation and analysis. The problem is that in today’s ever changing world – by time all that is done (and implemented), the requirements from the system have changed and it no longer meets user needs. Not only that – the system will need to continually adapt since the world continually changes and that doesn’t fit with traditional software engineering techniques. BPM systems help with at least some of the issues, but to be honest I think most BPM system implementations and methodologies suffer from the same ills as the article describes (though with much quicker time to product) – investing too heavily on analysis and modeling before some “good enough” system can be created for users to use and evolve. So even though a good BPMS will help immensely in speeding up the implementation time of structured business processes – the tools and methodologies just aren’t appropriate for most unstructured, ad-hoc human processes. 

The only way to make a usable human process management system is to embrace evolutionary development throughout -from process discovery, all the way through design and implementation. A long discovery, modeling and implementation process just isn’t viable for when providing support tools for human processes. That is why so many human processes are implemented (defacto) using email and documents. Even though email and documents are far from a perfect methodology (and require a lot of human intervention) – their critical advantage is that a “good enough” process can be available immediately, created by the people involved without the need IT involvement. For an HPMS to be successful it too needs to enable a quick first-blush ”good enough” implementation that people can use, and a simple way for the users to evolve that implementation as the process changes (either as a result of changes in the business environment, learning, or to handle various unexpected exceptions). If it can provide that (along with a familiar email and document interface), then the additional benefits of tracking, followup, status visibility and reuse should make it the preferred tool for human process management.

In my next posts I’ll address the first step – using email and ActionMail to create a fast “good enough” first implementation of the existing process that can (and will!) evolve as needed.

Here is why i think anyone who takes the time to write a meeting minutes document is practically wasting his/her time.
In general we take the time to put things in writing as a way of documenting the decisions, action items and agreements made in a meeting. The problem everyone faces is that two seconds and even before the digital ink dried on your meeting minutes paper things start to change.
Responsibilities, due dates, the nature of action items etc… that is the dynamic nature of people as they work together.
Writing a meeting minutes document is like taking a photo of a specific point in space-time and thinking that this is what is still going on right now…

As things change, people seldomly revisit the document and edit these changes, so the document becomes obsolete, a fossil of a meeting that once took place somewhere in time.

What we really need is a way of extracting these logical entities (decisions, action items etc) from the document and be able to work on them in a collaborative nature like email.
Think of a mechanism that allows you to define action items in a document, and when you are done, these action items are magically transferred to the relevant people and as they work on them, any response, change or collaborative information gathered is documented on the same action item.
Furthermore, the next time you open the document, the changes made in ‘real life’ are propagated back to the document so your ‘photo’ is actually a ‘video’ or a real time snap shot of the ever changing reality – these are actionable documents we call ActionDocs.

So we have established the idea that email clients are not cut out for managing day to day work.

Working with several people and managing action items can not be done through email. We need a new breed of email clients that are action item oriented. this type of email system will arrange information that is otherwise scattered across email messages and collate them into one single entity – the action item.

Imagine sending a request to three different people to hand out their report. With regular email you are bound to end up with minimum 3 emails and 3 attachments… and when you take into account, questions, clarification, scheduling and status updates you get a pile of email.

A task oriented email client will behave like a wiki document in the sense that once you send it out, any response, question or comment made by recipients or yourself, will all happen on the same email entry… all the relevant information under a single line item – THIS IS COLLABORATIVE EMAIL.

In ActionBase we call this email – ActionMail.

ActionMail is the next generation of work email which is task oriented rather than message oriented.

Email is SO 1.0 – and this is why we all suffer from email overload…

Let’s face, it – we abuse email into doing things it was never meant to do and this is why we face  over flooded mailboxes with no clear view on the things that matter the most.

Today’s email clients were designed for yesterday’s email. Originally, email was merely a communication medium. Today, we engage in a variety of complex behaviors using email, such as project management, collaboration, meeting scheduling, to-do tracking, etc.

There have been no thrilling innovations in email. GMail, Outlook 2007 both offer enhanced searching capabilities but the problem remains… and this is the reason why:

email clients think about “messages” – our minds think about “context”.

Context is the logical meaning which spans and transcends a specific email message or conversation thread. if i emailed someone requesting that they do something, the request or action item is the context, and this logical issue can span several email correspondence threads sometimes even across email accounts.

The next generation of mailing will have an ability to find the logical context and transform email clients to becoming context oriented and not message oriented.