The knowledge-worker culture has developed some bad habits regarding respect (or lack thereof) for people’s time. This leads meeting organizers – notably project managers – to make some fundamental mistakes about why a team should get together and what they should be able to accomplish. For managers of any kind, here is my list of top status meeting mistakes.

Mistake 1: Let’s Have Status Meetings

How much fun do YOU have telling a roomful of people what you’ve done for the past week, and “where you’re at”? Probably a little more fun than listening to other people tell you “where they’re at,” but not much fun overall, I’ll bet.

In general, no team should depend on a meeting to convey or learn status. Meetings that exist just to exchange status are hugely inefficient and ultimately an expensive use of talent. Multiply the number of attendees times the meeting length to get the number of person-hours lost to a low-value information exchange that spreads a little news but doesn’t really solve problems. When you meet, do so for a purpose with more value, like resolving the top five hot issues or mitigating an emerging risk or adapting to a scope change.

This is especially true when you consider that status updates are communicated most efficiently in writing. Status reports typically cover four general topics: recent accomplishments, progress toward milestones, next actions, and hot issues. Status information is easy to write. It should be as simple as filling in a form, pasting text from a log, typing a progress percentage, even checking a box. Status reports consume far fewer person-hours than meetings, and both  writer and reader can write or read status reports on their own schedule and terms. It’s a perfect opportunity for asynchronous communication.

So to my way of thinking, status meetings shouldn’t exist at all in a project with an efficient status reporting protocol. This assumes some measure of collaborative technology ranging from mere e-mail to online project workspaces. Instead of status meetings, project teams really need “situation rooms” – periodic meetings to handle issues, exceptions, anomalies, the unplanned, and the unexpected. In general, people would much rather work their brains by solving something than having to listen to something they either already know or probably don’t care about.

So for the rest of this rant, I’ll refer to “weekly meetings” instead of “status meetings.”

Mistake 2: We Don’t Need an Agenda

How often have you heard, “This meeting will be short,” only to have it turn into a long conversational equivalent of elevator music? This is one wart on the toad of meetings with no agenda. The team wanders into the room with vague expectations of going over “status” but with no preparation for contributing to important questions or issues that somebody knew about beforehand but kept to themselves.

If you want to encourage engagement in a meeting of any length, build a list of the topics you want to walk through, set time limits on each one, link specific people to each topic, and set forth the probable outcome. It’s best to be as specific as possible in your topic choices, too. If you’re going to go over the bug list, list the titles of the top five bugs you absolutely have to get through. If you finish those five bugs early, great. You can get everybody back to their desks sooner, or you can feel out the crowd to see if a few more bugs can be stomped.

Also important: Publish the agenda the day before the meeting, or at least a few hours earlier. Part of an agenda’s value is that it encourages preparation. It should come standard for almost every meeting.

It’s kind of like teaching: Say what you’re going to talk about, then talk about what you said you’d talk about, then review what you just talked about. Result: clarity and a sense of having learned something new.

Mistake 3: Every Weekly Meeting Should Have the Same Agenda

Ralph Waldo Emerson must have been to some of the same meetings I have:

A foolish consistency is the hobgoblin of little minds,
adored by little statesmen and philosophers and divines.

I’ll stand up first to say that consistency in anything is important for stability, clarity, predictability, and a bunch of other benefits. However, there is no rule in the PMBOK or any other arbiter of project practices that says that you can’t mix it up now and then. As long as you tell the team beforehand (using the revered agenda), introduce some variety and shine the spotlight on particular themes instead of the overall project every week. For example, focus one meeting a month on risk management, another on documentation needs, another on change management efforts, and so forth. It’s usually hard to touch on all of project’s workstreams in one hour a week, so instead of carving that hour into little topical pieces, carve a month of weekly meetings into a set of rolling topics that merit some focused conversation.

Mistake 4: We Don’t Need Meeting Minutes

It’s easy to believe you’ll always remember something until you forget that you need to remember.

It’s not that easy to tell when you’ll really need to look back at an action item or decision that was made in a meeting many months ago.

They might seem superfluous at the time hey’re published, but sometimes it takes only a few days for the value of meeting notes to shine forth. A common example is when a team member needs to look up the minutes to remember which action items were assigned to her this week. The more classic case, of course, are the decision forensics that occur later on when somebody (usually an exec) questions an outcome.

