Bringing Outlook into the Internet age

Until recently, I had only used Outlook for a short period in 1998-99. It was okay, but I only used it inside a corporate context. The feature I most enjoyed was the calendaring and appointments function. I've tried several email clients since then and settled on Gnus as the most useful I've found.

Over the years, I've participated in a number of mailing lists, and I've noticed that some people struggle with what others regard as basic courtesy: failing to trim excess quotations out of replies and top posting are things many seem to get complaints on. I've wondered why that was so hard to get right. (If you're wondering what's the problem with top posting, see the example at the bottom of the Top Posting section on Wikipedia, starting with "A: Because it messes up the order....")

Now I'm back using Outlook in one part of my professional life, even as I continue with Gnus in another. I begin to see why people struggle with some of the basics. It's quite hard to do the basics well in Outlook, including trimming quotes and bottom posting. Seeing real email addresses involves extra work, and the Outlook text editor is limited in its power. After using Gnus for years, I get the impression of Outlook as a tool with limited capability even compared to simpler tools such as Thunderbird. The only advantage I see to Outlook is its appointment tracking, and one can do that in multiple ways today including with the free Google Calendar.

Yet I realize most Outlook users have little say in which client they use. I recently found a tool that seems reliable and does help offset Outlook's weaknesses: Outlook QuoteFix (there's also a version for Outlook Express, although I've never used it nor OE). If you use Outlook and communicate with people on mailing lists or with people who don't use Outlook, check it out. It's been quite unobtrusive so far and lets me treat email either in the Outlook fashion or in ways I've grown comfortable with over the past 20+ years of using Internet email.

PS: Gmail didn't do it so well, either, the last time I tried it; it put the cursor at the top of replies. In researching this article, At least it's not too hard to do it manually in Gmail. I found Gmail bottom posting in replies, which seems to promise help.

How do you think in Word?

Now's your opportunity to help me, especially if you mostly create text using a markup language but occasionally use a word processor.

First a disclaimer: I think it's likely we all learn, think, and work somewhat differently. The fact that I work one way doesn't mean I think you should necessarily work that way, too. Somewhere I recall reading that many people (especially technical people) tend to pick one main tool, master it, and arrange the rest of their work around that core. Today I'm asking how you work when you have to work outside of your core toolset.

Now some background: I've used word processors for quite a few years, starting with Speedscript, AppleWorks GS, and then Word 5 (or was it 4 or 5.1?). I've used many versions of Word up through 2007 at some level of intensity. A few years ago, I worked on a successful documentation project that involved on the order of 100 Word and Excel documents, some quite lengthy (I seem to recall one in the 700 page range).

At some point, I discovered markup languages. I started with nroff and later moved to LaTeX. After that Word project, I moved to DocBook and completed a follow-on project that garnered some nice praise for having gotten around some of the challenges of the first project while producing quite readable and professional-looking documentation. I currently use asciidoc, LaTeX, DocBook, and J Publish.

In all of this, I find it helpful to have great tools. I've built my toolbox around GNU Emacs, starting around version 18.24. For LaTeX, I use AUCTeX; for DocBook, I use nXML mode and eDE on Windows or any of several toolchains on Linux. antiword is handy for converting other people's Word documents into a form I can import into one of those tools, and I make use of revision control (currently bazaar) and makefiles to help with organization and productivity while reducing the chance for unfortunate mistakes. I've used cweb when writing about simulation models.

Despite my tendency to use markup languages, I do still use a word processor from time to time. OpenOffice.org write is my current preferred choice, because I find its approach to styles is robust and easy to use, because it stores files in an open format, and because I haven't lost an OpenOffice.org document yet.

I often think by writing. I am noticing that I find it easy to think when writing with a markup language, but I'm finding it much more challenging to think effectively when faced with the simultaneous content and layout creation tasks in a word processor. While I sympathize with much of this rant, I'm looking for solutions, not conversion, today.

The first question: if you, like me, work well in markup languages, how do you think when writing in Word? Are there tricks to the setup to make it easier? For example, I think there used to be an unformatted mode in which you basically just saw text. That sounds attractive, but I thought it had been deleted from Word. I spoke with a former journalist recently, and he noted that he often composed text in email and then pasted it into Word for formatting. What other ideas can you suggest?

The second question: how do you format the final document? I know the "right" answer: create and use styles and templates, yet I find that harder to do in Word than in OpenOffice.org or even than in systems such as LaTeX. Do you have any tips, especially for those situations in which you're working with documents that were created at least partially with direct formatting?

Literate modeling and neatness

Neatness and organization count for something, right?

That's what we were all told growing up, I imagine, and it is a pleasure to work in a neat environment.

Then why do (I suspect) so many of us who model have directories with files named model-2008-10-15.model, model-2008-10-15A.model, model-2008-10-16.model, etc.?

It's because we were also told that modeling is an iterative process, which it very much is (one student in one of my classes thought "Iterate" must be my name). If we iterate on models (writers do the same), and if we want to keep older versions around just in case we need to go back to one of them, we end up with heaps of models to keep track of.

Literate (and text-based) modeling can help. Instead of filling directories with files, I now have one model file per model, and I let bazaar, my revision control system, track the history of that file. If I want to see what it looked like last week (or last month), I simply check out the old version or compare it to the current version. Bazaar tracks comments by revision, too, so it's easy to find the model I created to address a particular issue (assuming I noted that issue in the comment for that revision).

Why do you care? Have you ever worked with someone who couldn't find an aspect of the work you needed to see? Have you ever "improved" something you're working on, only to find a prior version was better? Perhaps literate modeling, text-based modeling, and revision control are in your future!

asciidoc isn't just for small documents anymore

I've used asciidoc for quite a while as a tool to generate small reports for clients. As I've discovered how easy it is, I'm also using it to keep notes. The lightly formatted (perhaps stylized would be a better word) text is better organized visually than simple text, and, if I need to turn it into typeset text, it's pretty easy to convert it into a range of formats: HTML, XHTML, PDF, RTF (and, from there, DOC), ODT, and more. I've tested its ability to create (LaTeX) beamer presentations and might use that regularly if I didn't stretch beamer a bit more than the asciidoc beamer translator supported at the time.

Yet I had fallen for the idea that asciidoc was for small documents, at least until I read Noah Slater's posting on the asciidoc mailing list saying he was using it to write a book that will be published by a professional publisher using their DocBook backend processes.

What do you need to use asciidoc successfully? I started using it on Windows with Emacs as my editor. I now use it on GNU Linux (Ubuntu, to be specific). Both work just fine. It seems easier to set up any backend processes on Linux, but your organization can set those up once and then users don't need to do that configuration themselves.

To get from asciidoc to PDF or RTF requires you have a DocBook toolchain. That's fairly straightforward on Linux; the main challenge is figuring out which alternatives you like. That's more of a challenge on Windows, but I have found the e-novative DocBook Environment (eDE) to be extremely easy to use.

Those of you who like HTML documents but struggle with the problem of distributing them by email (you have to attach any images as separate files and then rely on the recipient to manage them properly) might like asciidoc's ability to use data URIs. That means you can embed images inside the HTML file, so you only have the one file to distribute.

While you're looking at asciidoc, check out their examples using asciidoc to produce diagrams with graphviz, to typeset musical notation, and to create Web sites, in addition to simply creating articles and books.

R in the news

If you're nervous about applying free software in your work, see what the New York Times had to say about R, the free statistics system. Thanks to Andrew Gelman for pointing out that article.

I'll highlight another free tool in my next posting.

Introducing literate modeling

Organizational modeling has much in common with programming. If you create or ask for organizational models in any one of a number of text-based systems, you likely realize that. If you use any one of a number of GUI-based systems, you may recognize what you're doing as visual programming.

In organizational modeling, the challenges are many:

• How to create a competent model
  
• How to make the process transparent so others can collaborate and still others can benefit
  
• How to organize the model in ways that are understandable both to people and the computer
  

It's both easier and harder than it sounds: it's easier to produce useful, insightful models than many might think, and it's harder to create solid models than some would have you believe.

Despite the claims of some, I don't think there's one right way: I think we need a diversity of approaches. To that end, I've been exploring text-based modeling and simulation for the last few years. Recently I've begun to merge the ideas of literate programming and organizational modeling into what you might call literate modeling. Strictly speaking, that's only doable with text-based modeling languages. It brings with it a few features that seem important:

• Thinking about the model and creating the model go hand-in-hand. I've already found that text-based modeling has helped me think in new and deeper ways about the problems I've addressed, and literate modeling strengthens that thinking by linking them even more tightly.
  
  Why is that so? Part of the reason has little to do with literate modeling and textual programming per se: I found that splitting up the work of modeling and simulation into different types of tasks (conceptualizing and modeling a problem, designing experiments to test theories of action, analyzing and thinking about experimental results, and communicating those results to others) helped me do a better job at each stage.
  
  Literate modeling adds a writing component, which may help us think more carefully about our modeling decisions, to the modeling process. Forcing the explanation of the model to go hand-in-hand with its creation seems to keep me from making assumptions I can't support. In fact, I tend to let the writing drive the modeling, which I think drives models even more from the aspect of hypothesized causality than from the aspect of what works technically. You can see what others have said about literate programming; I think those ideas apply to literate modeling, too.
  
  Of course, you can document normal models extensively, too. As others have said, literate approaches link the thinking required to explain a model (or a program) to other people tightly to the model (or program) itself; the model flows from the thinking and writing instead of the writing becoming partially a reverse engineering of the model code.
  



• Model consumers, collaborators, and even developers think most naturally about models in a sequence that doesn't necessarily match the sequence needed by the simulator. Literate modeling allows you to decouple those two sequences completely.
  



• To explain a model, you sometimes need graphs, diagrams, pictures, tables, or other non-textual components. A good literate modeling system can integrate all those components easily without being tied down to the features offered by a particular simulator. In a way, this is the old Unix philosophy: use a collection of smaller tools, each well-suited to the task at hand, and put them together flexibly as you need them.
  



• Literate modeling is one approach to applying some of the best of the lessons of software engineering to a related field in order to do better work.
  

Why do you care? Why should you care?

If you work with or use organizational simulation models to make better business or organizational decisions, perhaps literate modeling offers you a way to have more transparent, more collaborative, more understandable, and more well-thought-out models. Better models, applied appropriately to generate better insights, might just help you make better decisions. Better decisions, carried through with good implementation, might just lead to better results over the long haul.

Is literate modeling or, for that matter, text-based modeling the only way to go? By no means! By the rule of diversity, if nothing else, that would be wrong. Each of the graphical modeling tools I use has brought its unique strengths to the problem-solving process, and I continue to use them. "Horses for courses," as they say. Yet don't count out text-based tools for effectively engaging those with whom you're working, don't think that text-based modeling and literate modeling has to be ponderous, and don't count out the power of text and writing to help you think more effectively about the challenges you face.

What do you think?

Secret tool for online meetings

Have you ever sat in an informal (no slides) Web-based meeting and tried to keep up with what's going on? When the meeting was over, have you wondered what was decided?

