I spoke at the Office 2.0 conference last week, which was superbly organized by Ismael Ghalimi and his colleagues. It was great to meet so many of the enterprise irregulars, who I’d been interacting with only digitally up to that point.
The highlight of the event for me was the chance to hear from and meet Esther Dyson, who has been a leading technology observer, analyst, and theorist for some time now.
The conference opened with her being interviewed by CNET‘s Dan Farber. This was bad news and good. Bad because I was up next, and she is an incredibly tough act to follow. Good because one of her strongest themes around the future of IT-supported work (at least as I heard her) is also one that I find critically important, and that I stressed in my speech.
Esther sees a need for what she called "lightweight project management" or "lightweight workflow." This is software that (to paraphrase and extend what she said — Esther, I’m sorry if I’m misrepresenting any of your ideas) would let one user quickly set up a business process — a linked sequence of tasks performed by people with different roles — deploy that process across all the people and groups involved in executing it, then monitor progress toward its completion.
To take a trivial example, let’s say three co-authors and I, each at a different school, are getting a paper ready to submit to a journal. We’ve got to
- finalize the analyses,
- revise the results and conclusions sections based on these analyses
- check all the references and finalize the bibliography
- give it a final once-over
- do all the formatting and housekeeping required for the journal we’re submitting it to
We’ve agreed which one of us is responsible for steps 1,2,3, and 5, and that we’re all responsible for step 4. We’ve also all agreed that we want to get the paper submitted within two weeks. At this point, what I’d really like is a Web-based tool that lets me flowchart this process, say who’s responsible for each step and what the deadline is, and set up some kind of document check-in and check-out repository. The tool would then take responsibility for telling each of us when work was ready for us, and also for bugging us as deadlines approached (and passed). It would also have a dashboard that any of us could use to learn at a glance how far along the process was, who was on the critical path, and whether anyone was behind schedule.
I realize, of course, that this is not an easy system to develop. Robust yet lightweight document version control, for example, is hard to accomplish. It’s also not a system whose exact features and functionality are clear at this point — should my co-authors, for instance, have the ability to change the process I define and deploy? Finally, it‘s pretty clear that lightweight workflow software is going to have to walk a particularly delicate balance between providing structure and being easy and appealing to use. If it doesn’t propose and enforce enough workflow it won’t be a sufficient improvement over emailing documents and updates around. If it feels rigid, unfriendly, or hard to use, in contrast, people will abandon it and go back emailing documents and updates around. For this tool, in other words, the 9X problem of email looms particularly large.
The reason I’m excited about this type of tool despite the above caveats is that it fits in a potentially large blank space in a picture of corporate IT. At the Office 2.0 conference I showed the picture below. It divides end-user-visible information technologies into three categories: those that facilitate discrete tasks, those that define then deploy structured interactions in the form of business processes, and those that allow unstructured and unplanned interactions. I label these Function, Enterprise, and Network IT, respectively.
Each of these categories is currently well-populated, but the boundary regions between them are not. Or at least, not yet. My loose working definition of ‘Office 2.0’ is the lowering of the barrier between the task and the unstructured interaction. This trend is epitomized by Google’s announcement, on the day of the conference, of Google Docs & Spreadsheets, which are exactly what one would expect: web-based and group-based tools for creating documents and spreadsheets. Google D&S gives many types of knowledge worker the choice between working individually, or as part of a team. If they work within a team, they no longer have to use two pieces of technology (Word and email, or Excel and email) to get their job done. Instead, they use one tool that spans a previously existing boundary.
Esther’s proposed tool for lightweight workflow would span another boundary — the one between structured and unstructured interactions. This would be a welcome technology for at least two reasons. First, it would match and support the semi-structured ways that lots of knowledge work (like the paper completion effort described above) gets done.
Second, it could also help appropriate business processes form and solidify over time. As I wrote earlier, the best configuration for a given business process isn’t always clear in advance, yet the enterprise systems we have don’t typically lend themselves to quick-and-easy process tweaking. They’re great for embedding a process once it’s developed, but not so great at experimenting and iterating to come up with a good process. So lightweight workflow software could be both an end in itself and a means to accomplishing other ends.
We’ll always have a need for technologies that rest squarely within the borders of the task, the structured interaction, and the unstructured interaction. CAD systems, ERP, and email are not going anywhere. And we’ll continue to see new beneficial technologies appear within each of these categories. I agree with Esther that a wiki is simply a container, but that’s exactly what we need for some purposes. When I launched my course wiki at the start of last semester I didn’t want it to have any traces of structure, workflow, or hierarchy. I wanted those to appear over time based on what my students did with the tool.
I imagine that some of the most interesting near-term corporate technology developments, however, will come at the intersections between today’s technology categories. Clever technologists and entrepreneurs are going to take advantage of the current ‘building blocks’ of IT — abundant bandwidth, lively browsers, fast development environments, more link-able applications, etc. — to build tools that cover and support more of the modes of corporate knowledge work, and that cross current lines rather than staying within them.
I have to confess that I’m not up to speed on all the applications and sites that currently provide something like lightweight workflow. I understand, for example, that Itensil does something close to this, but I missed the chance to get a demo from them at the conference. I take some comfort from the fact that if I’ve overlooked the ‘silver bullet’ tool then Esther has, too, since she talked about lightweight workflow as a desideratum rather than a done deal. If you know of good boundary-spanning technologies, please leave a comment and tell us about them.