To make meeting notes useful and easy, you don’t have to record a detailed journal of everything that was said. You need only the action items, key decisions, new issues, and the guest list. It makes meeting minutes easier if the person taking the notes is not the person running the meeting.

Mistake 5: Every Problem Must Be Solved Now

If your weekly meetings have evolved from status drudgery up to solving problems, that’s a step in the right direction. The pothole that now opens will probably be the conviction by some or all that every issue that gets raised should get solved before the closing bell rings. Unfortunately, that’s hard to do. If discussion about any single issue goes longer than five or ten minutes, the meeting chair should pound a gavel and send the discussion offline. This will be popular with the attendees who have nothing to say about the long issue and have other issues they want to get to.

Mistake 6: Everybody Needs a New Copy of the Project Plan

I mourn for the timber that gets sacrificed for the printing of the latest version of the project plan for every weekly project meeting. Except for the beginning of a project, most team members will care only for tasks with their name, so copies of the whole plan will get only a brief glance before falling into the trash can. For team members who are not used to looking at project plans very often, being asked to examine a grid full of small-print numbers, dates, and names will keep their attention for about five seconds. They don’t want to see a detailed copy of the big picture every week. They just want to know about any changes to their own tasks, and about their upstream or downstream dependencies.

Once a plan is in motion, team members should be able to pull a view of the whole plan on their own time from an online collaboration workspace or the wall in the hallway. For summarizing progress and project metrics, a dashboard approach works well: a single page or screen with the key progress indicators depicted clearly, usually graphically.

If it’s needed for context – say, to address the downstream implications of a recent scope change – a portion of the project plan can be handed out, but ideally only if it can be made to fit on one or two pages at a standard font size. Anything more will induce the glazed looks of people looking for their five pet bees in a busy hive.

Mistake 7: Everybody Needs to Be at the Weekly Meeting

See the previous item. If the agenda varies, times will occur in which the topic at hand is irrelevant to some of the team. This is another benefit of having an agenda in advance. If it’s obvious up front that a few particular team members won’t be able to get much or give much relative to a particular set of topics, give them a meeting reprieve. You’ll give them an hour they didn’t expect to have, and show that you respect their time and attention. (You’ll need to emphasize that it’s related to current specific agenda items so that an attendance issue doesn’t start to occur later.)

This same mistake is made when sponsors and stakeholders are invited to weekly meetings – a sure-fire way to risk the failure of an agenda. Conversational “scope creep” inevitably occurs the more people you have in a meeting, especially if some of those people are functional managers or executives. They’ll feel compelled to speak, sometimes often. If the value of weekly team meetings becomes diluted because more than the core team attends, protect the time and focus of your core team and set up separate meetings or different ways of communicating with non-core folks.

Mistake 8: All Weekly Meetings Have to Take an Hour

Heck, no. Just enough is plenty.

Rant Over

These are, of course, just my thoughts. I’d love to hear what anybody else thinks.

I doubt this conviction will prompt a change in the Project Management Professional (PMP) certification process, but the concept is worth investigating. So much can be learned from preparing the bar for business, making and serving drinks, ferrying platters of hot food, taking customer orders, communicating orders to the kitchen, cleaning up spills, and other such drudgery. It’s like boot camp for anybody who hopes to get a practical grasp of the physical, verbal, and mental skills needed to operate as a truly effective project manager.

It’s not just for the sake of analogy. There are many skills that nascent project managers can learn from even a brief career in on the other side of the bar:

• Multitasking – Bartenders – like waitstaff and chefs – have to excel at handling many things at once. While you pour a batch of drafts for one customer, you’re taking orders from another (orders that you have to remember for more than five seconds). Meanwhile the dirty glasses pile up beside the small under-the-bar dishwasher that is ready to be emptied, and you need to get word to the bus help that you need more vodka. As with project management, many workstreams all merge into one combined flow of input/output that you have to rapidly parse into a sequence of well-executed tasks in order to please all of your customers and avoid getting injured. The tasks involve not only the standard activities you can easily predict; there are also the unplanned problems you have to respond to: the dropped glass, the angry customer, the police raid, etc. Handling these means…