Here's a small secret: I've found it helpful to use FreeMind, a free mind-mapping tool, to take notes during meetings. I often share Freemind through the Web-based meeting tool so that it works as a virtual flip-chart: everyone can see what I'm recording, people can suggest corrections, and I can hide parts easily when we're addressing other issues. When the meeting is over, I can convert it to PDF or HTML or any of a number of other formats and distribute meeting minutes with no additional work.

That's very related to Bernie DeKoven's technography (be sure to watch the video to understand how this works).

Try it sometime; you might find you like it.

Staying in touch

On a lighter note, I've been using Twitter for a while now, and I've even installed the light-weight Twitux to make it easier (trivial to do on Linux, but you can also just use your Web browser). I'm beginning to see Twitter's benefits: for one, it enables the casual sharing of ideas one has in an office without the interruptions of an office, for you can always ignore a tweet for a while.

If you'd like to stay in touch more informally, follow me on Twitter. I'm not an overly frequent tweeter, but it's yet another way to maintain contact in a distributed world.

Exploring GTD

I read Getting Things Done: The Art of Stress-Free Productivity some time ago, but I stopped at the prospect of organizing everything I had in order to get started.

Now I've come back to what I see as the essential ideas, and I'm giving it a try. As I see it today, the essential ideas for me are

• Create lists of tasks organized by their context—the place I'll be when it makes sense to do them.
  
• Don't prioritize inside those lists unless there's a hard deadline (a meeting to attend, for example).
  
• Review and update the lists frequently.
  

There's the question of how to manage those lists. I tried HipsterPDA, but it felt wasteful to use new 3x5 cards when I had lots of scratch paper and a decent amount of disk space available. I tried scratch paper (the backs of advertising letters I receive, a habit I learned from my colleagues at my first job), but they get messy. I tried using various TiddlyWikis, but I'm not always at my computer when I want to write something down or check a status.

I'm currently using a hybrid:

• I use GTD TiddlyWiki, partly because it's made for GTD, and partly because it claims to print tiddlers on 3x5 cards (something I haven't had to do yet).
  
• I use folded-up scratch paper to record new things as they occur to me; I transfer them to GTD TiddyWiki unless I take care of them first.
  
• I use Patrick Rhone's Dash/Plus scheme for annotating to-do items recorded on paper (found initially via Joe Ely's article).
  

So far, it's helping me, perhaps only in proportion to the rigor with which I use it. I've still got too much that's not in the system, but I'm working to incorporate more of my stuff in the system (or to get rid of it, if I can).

How do you focus your attention on the important things effectively? If you're a user of GTD, do you have any suggestions?

If you want to figure out where your time is going, I still recommend the time log that's part of the learning log package Bob Williams and I produced.

It's good enough for the whole Chorus

First it was Kate Lister, then it was Phil Woolas, then it was Fast Company, and now it's a whole Chorus. See how a small software company has become totally virtual.

It's good enough for Fast Company

I wasn't planning on continuing this thread, but Fast Company sent me a pertinent link this morning, predicting that "Within five years, technology will obliterate the need for business travel."

While I can conceive of video offering certain benefits, I wouldn't suggest waiting for technological solutions. Perhaps one of the most engaging and effective courses I've ever attended was the all-text-based email AREOL, put on by Bob Dick at Southern Cross University twice a year since 1995 (the year I took it). The key lies in the people and the process, not necessarily the advanced technology.

How can I help you today?

It's good enough for Phil Woolas

Yesterday I wrote about working without travel or commuting. Apparently Phil Woolas, UK Minister of State for the Environment, sees things the same way; he delivered a keynote speech at the Annual Climate Change Summit in Sydney while remaining in London.

What have you been doing to reduce GHG emissions, reduce fuel usage, and thereby improve productivity? I'm curious, and I'd welcome your comments.

By the way, it's my experience that you don't need a lot of technology to make working remotely successful; you just need to think and plan carefully how you'll be effective.

Why go to work today?

Why go, indeed?

Some time ago, I described why I think most of you have had me work remotely over the last eight and a half years and how that has helped you and society. Now Kate Lister makes similar points on The Oil Drum.

The Toyota Communications System and sliduments

Presentation Zen says it all.

Is Linus Torvalds lazy?

You've read about lazy employees before. Now I read from Jason Stamper that Linus Torvalds has said, “Intelligence is the ability to avoid doing work, yet getting the work done.” Is he lazy—or simply effective?

More on workweeks

I've written before about the lazy worker (a very popular posting), an ethical advantage to shorter work weeks, and how managers' jobs, done well, can make their employees' (and their) workweeks shorter.

In All In A Days Work on the Fast Company site, Dave Roberts writes of evidence that shorter workweeks and higher productivity may go together. What do you think?

Thanks to the TP! Wire Service for the tip.

Top postings of 2007

In the last 12 months (to be precise, from last December 28, the day after the Top postings of 2006 entry through December 26, 2007), you have chosen ten top postings on Making Sense With Facilitated Systems as ranked by unique pageviews in Google Analytics.

As I noted last year, there are potential statistical problems with this list. Those who read my blog every day using the main URL don't get counted; both last year's and this year's tallies were made from those who landed on specific URLs as reported by Google Analytics (but excluding visits I may have made). That may be okay; those who linked to specific pages may have cared more about them. Recent entries have a more difficult hurdle, as they haven't been around as long to be viewed. The dates don't quite line up with the calendar year, although I suspect that makes little difference in the results. If you know of a better way, let me know.

10. For some time now, I've been using an open source simulator for my system dynamics work because it seems to help me think more effectively. That doesn't mean I've given up on commercial tools; I still use iThink for creating interactive environments, and I will be teaching IMT 586 at the University of Washington using Vensim PLE (and I may be using it in professional applications, as well). Last April, I combined my interest in the arts with my interest in this new approach to system dynamics in a public article about marketing program for symphony orchestras. You selected TAFTO 2007, the pointer to that article, as number ten on the list.
    



9. I've written several articles about data and numbers. Making more sense with numbers part 3 offered an easy process to plot data you receive in email or reports.
   



8. The words we use can be vitally important in helping us think productively about key business, organizational, and social challenges. In A systems language for business, number eight on the list, I described one team's evolution towards a better language for discussing business issues, thanks to a course they took from me in system dynamics modeling and simulation.
   



7. Good data helps us ground our thinking in reality. Still more on data, a pointer to several online sources of data, captured the number seven spot.
   



6. Growth can create problems (witness any of the bubbles that have occurred over history), but where are good examples of successful companies that intentionally don't grow? Number four on the list is Small Giants: the American Mittelstand?, pointing to a book that answers that question.
   



5. Sometimes old technology still has utility; sometimes it still attracts interest. At number five, Technology comes full circle, a description of my continuing use of a slide rule in my work, certainly fits that description. For those who are interested, it points to a source for new slide rules.
   



4. When I first started work as an engineer, PERT charts were done using mainframe computers or hand-drawn charts. Today, project management has become a profession with a certification process, and automated tools with graphical user interfaces have long since replaced tables of numbers and dates. Your sixth-most-popular entry was Critical chains: a decade later, my revisiting of Eliyahu Goldratt's critical chain theory that linked to Tom von Alten's revisiting of his views on the approach.
   



3. Productivity is obviously important to you. Your third most popular posting of the year was a surprise to me: If you can say it, it's done, an entry about the array programming language J.
   



2. Barry Richmond has a deserved place as an educator and thinker on system dynamics and systems thinking. I posted a link to an article he wrote about systems thinking and followed up with "Scientific thinking" the modern way, a differing view on the application of modern scientific thinking in system dynamics. That was your second favorite posting from 2007.
   



1. The 2007 posting you viewed the most was the series Making musical sense by email, showcasing a conversation between music critic, composer, author, professor, and consultant Greg Sandow and me that used a system dynamics model to explore the aging of audiences for symphony orchestra concerts in the USA. Now I'm curious: was its popularity because of the topic (music), the approach (a somewhat novel approach to using system dynamics), or the fact it was a real conversation between two people? Let me know.
   

All of those postings were made in 2007. It wouldn't be fair to finish this list without noting that some postings from prior years did rank higher than some of these. Here's the all-time top ten list of postings from Making Sense With Facilitated Systems as measured by your viewings in the last twelve months:

15. TAFTO 2007 (2007)



14. Making more sense with numbers part 3 (2007)
    



13. A systems language for business (2007)
    



12. Still more on data (2007)
    



11. Small Giants: the American Mittelstand? (2007)
    



10. Technology comes full circle (2007)
    



9. System Dynamics for Cheapskates (November 2006)
   



8. Critical chains: a decade later (2007)
   



7. If you can say it, it's done (2007)
   



6. "Scientific thinking" the modern way (2007)
   



5. Making musical sense by email (2007)
   



4. System dynamics with MCSim (November 2006)
   



3. In praise of the lazy employee (April 2005)
   



2. System dynamics and program evaluation (June 2005)
   



1. Making sense with numbers (November 2006)
   

That list includes the top ten postings written in 2007 plus the five entries written in prior years that were at least as popular as the top ten 2007 postings.

As 2007 draws to a close, I want to thank you who read Making Sense With Facilitated Systems and to invite you to continue with me in 2008. If you have suggestions or feedback for this blog, contact me.

I would be honored to be of service to you or your organization in 2008. If you're trying to make sense of tough business or organizational challenges, curious how I might be able to help, or just want to talk about some of the issues you face or that I write about, get in touch.

High-performance organizations

Do you want your organization to perform dramatically better than it does today? What's holding it back? What's holding you back?

Ralph Sink has an idea, based in his experience, and he describes it in My Unfashionable Legacy in strategy+business. I've led that sort of organization before, and I found it amazing what such an approach can accomplish.

Thanks to Fred Nickols for bringing this to my attention via the ODnet mailing list.

Finding a consultant - remotely

In less than a month, Facilitated Systems will have been in business for eight years. I've worked with people in Asia-Pacific, Europe, and the Americas, and yet I've rarely seen a client, for I work mostly from my office.

In today's world, that has distinct advantages. For those of you not used to working remotely with a consultant, I'll list a few:

Responsiveness

If I came to your site to work, I'd likely save up tasks until I had half a day, a full day, or perhaps several days of work at once (depending upon how far away you are), because it's more economical. That's a delay for you.

If I work remotely, you can get my attention in the size chunks you need: minutes, hours, days, weeks, or months. The delay from asking a question to getting an answer drops; if I'm available when you call, you'll start getting help immediately. If you do have to wait, the wait will likely be shorter.

Speed

You can get my help now, without waiting for me to fly, drive, or take a train. If I'm working on someone else's tasks, you need to wait for me to finish those. That's where responsiveness kicks in: if it's appropriate, you may well get some of my time starting today, rather than having to wait until I have full days available.

Lean

If I'm traveling, I'm not working for you. Sure, I try to work on planes when I can, but there is much to the travel experience that represents pure muda. Moving me to you is the essence of transportation and waiting waste.

