Snail Mail < Email < Web 2.0

When I was a kid, I loved getting mail. I got holiday and birthday cards, packages, letters from friends and family. As I got older, the quality of my mail shifted lower and lower until I receive only bills and junk mail, with the occasional Netflix disc thrown in. The same thing happened with email, but instead of bills, I get "tasks" (and no Netflix). Postal mail and email have another similarity: they are both passive media. They get sent to you whether you like it or not, and your participation is minimal until you want to send a return message. For the past few years, I have been engaged in "Web 2.0," which is a much more active, engaging medium. Through FaceBook and LinkedIn, I can reconnect with friends and colleagues at many different levels, from reading status updates to email, chat, and even a phone call or two. In daily work, SharePoint fills the same need, but it can take some getting used to.

One of the first things I had to learn about SharePoint was balancing quality and quantity. It is so easy to be inundated with alerts for announcements, file updates, status changes, etc. If I'm actively managing a project, I might want immediate or daily alerts from the system. If not, weekly alerts or none at all are just fine. Another new idea was "pulling" information I wanted. I was so used to being "told" by email, phone calls, meetings, etc, I had to learn what was actually important for me to know and then find it. When I figured it out, I saved all kinds of time. The next big thing was collaboration. Once I started to upload draft documents and work on them with a group, I started to feel the power of Web 2.0. No more emailing endless drafts around in a circle and having to consolidate all the changes. In addition, I began using discussion groups for different aspects of a project. No endless emails and conference calls, no emails. Once I got my clients used to it, they wanted a discussion group for everything.

There are some down sides to the Web 2.0 experience, but most of them can be fixed by training. For example, security: someone needs to be the gatekeeper for the site, library, or list. That person should have the authority to grant read or edit access at will. People do rotate among projects, there are new hires, and upper management may want to look at the team's progress. Another down side is access: SharePoint, LinkedIn, and FaceBook are all designed for access outside the firewall. Users should be able to get to SharePoint from anywhere. Often, unfortunately, organizations prevent outside access, even though they allow outside email access. Strange but true.

For those of you who are dealing with SharePoint, keep in mind that you have a deeper individual responsibility for SharePoint compared to a network share, but that's a good thing. You also have more control and much greater flexibility. I invite anyone with specific questions to put them in the comments. I promise I won't answer like a typical IT guy, because I'm not one. I reserve belittling people for my private life.

How To Lose A Week In Ten Days

Warning: the following blog entry contains math!

I have come to realize that I only enjoy snow in the abstract. The idea of it is fun and enchanting from the living room window, but the cold hard reality of snow from the driveway is all blood, sweat, and tears. If you live in the DC area and don't have a flying car, you were probably stuck at home for much of the "Snowpocalypse last year." If you were prepared, you had food and activities. If you were lucky, you had uninterrupted electricity, cable, Internet, and you got paid.
With 300,000 federal government employees in the DC metro area according to the Bureau of Labor Statistics, and an average salary of about $71,000 according to USA Today, every lost hour of work costs the taxpayer about $10.5 million. The government was basically closed for an entire week, but some workers had access to email or brought some work home with them. Some others may have teleworked. Let's figure 30 hours lost over the snow emergency, which therefore cost a whopping $315 million. Keep in mind, that's only a direct cost, which doesn't count lost productivity by people working out of the area who couldn't communicate with DC people.

Now, I know what you're thinking: the number sounds big, but it's a drop in the federal bucket. Fair enough, but we received zero for it. Nada, zilch, niente. And the government will never make up that productivity over the fiscal year. Is this situation preventable somehow?

Well of course it is, with telework. According to telework.gov's 2009 Annual Report, 102,900 federal employees are teleworking out of 2 million total, which is about 5 percent. The problem is that about half of agencies have not put telework into their Continuity of Operations (COOP) planning in a meaningful way. According to the report, the biggest stumbling blocks aren't IT or security, they are "office coverage" and management resistance.

In a snowstorm, there's no need for office coverage, because nobody's there anyway. For the managers, they should ask whether it's better to encourage telework and put a real plan in place or to watch their human capital budget go down the storm drain. Thanks to technologies like Microsoft SharePoint, any worker with Internet access can work on documents, engage in discussion groups, and schedule meetings much more efficiently than with Outlook. Best of all, documents can stay on a server managed by IT rather than being saved on a home computer. Even if teleworking isn't practical for everyone on a regular basis, it's a great way to ensure that the people's business gets done.

If Results Don't Matter, Neither Do You

I am always envious of the failed CEOs, general managers, and chairs of the big corporations. Over the past ten years, I watched the dot-com guys turn to vapor, real estate magnets go under water, and profitable banks turn on a dime. My wish is always the same, "Please give me that job! I could ruin your company for 10% of what the last guy made!" At the highest levels, it might be OK to pay a bloated salary for terrible performance, but for the rest of us, results matter.