• Thinking on your feet – Responding quickly to an unexpected situation requires a nominal confidence that, from out of your experience, you can dredge up what you need to handle whatever comes up. It’s an upward spiral: The more challenges you face, the more solutions you try out, and the more successes you have, the more confidence you have to face a greater number of challenges. Bartending gives you a challenge as often as every 30 seconds, especially during happy hour, or during the after-theatre period when customers have an expanded capacity for branching out into bizarre and inconsistent demands. For a normally thoughtful, deliberate person (e.g., many project managers), this kind of improvisatory mentality requires the temporary adoption of an ADD persona. Such improvising is sometimes best prepared for by…

• Following the drill – Bartending, like many professions, involves a collection of well-known, small-scale repeatable processes that require discipline to learn and habit to execute: arranging the bar, minding the dishwashing flow, prepping the garnishes in advance, and so forth. Once mastered, however, these repetitive tasks become automatic and uncomplicated, freeing your mind and body to handle the things that are not part of the drill. For a project manager, the standard repeatable processes involve project documentation, weekly progress tracking, status reporting, budget updates, issue tracking, risk management, “walking around,” and checking in with sponsors. When these become second nature – part of the drill – a good PM frees up mental bandwidth to focus on those things that require more thought and deliberation. It’s all about habits, one of the best of which is…

• Communicating well with many kinds of people - Bartenders have to interact well across a wide spectrum of humanity, including bikers, country club gentry, loving couples, fighting couples, harried waitstaff, bosses, rowdy sports fans, truck drivers, businessfolk, thespians, and bagpeople. Paul the apostle seemed to have this in mind when he wrote, “I have become all things to all men,” a message about communicating with people on their own terms, of having compassionate empathy or sympathy with their current situation. It means adapting to the person currently facing you. In addition to talking with customers, a bartender also needs to communicate customer requests to the kitchen, communicate kitchen issues to the customer, keep the boss informed, handle requests and issues from waitstaff, and give directions to a lost couple trying to find Duluth. Project managers need to communicate well with multiple constituencies, especially when the news is bad or complicated. They need to adapt their message to the current audience. More importantly, as with bartenders, they need to be able to listen more than they talk. A very useful skill is therefore…

• Keeping a neutral expression – In a bar, people usually fulfill their potential to be noisy, irritable, gleeful, unpredictable, loud, unhappy, whiny, elated, lonely, regular human beings, sometimes all at once. A bartender has to put up with a wide spectrum of behavior, and has to be able to respond to it in a way that doesn’t scare anybody or tick them off. Experienced bartenders do this in various ways, but the most efficacious method is usually the “stone face”, a stoic indifference to the local emotional weather combined with a thick skin to withstand verbal slings and arrows. Project managers have to put up with a variety of behavior too. Like bartenders, they need to stay standing – stone-faced and unbothered – in a field of flying arrows in order to reassure their constituencies that mere noise from here and there won’t disturb the progress toward the common goal. This often elusive skill is reinforced by the capacity for…

• Letting things go – As any bartender will tell you, no matter how right you are, the customer is more right than you. In an argument, you can’t usually win just on the merits of your position. Sometimes, you just have to absorb a criticism and move on to the next thing without worrying about what somebody thinks. Obviously, situations arise where letting things go is not appropriate. But knowing to accede when the stakes aren’t high protects your energy for handling the really tough stuff. Pick your battles, don’t sweat the small stuff, etc. This especially helps with…

• Getting along with your peers – In a crowded and fast-moving bar or restaurant scene, somebody needs you to cover their back, and you need somebody to cover yours. In an efficient restaurant or bar, everybody helps everybody else to keep things running smoothly. Even if you’re not buddy material for everybody else working the floor, you know what needs to be done, which routes to take, and who’s in charge of what, and you know that your peers know that too. In project management, it helps to have a common bond with other project managers in your organization and your industry, a function often served by project management offices (PMOs) or, in lieu of a formalized PM organization, some kind of team or support group. Together you support each other with shared methods, common tools, and shared objectives, the most important of which is…

• Placing the customer first – Yes, it sounds obvious, but it needs to be repeated. Some project managers act like a bartender who thinks his job is merely to  arrange the bottles nicely and wipe peanut shells off the bar. But his or her real job is to serve customers well so that the bar makes more money. It’s not enough just to know the standard recipes. A good bartender knows he’s a combination of salesman and “go-fer,” and that his own success links tightly with his ability to fulfill customer needs and bring in the bucks. In the project management world, your certifications, project plans, and years of experience don’t matter a bit if you’re not having an impact on business performance through increased profit or reduced costs. It’s a service role. The best PMs understand that leadership means serving the needs and interests of all stakeholders in a particular initiative, whether it’s for the sponsor providing the oversight, for the team getting the work done, or for the whole business and its strategic goals. It’s not about how good you are; it’s about the good that you do.