Cost

If there's no travel, you don't pay for travel. Simple.

Carbon friendly

If I'm not traveling, I'm not generating as much CO₂.

Petroleum friendly

If I'm not traveling, I'm using less petroleum.

Congestion friendly

If I'm not traveling, I don't add to traffic congestion.

Resources

If you need a team, assembling a remote, distributed team from my contacts world-wide to help you brings all these benefits in spades.

How did I discover this? You folks taught me. When I started out, I expected to spend significant time in a car or on a plane, even as I expected to do some of my work remotely using the phone, email, and other online tools. With rare exceptions, you who hired me were quite happy to have me sit here and work there. As times have changed over the last eight years, your insights seem wisely prescient.

Some tasks do require a consultant at your site. I've done that, I will do it again, and I do enjoy working together with you in person. So call if you think that's what you need.

I have also discovered that it's possible to share ideas, build trust, work on problems, and make a joint contribution without being there in person. If that's what you seek, call me, too.

Which serves you best?

Multitasking

I recently saw a television advertisement promoting someone's smart phone that could make you more productive by helping you multitask more.

In light of what I'm reading elsewhere about the risks of multitasking, I thought it worthwhile reflecting on what multitasking does.

In the old days, computers did one thing at a time. That was efficient for them, but it wasn't always great for us. We humans began to see the advantages to us of their doing more than one thing at a time. That is, I benefit if I can be printing a document, updating software, and reading my email, all at the same time. In that case, I'm only doing one thing: reading email. I told the computer to print the document, and I'll pick it up later when I walk by the printer. I told the computer to get the latest version of a certain application; I don't have to do anything else, and it will be ready for me when I next use it. I can now read my email without waiting on the other tasks to finish. In addition, the computer may be doing other useful things (for example, getting new email) without me having to even ask. That can be very good for me.

From the computer's standpoint, that can be a problem. The computer has to do more work multitasking than if it were only doing one thing at a time. The good news is that computers have gotten faster, and they've gotten features that help them multitask more efficiently, so they have the capability to keep up with our demands (at least most of the time).

So when someone talks about productivity and multitasking in the same sentence, make sure you know whose productivity they're talking about. If this multitasking stuff works as it has in the past, your multitasking may enhance someone else's productivity, but it makes you work harder. That can only work if you have the excess capacity (time) to get all your work done and manage to switch between tasks efficiently. Did you get that quad core brain implant last week?

Critical chains: a decade later

I first read Eliyahu Goldratt's Critical Chain : A Business Novel in 1998. I was sufficiently intrigued by the critical chain approach to project management that I summarized my notes for an internal Web page at my company in March 1998. Tom von Alten worked for the same company and also wrote up his thoughts on critical chains; we cross-linked our pages to give people two somewhat differing views of the approach.

It's now almost a decade later, and Tom and I have been discussing project management again. We decided to post slightly edited and reformatted versions of our original pages to let you see what we were thinking back then and to provide a reference for those of you who might want to know more. I've integrated my three pages into one long post so that it's easier to find as a whole.

---

Project Management Revisited: The Theory of Constraints

Eliyahu M. Goldratt's book, Critical Chain, applies the theory of constraints to project management. He implies ~25% improvements in project duration are possible the first time it is applied.

The basic steps

1. Draw the project plan in PERT chart form; make sure each activity has a time estimate. Assign resources to the steps, and shuffle steps in time until no resource conflicts (i.e., two steps needing to be done at the same time by the same resource) occur. Identify the critical chain (the longest chain of dependent steps, including path and resource dependencies).
   
   
2. Cut the time estimates of each step in the critical path in half (this approximates the median step duration). Add a project buffer at the end of the critical path equal to half the time you cut from the critical path.
   
   
3. For each path which feeds into the critical path (so-called feeding paths), cut the times of the individual tasks in half and place a feeding buffer just before that path feeds into the critical path.
   
   
4. When a person or group is a week away from entering the critical path, send them a reminder. Repeat that reminder at 3 days and 1 day prior to their projected entering of the critical path. When the time comes for them to start a step on the critical path, they are expected to drop whatever else they are doing to focus on the critical path step (this provides a resource buffer by ensuring that the critical path won't have to wait for them to come free).
   
   
5. Set up a daily (one colleague suggested that weekly might be more appropriate) metrics collection and reporting program.
   
   
   
   
   • For each step in the critical path, capture the number of days until that step hands off to the next step.
     
     
   • If that number increases by x, remove x days from the project buffer. If it decreases by x, add x days to the project buffer.
     
     
   • Do the same things for each feeding path.
     
     
   • Report those numbers daily (weekly), prioritized by those steps which are decreasing the project buffer and then by those which are decreasing a feeding buffer.
     
   
   

This cuts ~25% off the current plan without a change in work content or resources. Future improvements are possible and expected; see the next section for more details.

The five steps of the theory of constraints

These steps restate the above process with more focus on TOC terminology. Any book or paper on the theory of constraints will reference these five steps using Goldratt's unique terminology.

1. Identify the system's constraint.
   
   For project management, the constraint is, to a first order approximation, the critical path from the PERT chart. By incorporating resource needs, one arrives at the critical chain, the precise constraint.
   
   
2. Decide how to exploit the system's constraint.
   
   Make sure it stays busy. First, remove time buffers from the individual steps by using 50%, not 80% or 90%, confidence values for expected durations. Cutting traditionally estimated times in half is the suggested heuristic.
   
   Next, install feeding buffers to ensure lateness in a non-critical chain step won't impact the critical chain and resource buffers to ensure that resources are available when their contribution is needed to the critical chain. The suggested length of such a resource buffer is half the amount that was removed from the path it's protecting, thus giving a 25% savings on each feeding path.
   
   Finally, because there is variation (uncertainty) in the estimates for the durations of critical chain steps, install a single project buffer at the end of the project to buffer the scheduled completion date (and the customer) from that uncertainty. Use the same algorithm as for feeding buffers, giving a 25% savings on the overall project duration.
   
   
3. Subordinate everything else to the above decision.
   
   Don't work on something just because you think you have to keep busy or be more efficient or productive. Ensure you have excess capacity in all the feeding paths to keep the constraint (the critical chain) busy and to catch up from any delays in the feeding path steps.
   
   
4. Elevate the system's constraint.
   
   Increase its capacity. Add resources in ways that shorten the critical chain; improve processes along the critical chain.
   
   
5. Repeat the process.
   
   If the constraint has been elevated successfully, it may very well no longer be the real constraint. When the constraint has been elevated, re-assess the current critical chain, which may lead to repositioning and redimensioning buffers.
   

A change in work philosophy

In the traditional way of managing projects, people are expected to stay busy, and departments are expected to avoid wasting money by eliminating excess capacity. This presumes that having uniformly busy people contributes directly to faster project completion and better business results.

The TOC approach calls for a focus on the system's constraint (the critical chain). The parts of the organization on the critical chain should be running at capacity.

The difference is how one treats work off the critical chain. Those areas should be running explicitly at less than full capacity, because they need reserve capacity to make up for the unavoidable slips which occur due to activations of Murphy's Law.

A change in metrics

The fundamental changes are to stop measuring what percentage of the total work is done, how busy everyone is (area capacity utilizations), and when individual steps should be and are completed.

The fundamental and perhaps only measure becomes how much of the various buffers (project buffer first, then feeder buffers) remains. Changes which reduce those buffers are warning signs; changes which increase them increase the likelihood of completing the project by the scheduled date.

Assumptions

I have listed the assumptions which seem to underlie the critical chain approach to project management here for people to attempt to disconfirm them. Lack of success at such disconfirmation attempts would seem to indicate strength in this approach. I've tried to list them as major points with underlying corollaries capable of being derived from those major points.

• Traditional business philosophy says improving any parts of the whole provides equivalent benefits to the whole; in reality, a very few parts have an overwhelming contribution to the performance of the whole (much more concentrated even than the "80-20" rule).
  
  
  
  
  
  • Monitoring the percentage of work completed causes a focus on tasks which works against on-time completion of the project.
    
    
  • Focusing on ensuring that each step completes on time will not ensure the project completes on time.
    
    
    
  • You don't protect the integrity of the project schedule by protecting the integrity of the schedule of each step (by adding safety factors at each step); you must protect the goal of the project schedule by putting in safety factors (time buffers) just in front of the customer (at the end of the project) and just in front of the project's constraint (the critical chain) (i.e., putting feeding buffers where any path in the PERT feeds into the critical chain or where any resource constrain threatens the critical chain).
    
    
  
  
  
• There is excess time in most project schedules (analogous to excess inventory on most production floors) which can be removed by proper focus.
  
  
  
  
  • We inflate our normal task (step) estimates to
    
    
    
    • account for interruptions and multi-tasking, and to
      
    • give ourselves an 80% or 90% chance of completing the task on time.
      
      
      
      
      
      • Given the skewed right nature of the probability distribution of most task duration estimates, this easily translates into about a 200% inflation in time when compared to the median of the distribution.
        
        
      
      
      
    
    
    
  • We often waste safety buffers we give ourselves by
    
    
    
    
    • not starting a task until any such buffer has gone by (procrastination),
      
      
      
      
      • Since we don't know until we're well into a task whether there are unfortunate surprises ahead, by waiting to the last minute to start, any surprises we find affect the completion date directly.
        
      
      
      
    • trying to do multiple tasks simultaneously (multi-tasking), and
      
      
    • allowing dependencies between tasks to accumulate delays and waste advances.
      
    
    
    
  
  
  
  
• Local efficiencies and productivities don't count.
  
  
  
  
  
  • People don't have to stay busy all the time.
    
    
  • People shouldn't stay busy all the time, because then you don't have the excess capacity you need to protect the system constraint.
    
    
    
    
    
    • If you don't protect the system constraint (in project management, the critical chain), your overall goal will suffer, even if your metrics at individual steps appear in order.
      
      
      
      
      • Measuring individual steps, unless they are a part of the constraint, is likely to lead you to do exactly the wrong thing.
        
      
      
      
    • There is a new work philosophy:
      
      
      
      
      • If it's too early to start a step (on the PERT chart), do nothing.
        
      • If it's not too early, work as fast as possible on that step.
        
        
        
        
        • By having removed the safety from each step, you have nominally only a 50% chance of completing the step on time.
          
          
        
        
      
      
      
    
    
  
  
  
• Conflicts are a clear indication that someone has made a faulty assumption and not a signal to compromise. (This is a lesson Goldratt claims to have taken from the scientific world into the business and sociological world.)
  
  
  

To find out more

The original article listed several references. I've already listed Critical Chain and some of the others elsewhere. I once pointed to a Robert Newbold article I can no longer find, but there is a long list of papers he and others have written on the subject.

For Tom Tom von Alten's insights on the critical chain approach, see his book review of Critical Chain, which includes snippets of PERT charts showing this more graphically.

---

That's what I thought almost a decade ago, and you can find out what Tom thought back then, too.

I'm curious: have any of you tried critical chains in your organizations? What have you learned?

What moves us forward?

What moves us forward? According to a recent article in the NY Times, The Unsung Heroes Who Move Products Forward, it's the creation of innovative processes and infrastructure.

Thanks to the TP! Wire Service for the tip.

Technology comes full circle

This goes in the category of a small productivity hint to those of you who have to manage or moderate presentations from time to time. One of the challenges is to keep to a schedule; in the midst of presenting, presenters can wax eloquent and use more words (and thus time) than they intended. Assuming you can signal them somehow, how do you figure out whether you're in time trouble or not?

I moderate online meetings from time to time, and I've tried different approaches. For some time now, I've been using a circular slide rule. It's fast, it's easy, it's small (inconspicuous, if you're working in front of others), and the circular slide rule ensures you never have to re-orient the rule. If you'd like to try this approach but don't have a slide rule sitting around, check out Concise. They make a variety of circular slide rules. I'm using a smaller, pocket-sized model they no longer make, but I'd be interested in their 300 today. For this work, though, the 27N or 28N would do quite nicely.