So when I look at SharePoint, I see something similar. Some big-name company is getting paid huge amounts of cash to do a SharePoint implementation. That part I don't mind; what gets me is how poorly SharePoint performs for its user base. Somebody got a big paycheck, but where are the results? I could do a terrible job on that implementation for a fraction of the cost.

The biggest challenge is goals. SharePoint is designed to do certain things very well, but it has no purpose of its own. The organization has to give it a purpose. The goal is not to use SharePoint; the goal should be to increase productivity, decrease costs, improve quality, that sort of thing. Then it's time to explain how SharePoint can help the organization get there -- those are the strategic objectives. Every site, every feature, every web part needs to align with those objectives in some way. Otherwise, the launch will be a mess of frustration and fingerpointing.

The other big challenge is metrics. They should be concrete and actually measureable. Want to reduce the average size of email? Measure it before the implementation and set a goal number, like 20% less. Reduce production time for a document? Find out how long it takes now; set a goal number. Whatever the improvement is, compare before and after, and three months out, and six months out, etc. Not everyone will jump into SharePoint at once, and it's a good idea to check metrics over time, anyway.

An unrelated point about implementations. Don't let IT circumvent the core functionality of SharePoint. If you have security or policy that bars some core functions, please use something else. It is very frustrating to be denied a basic feature that comes out of the box, like multiple file upload to a library.

SharePoint in a Crisis

There will always be surprises. While some are pleasant, others can be downright nasty, and it can take a group effort to handle them. Managing a crisis effectively entails internal and external communication, sound policy, group support, and an easy-to-use communication platform that can reach everyone.

Hey, guess what? I recommend SharePoint. I've gone on and on about certain features before, but this time I want to bring them together for a particular purpose. Here's a recipe for emergency management with SharePoint. First, there's a lot of prep work. Your organization should already have an emergency website with policies, procedures, internal contact info, friendly media contacts, first responder information, etc. Of course, you are already subscribed to the RSS feed for any important changes. What? You don't have this? Hmmm... OK, there's your first step.

Set up a site template for a discrete crisis. Make sure you have the features you want and everything is placed in line with your users' expectations. When a crisis occurs, launch a new site under your emergency site using the crisis template. Then you can assign a crisis manager and assistants, fill out forms, collaborate on press statements, make internal announcements, all within SharePoint. For the thumb-typers out there, SharePoint has a mobile version so people in the field can get the same info. Just append "/m" to the URL.

When the crisis is resolved, archive the site. If a new one occurs, launch another one. SharePoint may not save a life or a building, but if you provide good communication on a reliable platform, you just might.

P.S. Put your SharePoint server in the cloud so a location threat doesn't knock out a valuable piece of your global communications.

Oh, Bother

I just did the math. During the workday, I get an email every 10 minutes that matters to me. Those emails are links to news articles, file attachments, tasks, questions, reminders, alerts, and read receipts. I get calendar invitations to meetings, conference calls, webinars, lunches. I also get phone calls, voice messages, walk-ins, and snail mail. Every time I turn around, somebody wants me to do something or read something, so I've stopped turning around. In the old days, it was common for powerful executives like myself to have an assistant. That person would be the gatekeeper: he or she would open the mail, take the phone call, write the letter I would sign, handle my schedule, etc. Now, all but the top echelons in the biggest organizations must manage their own communication and schedule. The PDA or "virtual assistant" is more a nag than a help. It can be difficult to focus on the task at hand with all of these paralyzing distractions. As a result, I think more than a few of us are suffering from overload.

So we're missing that buffer layer that used to separate a manager from employers, employees, and customers. Short of paying a fat salary and sacrificing office space for a professional administrative assistant, what can we do about it? Here's where a combination of psychology, trust, email management, and SharePoint come into play.

First, the psychology. I understand that managers like to seem on top of things. Is getting an email that a file was uploaded really their job? The daily minutiae of a project should be handled by team members, not the manager. That includes acting as interpreter between the customer and the team. Managers should et them communicate directly and wait for the regular report. The team is reporting their activity, right?

That brings us to trust. If team members have to be watched all the time, it's time to get a different team. Managers should support the team, which includes giving them opportunities for both success and failure. OK, no one likes failure, but I've learned more from my failures than my successes. The trick is to fail in small ways and have a backup plan.

There are hundreds of experts on email management, and this blog is not supposed to be book-length, despite my best efforts. All I will say is that project emails are usually better off as content in a collaboration system. Discussion groups, wikis, blogs, lists, project calendars, and other features are often better containers of project information than email because different types of data are handled different ways. Email just puts stuff in the inbox, no matter what it is.

Last, but not least, is SharePoint. Chances are that most folks reading this blog already have it or something like it. Managers should show the project team how to use it specifically for collaboration and communication on the project before them. This could mean using announcements for team updates, a blog for reporting, and a project wiki to pool decisions made or lessons learned. Then it's time for the manager to set alerts. No phone calls, no emails, no endless conference calls. For long-term projects, I set my alerts to get a weekly email summary of activity. Shorter term, I like a daily summary. I don't want to see the 10 emails it took to decide on a background color; I just want to know if the client is happy. As a project nears completion, I will reset my alerts to "immediate" to make sure the rollout is going smoothly.