Obviously, many jobs other than bartending help develop these abilities. The point is that many project managers can improve themselves through the basic lessons that this kind of work provides. Theory and education are very important, but true effectiveness in a project manager is proven in the day-to-day exercise of certain practical skills that are sometimes best learned in places without desks and conference rooms.

The Times Reader fits into the middle ground between the printed paper and traditional concepts of Web-based media. It “behaves” more like a printed newspaper than any Web version of a metropolitan or national daily. You can browse from one article to the next in a manner that resembles turning pages. More importantly (for me), you can navigate through familiar sections that group the content – “Front Page,” “International,” “Opinion,” “Business Day,” and so forth. There are navigational “front pages” for each section that list the headlines contained in the section, often with brief lead paragraphs excerpted from the corresponding articles. The high-quality news photography we expect from the Times appears throughout, and the electronic nature of the medium allows video and audio to also feature prominently.

The Web-based version of the New York Times and other newspapers already have these characteristics, so what’s different? To begin with, the text appears in multiple columns of relatively narrow width, compared with the typical wide- and single-column approach of most, if not all, browser-based news sites. This multi-column format resembles the print format much more closely than anything else I’ve seen. That’s a good thing, because the text is more readable to me that way, or a least is easier to consume because of reading habits formed by reading printed newspapers. The Reader also adheres closely to the “look and feel” of the printed paper, using the typefaces and layout styles that make up the visual branding that so distinctively identifies the New York Times.

What I also like is that the Times Reader stores up to seven days of the most recent daily editions, so that you can go back to an earlier day in the week to catch anything you might have missed. A search feature complements the section-based navigation to make it as easy as possible to get to whatever you want to read about.

The Times Reader software, currently at version 2.0 (version 2.051, to be exact), is an Adobe AIR application, which means that it’s cross-platform software running on the same foundation as Adobe Flash and related Adobe tools. (I run the application without problems under Linux, Windows, and a Macintosh – the software license allows a user to deploy the application on up to five computers.) It also means that the application features more and better interactivity than is typically available through mere browser-delivered content. It gives developers more tools and freedom to build a rich user experience that clearly correlates with how people are used to reading newspapers. It also allows the Reader to more closely resemble the New York Times print edition.

What’s the real proof of the appeal of the Times Reader? Answer: I’m willing to pay for it, and I do, for a little less than $4 per week. Before the Times Reader, I was unwilling to pay for Web-based newspapers because I never felt completely comfortable with the way the product was presented in Web page format. The Times Reader takes me on a middle road that activates long-used visual and cognitive newspaper-reading habits, but also provides the richer experience of multiple media and the hyperlinking enabled by the online environment. And I also have to say this: The interactive Crossword is hugely addictive.

One thing that I ponder: Where are the ads? There are a few banner-style ads here and there, most of them promotional ads for the New York Times ad department. It’s hard to believe that the Times Reader subscription fee is enough to make the Reader profitable for the publisher. There’s often plenty of white space near the ends of articles within a screen-sized page. Obviously, it’s not that I miss the ads. My pondering is more about how this particular manifestation of the newspaper can be made profitable enough for it to survive and grow. What’s the business model that complements this publishing method?

Something else I wonder about: Can the Times Reader software be the key component of a publishing system that other news organizations – chiefly the rapidly failing newspaper publishers – can license and customize to publish their own content? Could my local newspaper adopt this tool to make itself more appealing and usable to its online readership? I’m sure somebody at the Times is thinking along these lines. But I wonder if the application is mature enough yet to be “genericized” and spun off for other publishers, and if there’s enough time left to do so before a lot more traditional newspaper publishers have to close down.

You finished the first part, you’re poised for the next.
Your mind wasn’t broken, but now will get fixed.
Of all the ideas they’ll throw at your brain,
Some will make perfect sense, some you’ll throw down the drain.
As you get your B.A., you’ll hear lots of B.S.
But your heart and your head are prepared now, I guess.
So keep your eyes bright and your mind even brighter.
The load that at first seems so heavy, is lighter
When all of the topics, the books, and idears,
Don’t matter as much as they might first appear.
What’s really the point as you seek your vocation:
Don’t let school ever keep you from your education!