If you're not ready to buy one, consider a home-made version.

Do you manage people who program?

Do you manage programmers or software engineers, people who write code for a living? If you do, check out Paul Graham's Holding a Program in One's Head. It explains the importance of getting a program into a programmer's working memory ("head") and the damage to results and productivity that can be created by distractions. I think the same applies to certain other fields, too. I know that modeling and simulation work quite resembles programming in that regard; perhaps you can list other fields where it takes significant time to get all the pertinent information into our heads before we start real work.

As an aside, Graham recommends succinct languages for more powerful results. J is one language that's quite succinct and quite powerful. It's easy for many of us to use as aids in our current work; that's why I recommend it for managers and knowledge workers, not because we're dense but because our primary contribution isn't programming, and I find J augments my capability without making me a programmer. I also recommend J for serious programming work, for I've seen what true J experts can do, and it's both impressive and leverageable.

Making more sense with numbers, part 4

Now that you've got an easy way to capture numbers out of emails and documents, how do you get numbers back into emails?

Graphs are great, but perhaps you don't want to use attachments? Check out Gnuplot's dumb terminal mode as a way to create plain text graphics. If you keep it simple, you can convey decent graphical information with plain text (as long as your recipients use a non-proportional font in their email client for plain text emails—a very good idea, anyway). I tested this approach in a public discussion and found some liked it and some didn't.

Perhaps you really do want to include a table of numbers or numbers and words. If you're working in J, it's pretty straightforward to create the table you want and then use J's clipfmt and wdclipwrite verbs to create something you can simply paste into your email or other document.

If you're using J, you can create your (text or other) graphics in Gnuplot, if you prefer, or you can create them in J directly.

Incidentally, this note and its predecessor have addressed specific cases of the more general problem of getting data into and out of J, a problem I think lots of newcomers to J discover early on. It's easy to do powerful calculations in J, but manually transcribing the data from another window into J or from J into another document loses all the benefits. The J Wiki has a page called Interfaces that might help. I've found the Text Files page quite helpful in getting data out of plain text files. Any statisticians reading this might find the interface to R useful.

Working together at a distance and across platforms

Solveig Haugland recently asked what tools she might use to share her desktop with others. One constraint: it had to work on a Linux platform.

Some of you might benefit from the answers. Even if you don't use Linux, perhaps some of those with whom you work (or want to work) do.

If you've got other suggestions, I suggest you post them on Solveig's blog; then we'll all have one spot to reference. Of course, if you want to comment here, too, you're always welcome to.

Moving to Linux

I don't think moving to Linux is for everyone.

For one thing, part of the reason we have as much malware as we do may be that there's one predominant operating system, so it pays to figure out ways to exploit it. Sure, some operating systems seem more bullet-proof than others, but having one main target for malware writers, no matter whether it's Linux, Mac's OS X, or Windows, seems like risky business. Spreading people more uniformly around the major operating systems and then providing data interchangeability (e.g., exchanging data through adhered-to standards for XML or plain text) seems like a more robust solution.

For another, you may have certain programs you need to run that only run on one or the other operating system. I can think of one or two major programs I need to run that require Windows.

Still, if you've been using one operating system for a while, you may not know what exists elsewhere. That's why it's good to see LinuxLinks' list of Linux alternatives to popular Windows programs. While it's missing major programs I use (most of which are available on all three major operating systems), it may help some of you. Thanks to RootPrompt.org for the tip.

Making more sense with numbers, part 3

One of the early mantras one hears in statistics is "Plot the data." When I first heard it, it was followed by "by hand"; I suspect that part gets elided these days. Still, the advice is good. It's often easier to make sense of a list of numbers if you can visualize them.

Most of the time, that takes time we don't have. When we get an email or a report with a table of numbers, we know that plotting the numbers means grabbing a piece of graph paper (does your office supply cabinet even stock graph paper anymore?) or opening up your favorite spreadsheet, copying numbers, and drawing a graph. I rarely take the time.

Last week, I got yet another email with a table of numbers showing how something had changed over time. I was curious, so I wrote a short J script (now edited into a one line script) to turn the clipboard into data and another to plot the data.

Voilá! Now I had an easy and quick way to grab and plot data. I tried grabbing data out of an OpenOffice.org Writer document, and it worked, too. Grabbing data out of a Writer table was almost as good; my script lost the shape of the table, but that's easy to fix.

What's more, when you've got it in J, you can also apply various J statistical routines to the data, or you can pass it to R for more advanced statistical processing.

Yet another simple productivity tool, yet another reason to learn J as a tool for thinking and doing, yet another way to make sense with numbers.

I don't really care if you use J or some other tool; just pay appropriate attention to the data you handle. I just happen to think J is a powerful tool for this task (and for many other tasks). If you're learning J, check out the J lab called "An Introductory Course in J" by Henry Rich (thanks to Kip Murray of the University of Houston for pointing that out recently on the J Programming forum. Kip notes that Henry's lab covers a lot of territory very clearly but with a steep learning curve. If you are just seeing J for the first time, check out the J Primer.).

Interested readers might also be interested in tables2graphs.com and Using Graphs Instead of Tables.

So, if you have a table in email that looks like

Year Amount
2000 150
2001 200
2002 250
2003 225
2004 260
2005 254

and you'd like to graph it, one J program is

require 'format misc files plot'
sd=: > @: (". each ) @: |: @: clipunfmt @: wdclipread

Just copy the numbers, and type

plot ;/ sd''

to see your graph. I'll let you figure out how to add options and how to deal with multi-column data tables (it's easy).

Why is this part 3? Because there already has been a first and a second making sense with numbers, of course.

Which OS for your business?

CIO Magazine has been looking over the shoulder of CareGroup CIO John Halamka as he tests various operating systems for deployment in his organization. See the final series as he tests Ubuntu, along with his decision. It may not be what you think. (If you like this article, you might also like this.)

If you can say it, it's done

Even in this day and age, computing is a problem. How many of you us take the time to do some of the calculations mentioned here when faced with business or economic data, and how many of you us just read the analyst's summary and take the analyst's advice?

To some degree, that's because it takes time and effort to double-check such work, and that only gets worse if the subject is complex. It's also because the tools we have aren't always set up to help us do such things on the fly, and we're often on the fly (or in meetings, which can be as challenging).

That's one reason I've encouraged some of you who are interested to learn alternative approaches.

At least one APLer, Randy MacDonnell, has written about APL, "If you can say it, it's done." The same is true, of course, about J, its descendant. I had occasion recently to write a program to calculate whether a certain Monte Carlo simulation was done. I found a quotation by Andrew Gelman describing the Gelman - Rubin statistic:

For any given parameter, R-hat is the estimated posterior variance of the parameter, based on the mixture of all the simulated sequences, divided by the average of the variances within each sequence.

That looked easy enough, so I just wrote it down:

R=: var @: , % mean @: var

In English, that's "the variance of the entire set of data" (var @: ,)
"divided by" (%) "the mean of the variance of each data sequence" (mean @: var).

"If you can say it, it's done."

And you thought this was a blog about business, not programming, right? You were right. While J is a language that can be used by programmers, it's also a language that can be used by you and me to express quantitative ideas more powerfully and concisely than a spreadsheet. If you're ever interested in numerical answers from a spreadsheet, you could be interested in J. Perhaps, for some of you, it's worth downloading and trying out. Much as in learning a foreign (human) language, you won't be able to do much at first, but, eventually, you might be surprised what you can do. In a way, it's as much about thinking than about computing, and yet you can process some pretty large data sets with pretty concise "programs," too.

Thanks to Randy and Andrew for the quotations. For those of you interested in the Gelman-Rubin statistic, Andrew has pointed me to two papers giving more information: his Inference from Iterative Simulation Using Multiple Sequences with Donald Rubin and his General Methods for Monitoring Convergence of Iterative Simulations with Steve Brooks.

Better than a spreadsheet

So you're a manager, and you have numbers to calculate. How do you do that? Most likely, you fire up your favorite office suite and create a spreadsheet.

With the problems people have highlighted about spreadsheet usage, I find that I've been using a spreadsheet less and less. Most of the time that I open a spreadsheet these days, it's for a legacy application. I tend to use J.

I've written about J elsewhere. I was tempted to give a short introduction here, but I realized I'd be duplicating what others have said, and their attempts are, no doubt, better.

What prompted me to write this morning was my experience of yesterday. I needed to track some data, and so I set out to create a simple database. I have PostgreSQL available, but that seemed excessively powerful. I really should update my PostgreSQL installation, and I didn't want to take the time for that. I thought about Base; then I could pick whether I wanted to use PostgreSQL, its internal database, or something else.

When I realized that I'd likely want to analyze the data with J, I remembered that J has an SQLite addon, thanks to Oleg Kobchenko. I installed it (it's tiny), and I was up and running with a relational database in minutes. Now I just need to brush up on my SQL.

So, check out J. It's free, and it runs on most systems.

Installing Ubuntu

From time to time, I mention that some of you may find one of the Linux distributions a good operating system for your use. The prospect of installing a new operating system can seem daunting, though. RootPrompt.org points to Falko Timme's The Perfect Desktop - Ubuntu 7.04 Feisty Fawn, which walks through the process with plenty of screen shots. That should give you plenty of information, if you've been considering this move.

Creating text productively

Most of us spend a fair amount of time creating or dealing with text: email, reports, evaluations, proposals, and the like. Over the years, I've found one tool that consistently has helped me to be more productive at generating text in any format: Emacs (check out their quick guided tour—I learned something new there). It may look like an editor for software engineers, but it's really much more general than that.

I'm not interested in starting an "editor war" with those who prefer other editors (or word processors, for that matter), for it's to some degree a matter of personal fit. I did want to point out that IBM has a tutorial on learning Emacs, for those starting out. So does Emacs, for that matter (it starts automatically the first time you run Emacs); the IBM version has the potential advantage that you can read through it before you install the software, although you will learn more by actually using it.

For those of you who would like to walk through the IBM tutorial (it requires free registration), check out these, or search on their site for more specialized material:

1. Living in Emacs
   
2. Learn the basics of Emacs
   
3. Learn the essential modes and editing features of Emacs
   
4. Advanced Emacs text operations
   

Emacs does run on pretty much any computer platform you might have.

For those of you saying, "But I want nicely formatted documents, not pure text," see Business writing made easier. And for any of you really into text, check out Antiword as a tool to convert a Word document back into text. It's usually faster to open a document in Antiword than in Word.

Making the move to open source software (don't forget to FLOSS!)

As frequent readers may have detected, I make use of a fair amount of open source software (also called Free/Libre/Open Source Software or FLOSS) in my work. Sure, it's less expensive, but I tend to do it because of other advantages it provides.

You might get the impression that I think switching to open source (or, for that matter, switching to any new software) is easy, and you might be concerned that it's harder than I let on.

You'd be right to be concerned. Solveig Haugland has just published a good article called A very important post for decision-makers considering OpenOffice.org. Read it if you're even considering moving your company to a new system. (If you're only moving yourself, it's a lot easier; you become both the pilot test and the implementation, and you can control the speed and extent of your transition.)

If you'd like to dig more deeply into the economic impacts of FLOSS, you might be interested in Study on the: Economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU, prepared for the European Commission's ICT Task-Force. The final report was published November 20, 2006. I can't get that report to load successfully this morning, but a September 26, 2006 draft of the executive summary does work.

I've not read the entire 287 pages, but I have read the executive summary. I'd like to highlight one point on page 12 of the report:

Avoid lifelong vendor lock-in in educational systems by teaching students skills, not specific applications...

Whether you're a fan of open source software or not, I think that's incredibly important advice. Some software, some products, some processes, and some technologies have incredibly long lives (I'm using an editor that traces its heritage back to the 1970s), but others come and go. It's much better when we, our employees, and our new hires understand general principles and then can apply those principles in specific cases than when we only understand specific cases and have to start all over when we face a new specific case. Think about that as you hire, as you train people, as you learn yourself, and as you consider what gets taught in the educational system where you live.

Ethics

We all bear responsibility for our own ethical behavior. Period.

That said, when we are in positions to direct others' behavior and when our actions can be shown to lead to less ethical behavior, we have a signal to act. I've written before about the challenges long hours at work can make and about the benefits of having a few lazy employees. Professor Sandy Piderit has written about it.

Now Deloitte & Touche USA LLP has published Deloitte & Touche USA LLP Survey Finds Strong Relationship Between Work-Life Balance and Ethical Behavior.

Is it as simple as having everyone in your company work 40 or perhaps 37 or 35 hours a week? No, it's clearly not that simple. Customers deserve the goods and services they paid for. Employees and the community need jobs, and we can't provide secure jobs if we sacrifice all our productivity gains and more to shorter hours. Unforeseen, short-term crises do arise. Besides, the length of the workweek clearly isn't the only factor affecting ethics in the workplace. As I said before, that's ultimately up to each of us.

But it does mean that there's yet another factor to put on the side of the scale that weighs against longer hours. It does mean that decisions aren't as simple as the calculation that "if 40 hours a week are good, then 80 must be twice as good." We as managers and consultants do bear responsibility for thinking about such things and for balanced decisions that take these factors responsibly into account.

Part of thinking responsibly is thinking skeptically, so I encourage you to provide any disconfirming evidence you might have. I'm not looking for anecdotes ("Sam only worked 30 hours a week, yet he stole more paperclips last year than you could believe!"), for I'm sure they exist. I'm looking for valid studies and good, statistical reasoning.

Thanks to Chief Learning Officer magazine for pointing this out.

Improving Firefox OS

I just discovered Fullerscreen today, which would seem to work especially nicely for those trying Firefox OS.

It doesn't come with much documentation. Look in the status bar at the bottom of your browser window to see the new Full Screen options icon. Use F11 to toggle between normal and full-screen mode. Move your mouse to the top of the screen to reactivate tabs temporarily to select another tab, or use Ctrl-tab to select the next tab in order.

Could your hard drive be obsolete?

Firefox OS: Why My Hard Drive & Software are Obsolete.

I'm not there—I do too much in Emacs—but I see his point.

Be careful out there

See Alert: Critical Windows Attack Underway and Virus Disguised as IE 7 Download.

Assuming you have the option, this sounds like a very good time to use a browser other than IE, to read emails in plain text instead of HTML, to avoid clicking on links you aren't sure of, and to be generally careful. Currently just over 50% of you who visit Facilitated Systems use IE.

By the way, when I send long URLs by email, I sometimes use TinyURL.com to shorten the link. I always use the Preview Feature in creating those links so you can see where you're going before you go there. In case you get a link where that's not enabled, you can apparently set it for your computer, too.

Inverted KM

I'm certainly no knowledge-management (KM) expert, but I had occasion to recall Connex, an old Hewlett-Packard KM system today. As I understand KM systems, they generally attempt to capture isolated organizational knowledge and make it more broadly available throughout the organization.

Connex worked the other way. Instead of capturing knowledge, it captured information about experts. If you needed information about subjects X and subject Y, and you had reason to need it from someone who spoke German, you could query Connex and find the name and contact information of any experts who fit that profile.

That seemed easier for the experts, for they didn't have to take the time to write up their expertise without knowing whether it would ever be used. They didn't have to work to make their tacit knowledge explicit, either.

It seemed advantageous for the people needing knowledge, too, for, instead of getting a canned response that might not precisely fit their situation, they'd be able to discuss the matter with the expert and, hopefully, tailor a solution to their particular problem.

What I found really attractive was the social dynamic upon which it was founded. In a KM system, experts might feel as if they were passing along to others what made them unique and valuable. Instead, by listing their profiles with Connex, they enhanced their reputations while benefiting others in the company.

With a bit of searching, I discovered that Connex is not necessarily unique; Motorola has its Compass program, and IBM has its Blue Pages Plus.

You are even less alone ...

... if you're thinking of storing all of your office files in ODF. Now Texas and Minnesota seem to be moving in that direction.

Whether you like OpenOffice.org, Microsoft Office, KOffice, or something else, I think it's very much a positive step to adopt a standard format such as ODF.

Is ODF perfect? No, it seems not. For example, I can't see any reason to abandon the TeX format for typeseting mathematical formulæ. Then again, if I'm typesetting a document, I'll likely use LaTeX. With the prevalence of files created with office suites, I still think it's important to start with a standard file format and then help it evolve and improve.

While such a format could be led by a company, I've seen "standards" in the past. Think of Pascal, if you programmed computers in the 1980s, in which many companies made incompatible extensions to try to lock people in to their versions. Sure, you could program in Standard Pascal, but they hoped you'd make use of their attractive, special features and then become locked into their platforms.

Let's have a standard, open, and publicly-agreed-upon file format that vendors really stick with, and let the competition reign in software to produce and read those files. We'll all win.

A commuting fantasy

Yesterday, I had occasion to drive to the airport and back. That's at least a 40-mile trip each way. With local traffic, the trip can take quite a while, no matter what time of day (except, perhaps, around 3-4 in the morning).

Two nights ago, though, we had a snowstorm that wreaked havoc with the evening commute, and we were being told yesterday that we should stay home unless we had to venture out. People seemed to listen, traffic was light, and driving to the airport, even with occasional slick spots in the roadway, was a dream. It was if we had turned the clock back 20 years as far as traffic goes.

As someone who does most of his work remotely, using phone, email, Web conferencing, and the like, I had a fantasy. What if people really didn't need to drive to work each and every day? What if we could keep the roads available for the times we really need them? We wouldn't have to spend as much on roads. Companies wouldn't have to spend as much on office buildings. We wouldn't have to spend as much on fuel. We wouldn't have to spend as much on cars. We wouldn't emit as much in the way of greenhouse gases. When we did drive, we'd have a more pleasant experience. When we didn't drive, we'd have more time for family, friends, and leisure. We'd injure or kill fewer people on the roads.

Could we do it? Really?

You are not alone ...

... if you're thinking of switching to GNU/Linux.

Top postings of 2006

Here are the top ten postings on Making Sense With Facilitated Systems for 2006. Technically, this is a bit premature, for the data was captured on December 27, but I don't think things will change much.

Admittedly, there is a statistical problem with this list. Entries made last January have had more time to be viewed than entries made late in December. As I suspect most entries get their heaviest readership shortly after they're posted, I'm ignoring that potential problem and simply ranking postings by the total number of entries received from January 1, 2006 through December 27, 2006. Besides, the most popular item is also one of the most recent.

10. Last year, I had several postings on the use of systems thinking approaches, especially system dynamics, in program evaluation. System dynamics and program theory (evaluation) was number 10 on the list of most popular postings for the year.
    
    
9. Work is changing, and, for many of us, our work locations and time are becoming more flexible. Number 9 on the list of most favorite postings for 2006 was ROWE: Revolution IN work, a description of Best Buy's changed work environment.
   
   
8. People in mature organizations often wish their employees were more entrepreneurial. Number 8 on the list is Becoming more entrepreneurial, which sheds light on what Saras Sarasvathy and others call effectual reasoning. That's the style she finds most prevalent in entrepreneurs. Are you ready for that approach?
   
   
7. I am a fan and user of open source software, as I've explained multiple times. Number 7 on the list is OO.o tips, intended to help those thinking of switching to OpenOffice.org as their office suite.
   
   The next highest essay on the list, The Joy of Thinking Small, was published in November of 2005, and so it doesn't deserve a place on the top ten list for 2006. I'm mentioning it because it did earn the spot through popularity, and it might give you a pointer to some small tool you can use to make youself more productive.
   
   
6. Number 6 on the list concerned growth, another topic I've covered several times. S-curves, growth, and discerning your position was written to help us all think about whether growth was a good goal for our organizations at this point.
   
   
5. Decisions, decisions, decisions, one of several notes comparing Gary Klein's recognition-primed decision model with other approaches, was number 5 on the list. This essay also touched on Saaty's Analytic Hierarchy Process.
   
   
4. Introducing Systems Thinking into Your Organization, number 4 on the list, announced the temporarily free availability of an article by that name that I wrote for Pegasus Communications' Systems Thinker. The article is still good, and it's still available for a small fee from Pegasus Communications.
   
   
3. Number 3 on the list was Thinking systemically: Limits to Growth, my favorable review of Limits to Growth: The 30-Year Update. I found it to be both a good treatise on the subject of growth and a good, non-technical introduction to system dynamics.
   
   
2. Growth also occuppied the number 2 spot with More on growth, perhaps my most reflective essay on the subject in 2006.
   
   
1. By far, the most popular essay for 2006 was the recent Making sense with numbers. It used an example from the business of classical music to show how an esoteric-sounding concept called Bayes' Rule could help us make better sense of the statistics we may hear in meetings or read in reports. Its popularity was no doubt aided by those of you who blogged about it yourselves. Thanks!
   
   

While all of these essays describe ways of making sense of the world, I see four categories as being important to you.

First, four of those entries, numbers 1, 4, 5, and 10, are about making sense of general situations. That's the theme of this blog and the central theme of my work.

Second, the environment and organization's responses are key in numbers 2, 3, and 6. While I suspect not many companies are yet modulating their growth in response to the environment, many of you seem to be thinking about it. I was fortunate to have been able to work in the environmental arena last year, and I enjoyed it immensely.

Third, number 7 and its 2005 partner showcase ways to do things more productively. As I hope that's one of the benefits people get from my work, I'm glad it came out in my essays.

Fourth, numbers 8 and 9 speak to the ways we work in organizations. As I focus on helping people through helping the organizations in which we work, I'm glad that came through, too.

By contrast, which essay was the least popular? That turns out to have been A wake-up call with positive ideas, an essay about Clyde Prestowitz' Three Billion New Capitalists: The Great Shift of Wealth and Power to the East, one of several essays I've written about what I see as the importance of those of us in the U.S.A. connecting better with those of us who live in other parts of the world.



What's the map, you ask? That's where you live—you who voted on these essays by viewing them during the course of the year.

Thank you for reading these essays and for the comments you've made. I'll try to focus even more on issues you care about in 2007, and I'll try to throw in a few new areas, too, just to keep things interesting.

I welcome comments from even more of you in the coming year. Email me, call me, or add a comment to a blog entry. I'd especially appreciate your feedback on what you found helpful in 2006 and what you'd like to see me cover more thoroughly in 2007.

Take back your time

In my first job, which happened to be as an engineer in a different country, I was limited by labor contracts to working no more than 96 hours in any two-week period. In my second job, in the USA, I put in more than 96 hours in many individual weeks (their standard work week was 45 hours, not 40).

While I like work, and while I really like making a contribution, life was certainly more enjoyable in the first environment than in the second. I had the time to enjoy hobbies, to be around people, and to experience new places when I was working 40 hours a week (we rarely worked overtime). When I was working 90+ hours a week, I rarely had time for any of that.

At my third job, I returned to an environment, still in the USA, in which I normally worked 40-45 hours a week. I found that I and my colleagues worked very intensely while at work, and then we had time we could call our own. I felt like a human being who worked again, rather than a worker who didn't do anything else. This, like my first job, was certainly more enjoyable than working very long hours.

But it's fair to ask: were the long hours better for the company? After all, if I turned out over twice the work in 90 hours when compared to 40 hours, perhaps that was good for the company directly and, indirectly, for society? If that were true, they would have gotten over twice the contribution out of the same number of people. Perhaps my enjoyment of a 40-hour week was a sign of laziness.

I don't think so. I noticed that, when I was working a "regular" work week, I'd work hard during the day. Then, in the evening, I would enjoy doing whatever I enjoyed doing. After being away from work for a while, I might think of an idea that would help me with a problem at work. I'd typically take 5-10 minutes to write that down, saving me perhaps an hour or two the next day had I attacked the work without benefit of those insights.

When I was working 90+ hours a week, I'd occasionally have similar ideas while at home. In those situations, I found that I'd rarely take the time to record my ideas; my time to be with family, to take care of basic chores, and even to sleep was already so limited I didn't want to give up another 5 minutes.

More than that, I sensed that my overall weekly or monthly contribution peaked at some hourly workweek far closer to 40 hours than 90.

All in all, I think the companies that had me work a hard 40 hours a week on the right things got more real contribution from me than the company that had me work 90+ hour, not because I was slacking off, but because it's very hard to maintain a creative, innovative focus on the right things when there's no time to recharge one's batteries, when there's no time to take care of onesself.

Some time ago, organizational behavior professor Sandy Piderit wrote about just this issue.

More recently, Kathy Sierra blogged about Twitter, one final tool to add to our mental overload.

I'm not about to condemn Twitter or to rail against companies that have long work weeks.

I am going to suggest that, if you're a manager in a company that encourages or demands your people work long hours on a regular basis, think seriously about that practice. It may serve you in the short term, but does it lead to unsustainable results and an eventual crash? With innovation being the current hot topic, do you get less innovation by pushing people harder? Is it good for society?

I will also suggest that, if you're a person who gets stuck working long hours on a regular basis (perhaps driven by others, perhaps driven by your own decisions), think seriously about whether you want to continue that practice. It's easy to get into an hours-based competition, where you work longer than the next person in the hopes that your work will be rewarded by more salary. Unfortunately, it's like an arms race or a price war: the other person can respond in kind, leading you to respond by working still more hours, ultimately limited only by the number of hours you have to sleep and the 168 hours in a week.

There is a systems component to this posting. Back in 1995, Jack Homer published an article on worker burnout, focused on his personal experiences. You can find the reference listed in Desert Island Dynamics: An Annotated Survey of the Essential System Dynamics Literature, and you can find a model listing on Tom Fiddaman's site.

Free software

Recently I presented a talk called System Dynamics for Cheapskates. In keeping with the theme of the talk, I mentioned OpenOffice.org as a way to generate reports. I acknowledged that one could do this with Microsoft Office, too, but I personally found OO.o better. I was pleasantly surprised to find at least one woman in the audience giving me an enthusiastic thumbs-up.

At meals, I found myself in enthusiastic conversations with others who were telling me how they've found OpenOffice.org and other free or open source software to be better than the commercial software they or their organizations had been using.

The conclusions don't seem strange; I might have expected that from people focused on technology, and they match much of my experience. What surprised me and pointed out my naiveté was seeing that excitement about free and open source software from a group of people focused simply on using software to be effective in their regular work.

I was reminded of this today by seeing Solveig Haugland's posting on Vista and Office 2007.

By the way, for those of you not sure where to find good open source software, check out Ubuntu, SourceForge.net and the GNU project for starters.

An Open Source potpourri

Start with Solveig Haugland's article Spending Your Money on Something Important.

If you've just switched to Linux, check out 10 Things a new Linux user needs to unlearn. If you haven't switched yet, you may want to, once you read this and a few other articles.

If you chose Ubuntu as your Linux distribution, check out Ten tips for new Ubuntu users.

A practical, quick guide to email security

I've written about email security in the past. Thanks to RootPrompt.org, I discovered a short introduction to configuring such a system in Free Software Magazine. While it's focused on Ubuntu, the same tools work on Windows.

An office suite experiment

From a posting I never posted: "I've pointed out the utility of a variety of tools to meet various needs. Yesterday I wrote about the release of OpenOffice.org 2.0. Last night, I decided to try an experiment: I'll try to use OO.o for the next month in my work instead of MS Office, just to see if I encounter any reliability problems. I'll let you know what I discover."

That was last October. It's now June, and I've increasingly used OpenOffice.org instead of MS Office 2000. Here's a bit of what I learned:

• I like Writer better than Word. While I haven't exercised Writer as much as I've exercised Word, I have yet to hear of or experience "spaghetti numbering" in Writer, and I've experienced it multiple times in Word 2000. I mostly value that I seem to find it easier to use styles in Writer, and I also like that I can create PDFs quickly and easily.
  
• I like Word's reviewing tools quite a lot. If I'm working on a document with another person (an editor or collaborator), they can make life much easier. I'd get many of the same features if they used LaTeX and latexdiff or DocBook and diff, but I've found fewer editors and collaborators who use those tools.
  
• I slightly prefer the user interface for Excel to that for Calc, but I'm getting used to Calc. I've got one or two Excel spreadsheets that seem to take a long time to save in Calc. I've heard good things about Gnumeric, but I have yet to try it. I am concerned about reports on Excel accuracy.
  
• I like the Impress and PowerPoint user interfaces about equally. I like it that I can easily save Impress presentations as PDFs or SWFs.
  
• I certainly like Draw better than not having any vector graphics program in MS Office.
  
• I like Base better than Access. For one, I can connect easily to a variety of databases, including industrial-strength tools such as PostgreSQL.
  
• I like that OO.o stores data in a standard, open format.
  

There have been a few downsides. Besides having the one or two aforementioned large spreadsheets that should have been databases and that seemingly took longer to save than I expected, I have seen a few complex Word documents that didn't open well in Writer. The information was all there, but the formatting of certain parts was ugly.

What would I recommend to others today, if anyone asked?

• Use MS Office if you need 100% compatibility with other MS Office users.
  
• Use a tool that supports OpenDocument if you want your files to be usable in the future.
  
• If creating office documents is not the fundamental contribution of your work, try OO.o. If you do:
  
  
  
  • Use styles (that's good advice in Writer and in Word).
    
  • Use templates.
    
  • Use PDF to publish documents. That's not because native formats aren't good ones; it's because PDF is intended as the portable publication format. For example, if you create a Word document and email it to me, what I see will almost certainly be different than what you created, for it lays out pages in a manner that's dependent upon the printer selected for each person's computer. A PDF is a PDF is a PDF.
    
  • Subscribe to a blog such as Solveig Haugland's OpenOffice.org Training, Tips, and Ideas to get daily tips on getting better at what you do.
    
  
  
• If creating office documents is important enough to your work, and if you have the time to learn them, consider special-purpose tools:
  
  
  
  • I use LaTeX, DocBook, and asciidoc more often than Writer or Word for creating formatted text documents.
    
  • I use J at least as much as I use a spreadsheet for working with arrays of data.
    
  • Given the choice in face-to-face work, I often eschew projected slides of any sort. If I need slides, I like beamer for the ease with which it puts useful information on a screen nicely.
    
  
  

I find I use a blend of all these approaches. For example, I tend to do formal documents (major reports, proposals, and invoices) using LaTeX, I do a number of recurring short reports using asciidoc, I document processes either in DocBook or on a Wiki, I use plain text for most text communications, and I use Writer for (mostly) informal reports that include text and graphics.

What's your experience?

PS: I know most of you will (or have to) stay with Word, at least for now. In that case, save yourself a bit of grief, and check out a few handy references. First, the Word MVP site is full of valuable information. Second, Shauna Kelly has a very handy site. For starters, read how you shouldn't format numbered lists in Word (but you probably do; that toolbar button is way too inviting).

OO.o tips

I've suggested OpenOffice.org as a good office suite. If you've installed it but want a bit of help getting started, check out Solveig Haugland's "OpenOffice.org Essentials."

OpenOffice.org revisited

Some time ago, I claimed that I liked OpenOffice.org but found it a bit too memory intensive. I keep getting drawn back to the tool for the features I like, and I've noticed something: it's not nearly as memory intensive as I had first thought. Where I get in the most trouble is by having Firefox open with a gazillion tabs; Emacs with a gazillion windows (not the same thing as a window in Windows or the X Window System) can take up much memory, too. OO.o has generally been down further on the list of memory use, according to Task Manager. Incidentally, I suspect opening a gazillion Internet Explorer windows would create the same sort of computer memory challenges, but I'd lose the ability to comprehend my desktop long before I got that far.

For the past month or so, I've used both Emacs and OO.o and been more careful to stop creating new Firefox tabs at around half a gazillion, and things have worked fine. When Firefox gets too big and I'm through with it for a while, I just close it. I can restart it quickly, and its history list lets me find places I recently visited, if I need to.

Email security made simpler

I've written about email security occasionally, but I realize that it might be intimidating to think about finding, installing, and learning to use the various pieces. It's not really that hard; if you use Thunderbird, you only need to install Enigmail and then follow their instructions.

Now there's also gpg4win, a package designed to make life simpler for you, if you're a Windows user who is just getting started. While I haven't tried it, all the material I've seen makes it look like one-stop shopping (almost) for getting encryption and email signing running on your computer.

There are two pieces that may be missing (you can check out the manual after you download it): setting a passphrase and using the Web of Trust. Check out Diceware for creating a secure passphrase, and check out the GNU Privacy Handbook for information on the web of trust. Being a responsible member of a web of trust means you don't sign another person's public key to indicate it's valid unless you really have identified who that person is. If you haven't known them for a long time, you ideally verify their identity with two physical pieces of identification—a passport, driver's license, or the like.

You can browse a few links I've found helpful, too.

Now give it a try! If you want, use my public key to send me an encrypted email as a demonstration that you can do it!

Tool training and a few tips

How did you learn how to use the word processor and spreadsheet you use? If you're like most people I know, you type many of your own documents yourself, and you create many of your own spreadsheets. Did you take a class? Did your company give you a book about the software when they gave you the computer to use (and did you study it)?

I'm guessing that most of you, just like I, didn't get a class to accompany most of the software you use. That's a bit of a shame, for there are ways to be more productive that don't take much effort. Take word processing, for example. I seem to recall reading estimates that the overwhelming percentage (>90%?) of Word users use "direct formatting" to format a document. That is, they click on the "bold" button to make text bold, they click on the "list" button to create a list, and so forth. While that often works, it can lead you into real trouble, and it takes longer when you have to make changes (even in short, one- or two-page documents).

There is a better way, and it has to do with using styles. For some reason, I've always found Word styles and templates a bit harder to use that direct formatting, and I've found OpenOffice.org's approach much more intuitive. If you want a quick introduction, see Solveig Haugland's All About Styles in OpenOffice.org Writer and Templates: Making Them, and Making New Documents Based on Them (Writer, Calc and Impress); she makes it seem easy.

For those of you who make documents other ways and use Emacs as your text editor, check out Emacs' templates. I've been using templates mode and finding it saves me time and makes my work more consistent in appearance.

productivity
word processing
writing

More on spreadsheets

I've written about the risks of spreadsheets before, but Friday's comp.risks brings news of a different sort of problem caused by spreadsheets with a DWIM mentality.

The moral of the story is the old, familiar one: pick the right tool, which is not necessarily the easy tool, for the job.

spreadsheets
software quality
business risk

A quick Web publishing tip

If you're a full-fledged Web developer, you no doubt already have effective ways of publishing stuff to the Web. If that's not your job, but you need to publish information for people as part of getting your real work done, take a look at Solveig Haugland's tips about the OpenOffice.org 2.0 Web Wizard.

I tried it three times. After I caught on that I can (and have to) set the way I want to publish each file I select, I produced a professional set of PDFs from a set of Word documents in short order. I can see this as a tool I can use with clients to save serious time, for they're paying me to get results, not be a publisher, but I do occasionally need to get information out rapidly and in a consistent, easy-to-use format.

OpenOffice.org
Web publishing

When easier is harder

Sometimes easier isn't easier than harder is.

Okay, that sentence is a mess. What I mean is that the easy way out sometimes makes problems for us, and those problems end up making things harder for us overall. Over time, I've decided I'd rather have a small amount of predictable challenge in getting something done than a very easy task with random, unpredictable problems that require much rework. It's easier to meet commitments in the former case, and that's important to clients.

Some time ago, I wrote about the dangers of using spreadsheets and some alternatives. Today, I saw a pointer in comp.risks to a list of problems caused by spreadsheet errors that have made the news. Take a look, and see if you're doing anything in your business that resembles these news stories.

I still think spreadsheets can be handy for quick, simple things, but I increasingly suspect we're often better served by a real program done using real design methods for anything more complex or business critical. It's not that you cannot do a good spreadsheet (although I think the medium makes it challenging); I think it's that we usually take the perceived ease as a cue not to do them the right way.

spreadsheets
software quality
business risk

OpenOffice.org tips

If you're considering using OpenOffice.org, check out Solveig Haugland's blog for frequent, useful tips.

Not long ago, I posted that OpenOffice.org 2.0 seemed to take lots of memory, and that was a problem for me. It still seems to, but I discovered something this week when I had to do a couple of different short, one-page custom documents: OpenOffice.org's Write can still be worth it. Compared to LaTeX for short, one-off documents with custom requirements, Write is quick. Compared to Word (or at least my skill with Word), Write seemed easier for working with styles. That was a big deal: I could enter the information, quickly assign custom styles to certain types of information, and then begin to format the styles to communicate the way I wanted.

So what about the memory issue? It's still there—I wish I had more memory or a less expansive Write (perhaps it's different on Linux)—but I discovered that I only really got in trouble when I had lots of OpenOffice.org windows open. Being a bit careful about what I kept open made things go pretty smoothly.

OpenOffice.org

Thinking about Linux?

If you've thought about trying Linux but figured it would take you a lot of time and effort, check out Live CDs such as Knoppix (for Intel/AMD hardware). Download and burn (or buy) a CD, boot from it, and experience Linux within minutes without erasing your current operating system or data.

If you want to install Linux on a machine, wiping out what was there before, Steven J. Vaughan-Nichols has a nifty intro to various Linuxes for the desktop. I've used Debian and Ubuntu, and I can't disagree with what he's said.

Thanks to RootPrompt.org for the lead!

linux

Math in the service of insight and results

CBS has a TV show called Numb3rs that "depicts how the confluence of police work and mathematics provides unexpected revelations and answers to the most perplexing criminal questions."

W. Edwards Deming and others used simple statistics to help companies improve product and process quality.

Virginia Postrel posted about the power of Bayesian statistics in getting drug test results more rapidly.

I and others have written about system dynamics, control theory applied to human, organizational, or ecological systems, as a way to make sense of and deal with those situations in which long time delays and the feedback of information play a strong role in determining outcomes.

Why is this important to mention? In today's fast-paced world, I think we often feel compelled to take the most direct approach to solving problems and making decisions: we use the experience we have already to make the decision that seems right, and we move on.

Sometimes that works well, but sometimes the result takes too long or the problem itself seems not to make sense. In those cases, check out the mathematical approaches! Perhaps there's a way to use the leverage of math to give you a better and easier answer than you might have gotten other ways.

business
Bayesian statistics
ecology
mathematics
statistics
system dynamics

Spreadsheets: dangerous to your organization?

Most of us use spreadsheets regularly. Indeed, starting with Visicalc, spreadsheets have been a major convenience factor for personal computers of all sorts, enabling non-programmers (or programmers who want an easier way) to make valuable calculations.

For some time, I've been worried about spreadsheets. For example, I've noted that it's far too easy to enter a value in a cell, overwriting a formula, and then forgetting to set it back to the formula. I've seen such errors get discovered weeks or months later when, for example, faulty but hoped-for financial projections in a spreadsheet don't come true.

Comp.risks posted potentially valuable links to sites that discuss errors in spreadsheets, and their work seems to validate my suspicions. Hardwiring, that overwriting of a formula by a constant, is "very common," although its incidence can be eliminated by protecting all cells with formulas. (No, I don't always do that, either.)

If you're so inclined, check out the research, and consider how you can insure the spreadsheets in your organization won't lead you astray. Consider best practices they suggest.

For even better security, I might suggest beginning to move to an array programming language, in which the calculations and the data are clearly separate and can be examined separately and easily. J is one such language; its tacit expressions can provide an easy path to a personal, custom calculator that can provide you the data you want and that is quite insusceptible to hardwiring errors. Check out Easy J for a quick introduction.

spreadsheets
software quality
j language
business risk
array programming language

A new office productivity tool: update

Not long ago, I hailed the release of OpenOffice.org 2.0, and I still think it looks to be a great tool.

However, I've been using it more extensively this month as an experiment, and I think I've noticed my computer running more slowly. When I did a bit of checking, I noticed I was using more memory than I had in physical RAM, thus requiring more use of disk.

Admittedly, I come from an X Window System on *nix background, where I didn't find it unusual to have 15-20 windows open at once (much to the dismay of the friendly Windows IT support people at my last company). I looked for what had changed recently, and I could only find OO.o.

A bit of Googling turned up a blog by George Ou indicating that I might have discovered the problem.

I still hope OO.o promises good things for the future. I do want anyone who reads this blog to know all the data I think pertinent (and perhaps, on occasion, some I'm not so sure about), even if they go against a position I've taken. I think that's part of the ethics of writing or speaking.

I suspect OO.o will get better and faster, but I don't know that. I hope OO.o Writer will continue to stress some of the contributions it makes: more emphasis on structured text (e.g., the OO.o 1.x Stylist) rather than direct formatting of text, seemingly fewer problems with list numbering and master documents, and easier generation of PDF files.

MS Office is still an alternative, of course. For people searching for spreadsheets other than Excel, I've heard good things about Gnumeric, although I've never used it. Those looking for a faster, cross-platform, and free word processor may want to investigate AbiWord (another program I've heard about but not used).

Until this gets resolved, I'll likely still use OO.o for some things. I'll also go back to my standbyes: LaTeX, DocBook, and related tools for all things textual (including presentations), J for calculations, and likely Excel for most spreadsheet work. All of those (except Excel) offer native storage of the work in readable text files, are excellent at what they do, and tend to be fast.

A new office productivity tool

OpenOffice.org 2.0 was just released. If you've heard of OpenOffice.org but haven't tried it yet, this may be a good time to check it out.

If you do, here are a few things you might want to check out; you'll probably find a number of others.

• It's quite easy to turn any of your documents into PDF.
  
• Draw is an easy way to do vector drawings, giving you nicer results and presumably smaller files than Paint.
  
• Look for the Styles and Formatting button. Discover how much easier it can be to create structured text documents than it is to use so-called "direct formatting."
  
• Check out the new and flexible database functionality in Base.
  

I've used PostgreSQL to track data for some projects. While it's industrial-strength, it lacked a bit of friendliness for creating queries and reports for the casual user. Last night, I opened Base and tried to connect to my last PostgreSQL database. Within a very few minutes, I had connected and was creating new queries. I then opened a Calc spreadsheet I had defined as a data source and was able to generate reports, again quite quickly and easily. This may be the biggest benefit for me in OpenOffice.org 2.0.

Business writing made easier

Some time ago, I blogged about productive ways to write. Some of those ideas were more suited to longer documents, where the overhead of learning something new can be amortized across many pages of text.

Often, though, I simply have to write a neat, understandable report for a client. If it has to look quite professional (and especially if it's to be printed), I still favor LaTeX as the best and easiest way to go. If it will have to be "repurposed" frequently for different needs or clients, DocBook has key strengths.

Often, though, I want something quicker and simpler. I once suggested parsewiki as a good tool, and it is, but I've since changed to a new, more powerful tool called asciidoc.

I've found I can write lightly formatted plain text using anything from Notepad to Emacs (my preference), and that text is easy to read. The asciidoc program can convert it, perhaps with the help of a few other tools, to varying XHTML formats, PDF, Windows or Java Help, or other formats.

For my personal use, I've been creating nicely formatted XHTML files I can view in a browser; for a client, I've been using cygwin's DocBook tools to convert the asciidoc output to PDF (although it would be easier on my Linux system). You may well need cygwin's Python packages to run asciidoc, anyway. This tool makes the creation of professionally formatted documents easy and straightforward, especially once you've done (and documented the process for) your first document.

Is there still a role for parsewiki? I think so, even if I choose asciidoc. It has the advantage that it will generate a formatted file pretty much no matter what I throw at it, while asciidoc can do more of what DocBook does while refusing to create formatted output if it can't understand what I write. So far, that's not been much of a problem, for asciidoc is pretty easy to use. parsewiki is also a bit simpler, mostly because it's also a bit more limited in power.

Business Writing docbook

Getting neat or getting organized?

Over two decades ago, I knew of a plant manager who wanted to instill the virtue of neatness in his employees. Every morning before 8, he'd tour the office areas, looking for desks that weren't clean. Pity the poor person (engineer, usually) whose desk was found to contain stacks of paper; that person would be "written up."

One morning, he wrote up an engineer who had arrived even earlier to work on an important project and who had stepped away from his desk to work in the lab for a bit. That story made the rounds quickly. It didn't help morale to think that people with extra initiative were getting written up for having taken work out of their desk drawers before the traditional starting time for work.

Yesterday, I saw a description of an impressive, paper-based Kanban approach to work. I bookmarked the full description on Edward Tufte's site (scroll down a quarter of the page), intending to review it today.

When I went there today, I first saw Tufte's reference to Malcolm Gladwell's The Social Life of Paper. That reminded me of Bob Pease's approach to filing, of what I've called my occasional "archaeological" approach to filing, especially when I was an engineer ("If I did it last week, it must be about 2 inches down from the top of the pile"), and of the importance of being organized for effective work, not looking organized for others.

The moral of the story? If you're a manager with a strong passion for neatness, be neat yourself, but strongly consider encouraging your people to be effective, not neat, unless neatness happens to correspond to effectiveness for them, too. Perhaps a bit of action learning on their part can help them learn what helps them be effective. Perhaps it can help you learn what makes you more effective, too.

Personal analog devices

If you liked the Hipster PDA, check out the more detailed information on Ward's Wiki.

Personal knowledge management

I've long used one of the Emacs Wiki systems on my computer for personal knowledge management. It's all local and thus private, it's easy to edit, and it provides me hypertext I can view in Emacs or in my browser, making it easy to document business processes, good practices, or agreements I've reached with clients.

Recently one of my sons pointed me to TiddlyWiki, an innovative tool that just might wean me away from my current system. If you clicked on its link in the last sentence, you just downloaded the entire system. Just go to SaveChanges in that window to save it to your disk so you can customize it for your own use. It has a rather cool user interface, it seems well-written (only HTML, CSS, and Javascript), and it's versatile and cross-platform.

Why would you want this? Perhaps you can use it to help you organize your work processes to make you more productive; that's what personal knowledge management is all about. I've got Emacs Wiki pages set up for general business processes, business processes that are unique to specific clients, strategic planning, and various other projects. I'm curious to see if TiddlyWiki works as well if I put it to similar uses. Perhaps I'll try using it as a blog. Perhaps I'll try a WikiOnAStick.

Writing productively

Almost all of us write for a living: some of us spend some amount of time writing professionally, in that we write words for which others pay us, others of us manage people who write professionally, and all of us write to communicate with others, be it in the form of email, reports, or handwritten notes.

While the content (the words themselves) are most important, the way we put them down can affect how productive we are and how our words are read by others. Over the years, I've developed an assessment of which means work for which ends, and I thought I'd share some of these company secrets with those of you who may be looking for alternatives.

For me, the simplest and often the best is plain text. It transports well in email, and it serves admirably in many other situations. It's easily searched (think "grep") for ideas later. It's easily signed or encrypted. Files are small. The most productive way I've found to create text is GNU Emacs. Period (or full stop). With a few add-ins such as its table functionality (table.el), it's easy to create nicely formatted, lightweight documents people can make sense of easily. With a few more add-ins, you can do almost anything you want: read mail, create Web sites, make calculations, store data, and plot graphs.

Sometimes plain text won't do. It really is hard to do better than LaTeX for producing nice looking documents to be printed or to be viewed as a PDF file. I've found AUCTeX a great add-in to Emacs to make it easy to write LaTeX.

In an increasing number of cases, it's important to be able to use the same text for multiple applications: print and the Web (and even online help), customer A and customer B, etc. For books, articles, and especially for documentation for computer hardware and software, DocBook provides a good solution. Write the text once, and then process it differently for each. It makes filling in the appropriate customer name or including the appropriate sections for each customer (relatively) easy. Emacs, with its nxml-mode, is again my tool of choice for creating DocBook documents. Perhaps the biggest challenge is selecting a "toolchain" that produces the documents you want: producing HTML is almost trivial, while producing PDF can be harder. DocBook can even be suitable for really quick, short documents.

Maybe you want a GUI, so you don't have to remember as much about how to format things the way you want. I've found OpenOffice.org's Write to be handy. Most importantly, its styles features make it easy to create structured text that looks good and is easy to maintain. Starting with version 2.0 (coming soon, they say), OpenOffice.org will store documents in OASIS OpenDocument XML format, a vendor- and implementation-independent format.

These are simply my impressions, so "your mileage may vary." For more information about any of these approaches, see these links.

Personal productivity tip

We all have lots of ways to think about improving our productivity. I like the ideas I read at 43 Folders. I've gotten my first PDA from that site (free, for I had all the pieces lying around the office), and I've discovered do-it-yourself add-ons to make it more useful. From that site, I found a link to off-the-shelf (or -printer) add-ons.

What cool tools do you use to improve your personal productivity?

It figures

Every so often, we all need to make various exploratory calculations as part of running our businesses. Perhaps we need to estimate a preliminary budget, calculate the projected revenue from a program, or analyze results we've been given. Often these are relatively simple calculations that just happen to deal repetitively with arrays of numbers.

As most of you probably do, I sometimes turn to spreadsheets or a calculator for such calculations. I keep coming back to an old standby, though, that often makes my life easier and gets results faster: the free J.

Just this week, I had some numbers to explore, and I started in a spreadsheet. After a few iterations, I was beginning to get lost, even with comments on cells to help me recall my assumptions. One of the challenges was the inability to see the assumptions, calculations (equations), and results, all at the same time.

So I switched to J. I opened a script window and started typing. Assumptions went into comments. Calculations went into simple equations. Constants went into even simpler equations. Every so often, I'd save and run the script to see the output. When I didn't get what I expected, I'd enter the name of a variable in the execution window and use the intermediate result to help understand what was happening.

Within a relatively short time, I had the result I needed, and I also had a file that documented my assumptions and process.

Nice.

Meeting better, asynchronously

If you attend meetings at work, try an experiment over the next work week. Log how much time is given over to the discussion of scheduling the next meeting ("Can we meet Tuesday at 10?" "No, I've got a staff meeting then. What about 11:30?" "No, I've got a lunch meeting with a customer. What about Wednesday?"). Also, log what delay, if any, occurs between when you'd naturally like to hold the meeting (say, Tuesday morning at 10) and when it actually occurs (say, Wednesday afternoon at 3). Divide the first number by the total length of the meeting to get the fraction of meeting time spent on meeting scheduling. Sum the total delay for all meetings and divide by the number of meetings to get the average delay per meeting.

I find it interesting that most business people I encounter aren't familiar with the concept of asynchronous meetings. We're used to synchronous meetings, in which we're all in the same conference room or on the same phone bridge. We're used to email, but many seem to think of that as work we do between meetings.

I think we're missing out on a great productivity enhancer when we ignore asynchronous meetings, and I think the time spent doing scheduling is just part of the problem. I've outlined a few more ideas in Online Facilitation for Inperson Facilitators, and I've put together a little matrix to help differentiate types of meetings and when you might choose which. You can find a wealth of additional information at my friend and colleague Nancy White's site (check out her blog, too). If you try moving some of your meetings to an asynchronous mode, I encourage you to plan the meeting thoughtfully. All meetings could benefit from thoughtful planning (and, judging by what people often say about meetings, they don't always receive such planning attention), but asynchronous meetings, because they're not familiar to most of us, especially benefit from careful planning and facilitation.

Oh, if you do the experiment and are willing to share, post a response to this note next week with your results. If you'd prefer not to publish your name and company, just email me the numbers, let me know you'd like me not to publish your name or company, and I'll simply publish the statistics. Thanks!

A blast from the past

Joe Podolsky was one of the early online essayists. From 1994 through 2000 (and perhaps beyond), he wrote Joe's Jottings, an email journal. Joe always seemed to be a serious, interesting, and insightful thinker. While I haven't reviewed all of his Jottings today, I've probably read them all at some time. I encourage you to peruse a few and see what you think.

The "blast from the past" label comes from seeing a few of my decade-old replies to his essays. I sometimes make the point to people that some of the interventions I and others try with organizations to help them improve interpersonal communications don't quite have the flavor of "soft skills," nor do they seem "touchy-feely." One of my responses from 1996 tries to point that out. As much as that effort was about communications, it was also about the tough aspects of communicating effectively when there's disagreement and even conflict, and it was very much about how to achieve the organization's goals.

We succeeded, by the way, in that we reduced process cycle time by 83%, as promised. We also succeeded in that we helped make that organization a much more rewarding place in which to work, again, as promised. To a significant degree, it became a more rewarding place to work because people knew they would be heard and because they knew they owned the work and its results (the closer we got to the end, the more they were willing to remind me of that in an energetic fashion!). While it sounds suspect for the change initiator (me) to be making those claims, I think those in the group would say the same thing.

New tools for writing

From time to time, I hear of people seeking easy ways to publish documents in PDF format. Sure, many still use Word and send their documents along as .doc files, but there's a perception of being complete that comes with PDF files, and PDF files look the same on all computers, unlike Word files.

For many, it's not easy to produce PDFs, though. They could buy Adobe Acrobat, but they can't justify the expense for the number of documents they'd convert in a year. They could do it in LaTeX, but that requires a bit of skill they don't have time to develop.

I recently discovered another approach that many may find easier. Parsewiki takes structured plain text and turns it into various formats: DocBook, HTML, or LaTeX. Then, if you have a DocBook toolchain installed, you can create PDF files quickly. That's doable on Windows, and it seemed trivial on Linux. It's not the tool you want for bigger documents, but it may work quite well for you for the one- or two-page memo or summary you'd like to produce.