The key to combating information overload is getting only the information I need. Through a combination of back-to-basics management and SharePoint technology, I think I've tamed the beast for now.

The App Heard 'Round the World

Email is pretty easy. With a few clicks and a little typing, I can communicate with anyone around the world. Email is also pretty fast. In a few seconds, the email I send is waiting in the other person's inbox for viewing. Email is pretty convenient; I can attach files, include hyperlinks, and contact many people at once. In the communication toolbox, email is as handy and necessary as a screwdriver. In the global collaboration toolbox, however, email is more like a sledgehammer -- good for specific tasks, but destructive if overused.

For example, think of eight people in different offices around the globe working on a project plan. They don't know each other, but a senior manager has put them together for this task. Naturally, each person has different expertise and opinions. They work on the plan and send out emails to the team. Draft after draft is distributed, copied, edited, split, and recombined. In the end, the team spends as much time piecing the final plan together as they spent drafting it in the first place.

Next time, they could use an actual collaboration tool, rather than a messaging tool. My preferred tool is SharePoint, though there are a few of them out there. SharePoint provides the necessary architecture out of the box, and there are a number of qualified independent vendors who can to build it to spec. With a little training, workers can take advantage of features like personal profiles and social networking features so they can get to know their teammates on the other side of the world or down the hall.

There are plenty of task-specific features as well. Document workspaces leverage check in/check out and versioning functionality so the team never has to wonder about the latest changes or accidentally editing an old version. Alerts via email or RSS feed automatically notify the team when new drafts are available for review. Personally, one of the features I like the most is threaded discussion groups. My team can keep track of ideas this way, and it really saves on the conference calls and note-taking. Another huge advantage of SharePoint is having a platform to keep senior management informed by giving them read-only rights to the collaboration site.

I know today's entry reads like a sell sheet, but whatever tool your organization chooses, I hope they make a sincere effort to transition out of email. It's just not the right tool.

Expose Your Knowledge, Avoid the Competence Crisis

It happens in any organization: people leave. Sometimes there is a great loss to the organization when folks move on. The career administrator who "knows where all the bodies are buried" also knows in detail how the organization runs and why. The new hire may be schooled in all the latest techniques and technology but doesn't know the organization like the old hand. Circumstances often dictate little or no transition period with both employees on board, and a wealth of institutional knowledge can be lost. Just about everything the newbie needs to know is locked in a file cabinet or five, and it's a big task just to figure out what's there. The alternative is to spend months re-integrating the team, and no one wants that.

There's a two-stage process to resolve this dilemma. Stage one is to dust off those file cabinets and scan everything. The difficulty here is setting aside the space, time, and personnel to scan. High-speed scanners are expensive and take training; interns have low motivation to produce volume or quality. Since no one is using those files anyway, let a pro cart them off, scan the documents, and destroy the files (or return them if you have to keep them). Scanning will happen in record time, and you don't have to reorganize your office around the activity. Do this yearly if you have to.

Stage two is all SharePoint. Upload the searchable files and let the administrator tag the ones that are important. Let the whole team loose if you want to. Add in electronic files like emails and Word docs, and you'll start to paint a complete picture. Then submit cross-references and comments about the documents. Do a review of a program as a wiki, linking your files throughout. Now you have a knowledge repository that will bring new people up to speed quickly or crosstrain existing employees. This is an easy way to minimize the disruption of job changes and keep productivity high.

SharePoint Is a Waste of Money, But It Shouldn't Be

Microsoft SharePoint 2007 is an amazing tool. Imagine a project management site, library, supply chain system, and records center coupled with Web 2.0 and social networking. It can't miss, right? Right! The promise of SharePoint has made it a wildly popular implementation in business and government. The practicality of it, however, has made it a hair-pulling experience for many people who are just trying to get some work done. Where's the disconnect?

The biggest challenge seems to be implementation. Typically, SharePoint gets poor treatment by IT people, who view it as a glorified web server or network share. Either way, it's an unknown and therefore a pain. Often, IT folks will spend six months planning the hardware and bandwidth and six hours on the software. Once SharePoint is turned on, the team walks away. It's tough for most employees to create a website from scratch; it's almost impossible for a novice to use SharePoint to its potential. The hardware, licensing, and IT effort are all for naught.

The answer is pretty simple: IT need to listen to the user base. They should find out -- from workers, not their manager -- about their daily work. Engineers can discover with them what features SharePoint can offer that save them some effort. Programmers can go over the use of RSS feeds and alerts for automatic communication. Trainers can school them in the benefits and surface usage. Once they get their feet wet, users will come back to IT for time-saving features that will really demonstrate SharePoint's ROI. Otherwise, SharePoint is just another spike in the five-year budget.