This could be the basis for a whole new psychology about the human/computer interface. Everybody knows some poor soul who gapes as if Judgment Day has arrived because of an inscrutable error message or an e-mail snafu. Those of us in the IT biz often find ourselves acting like Moses on Sinai trying to mediate between the stern CPU and the wayward People of Userville.

Be sure to also check out Condie’s classic “The Big Snit” when you get a chance.(I love the bit where the wife shakes her eyeballs.)

Last week I spent the day introducing desktop Linux – specifically Linux Mint, Fedora, and Puppy Linux – to youths who are learning and using computer skills through a program called Hopeworks. Hopeworks is a program in Camden dedicated to helping youth build their futures through a mixture of technology education, paid computing work, and personal guidance. The technology focus includes website development, graphic design, and some very cool and practical GIS projects that materially benefit the city and people of Camden. My employer, IT Evolution, also based in Camden, has adopted Hopeworks as one of our outlets for social action and community improvement.

At Hopeworks last week, we took a bunch of older unused desktop PC’s from the basement and booted them up with Live CD‘s from Mint, Fedora, and Puppy. The goal was to get a good Linux desktop environment running on enough PC’s so that each attendee could take one home and have a decently performing system with Linux software equivalents for all the Microsoft Windows-based programs the youth already know about. We achieved that goal, and in the process got to see the surprise that people experience when they discover a rich, secure alternative computing environment running on PC’s that aren’t powerful enough to run the latest Microsoft-ware.

After going through a brief introduction to Linux and the concept of free open-source software (FOSS), we each grabbed an old PC and booted it up using the Live CDs. (Some of the PCs didn’t boot up at all or had problematic hard drives, so we got a chance to open the computers, swap some drives, and learn about PC innards in the process.)

There was some waiting involved during installs, during which we explored OpenOffice’s word processor, Firefox, and graphics applications. One of the students used the GIMP photo-editing program to adjust a receding hairline in a photo of one of the Hopeworks directors. Another student found the Games menu and walked through each of the standard Gnome-based games such as AisleRiot Solitaire and Gnometris (a Tetris clone).

Throughout the day, the participants kept remarking about how easy the setup was, and how much free software was available in the Linux distributions we explored. Using Puppy Linux, a very small-scale Linux distribution designed to perform well on older, slower PCs, we saw the potential for conserving old hardware and keeping it useful without having to depend on Windows. The youth were particularly enamored of the good-looking and well-organized Linux Mint, one of the more artful and well-designed Ubuntu-based distributions.

The notion that a choice of PC operating systems existed at all was new and welcome information for everybody. The “cool” factor really kicked in at the second or third hour when the youth saw the potential of this new  world: Powerful quality software, freely available, community-supported, and comparable to what they already know in the Microsoft world.

We only scratched the surface during this introduction. We’ll continue in another session or two to explore Linux package management, networking, security, and running Windows applications under Linux.

As a consultant, on a few rare occasions, I find myself working on very similar projects for two different clients at the same time. It’s happening now. I’m currently helping a small family-owned energy company and a large multinational consumer products company each build their employee portal, the former from nothing, the latter from a chaotic hodgepodge of stale content from all over. The small company’s portal will reach about 80 employees, and the multinational will publish their new intranet to about 7,000 North American employees.

What I’m enjoying is how much commonality exists in the effort to plan, design, and deploy these two new portals. Scale matters less than I thought it would, at least in the early stages of plotting requirements and content. For both clients, our teams are cataloging the company’s information needs, creating a hierarchy that spans physical locations and business functions. We’re having the same kinds of conversations with the executives, the line managers, the grass roots: What information do you need? What information are you missing? Where can we speed things up? What would you like to say? How easy/hard is it to find stuff?

What’s even more enjoyable is knowing how much positive transformation will occur if people really take advantage of the new resource. The content owners will like the way they can get the word out efficiently, and the content consumers will enjoy having a source for finding and giving back information. This can happen regardless of the size of the company or the intranet. The more people know, the less they fear or worry about. Increasing the flow of information through a company, regardless of its size, means good things for both the company and the individuals working in it.