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.
Monday, December 27, 2010
Saturday, December 18, 2010
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.
Saturday, December 11, 2010
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.
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.
Saturday, December 4, 2010
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.
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.
Saturday, November 27, 2010
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.
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.
Saturday, November 20, 2010
4th Floor -- Results, Organizational Benefits, Objectives, Goals
I gave a seminar on elearning at a federal department this week. It was full of training managers and other human capital experts. They all had the same comment: "This is great information, but it doesn't address what I really need. How do I convince upper management that training is valuable?" As we examined that topic from different angles, a few things became clear. First, many training managers aren't measuring their training beyond a course evaluation. Second, and more shocking, upper management isn't sharing program objectives or organizational goals with the training team.
Let's take the measures first. You're probably familiar with Donald Kirkpatrick's evaluation model. Four levels of training assessment are broken down into a learner's evaluation, a learning assessment, knowledge transfer, and organizational benefit. Each level is measured and builds on the preceding one. It's pretty simple in concept, but it can be difficult to practice.
The training managers had some problems with the level one assessments. One issue was the questions didn't seem to go far enough. It's good to ask a learner how he or she liked the course, but it's better to go a little deeper. Ask how the learner would do it differently or if any information seemed to be missing. Find out how the learner would have survived without the course, and what resources he or she might have used if the course didn't exist. Another big issue was making sure the online evaluations were anonymous in the LMS -- something any good programmer should be able to provide with little difficulty.
At level two, managers seemed to be uncomfortable with the idea of a pretest evaluation of the learning population. They wanted to get on with the training. I sympathize, but it's really important to know how your training changed the learner's knowledge. If you don't know that, it's impossible to know what direct effect your training has had.
Level three, interestingly, was the easiest for training managers to handle. After all, they had numbers to justify that a particular skill was lacking in some way, and it was easy enough to do an additional evaluation to note the change in skill. Since the level two measures were lacking, however, managers could only guess that training was responsible for the change. Increased awareness, marketing, or other factors may have been responsible.
The biggest issue was level four, which is to be expected. Since training managers didn't have the first three levels of measurement on solid footing, and upper management wasn't sharing its objectives (or didn't have any), level four was an impossible climb. We've already looked at some issues with the first three levels, which are generally under the training manager's control. Since organizational goals and program objectives are the purview of higher powers, what can a training manager do?
I think the answer is simple: make something up. Training managers know enough about the organization to understand its mission. They know about the big programs and what they're designed to do. The trick is to tie the course to the program.
Though training managers may not get the news, marketing is all over this stuff. Every press release is peppered with "meeting the executive's goal of..." or "increase operational efficiency" or "reduce our risk exposure." This kind of language is all over an organization's website. Trainers should just pick a goal and march with it. Better yet, pick several. It's not a trick; any good trainer can identify organizational deficiencies instinctively. Trainers know what the organization needs, they just need a little help describing it to the folks with the checkbook.
Training must have a purpose, and that purpose should at least include an organizational benefit. As long as the first three Kirkpatrick levels are solid, it should be easy to show the way to level four.
Let's take the measures first. You're probably familiar with Donald Kirkpatrick's evaluation model. Four levels of training assessment are broken down into a learner's evaluation, a learning assessment, knowledge transfer, and organizational benefit. Each level is measured and builds on the preceding one. It's pretty simple in concept, but it can be difficult to practice.
The training managers had some problems with the level one assessments. One issue was the questions didn't seem to go far enough. It's good to ask a learner how he or she liked the course, but it's better to go a little deeper. Ask how the learner would do it differently or if any information seemed to be missing. Find out how the learner would have survived without the course, and what resources he or she might have used if the course didn't exist. Another big issue was making sure the online evaluations were anonymous in the LMS -- something any good programmer should be able to provide with little difficulty.
At level two, managers seemed to be uncomfortable with the idea of a pretest evaluation of the learning population. They wanted to get on with the training. I sympathize, but it's really important to know how your training changed the learner's knowledge. If you don't know that, it's impossible to know what direct effect your training has had.
Level three, interestingly, was the easiest for training managers to handle. After all, they had numbers to justify that a particular skill was lacking in some way, and it was easy enough to do an additional evaluation to note the change in skill. Since the level two measures were lacking, however, managers could only guess that training was responsible for the change. Increased awareness, marketing, or other factors may have been responsible.
The biggest issue was level four, which is to be expected. Since training managers didn't have the first three levels of measurement on solid footing, and upper management wasn't sharing its objectives (or didn't have any), level four was an impossible climb. We've already looked at some issues with the first three levels, which are generally under the training manager's control. Since organizational goals and program objectives are the purview of higher powers, what can a training manager do?
I think the answer is simple: make something up. Training managers know enough about the organization to understand its mission. They know about the big programs and what they're designed to do. The trick is to tie the course to the program.
Though training managers may not get the news, marketing is all over this stuff. Every press release is peppered with "meeting the executive's goal of..." or "increase operational efficiency" or "reduce our risk exposure." This kind of language is all over an organization's website. Trainers should just pick a goal and march with it. Better yet, pick several. It's not a trick; any good trainer can identify organizational deficiencies instinctively. Trainers know what the organization needs, they just need a little help describing it to the folks with the checkbook.
Training must have a purpose, and that purpose should at least include an organizational benefit. As long as the first three Kirkpatrick levels are solid, it should be easy to show the way to level four.
Saturday, November 13, 2010
Spend Your Training Budget, Train No One
Looking over some of my previous posts, I have discovered a common theme: scaling objectives. That is, achieving a goal by building a small but solid foundation and scaling up as needed to meet the goal. Unfortunately, some training program managers choose to spend lots of money on the one elearning component that doesn't directly train anyone: a learning management system. As soon as a training program is launched, some people go running for infrastructure. Don't get me wrong; I'm not against using an LMS. I just don't think that kind of major purchase is Step One.
So what is Step One? Figuring out what Step One is, of course. Look at all the people you serve. What are their duties? Where are the biggest area for improvement? What kind of impact would training make on performance? In other words, make sure you know who you are training and what courses they should have. Then it's time to figure out how.
There are two main directions to go: synchronous and asynchronous. Those are just 50-cent terms for instructor-led and self-directed. Which way to go is mostly based on how many learners you have, how many courses you intend to provide, and the course content, not to mention budget. Synchronous training is LMS-independent; classroom training has existed for centuries. Asynchronous training needs an LMS of some kind, but it doesn't have to cost much.
The essence of an LMS for many organizations is automated reporting. Test scoring, classroom scheduling, and course creation can all be beneficial, but for most trainers they are expensive add-ons. The bad news is that a traditional LMS includes those expensive add-ons and contributes to a huge budget footprint. The good news is that you don't have to have a traditional LMS to do your reporting.
If you have access to an intranet similar to SharePoint, work with a good developer to devise a solution for your internal or OPM reporting needs. The course and reporting can be hosted on your intranet and reporting data can be pushed to an external source as needed. The development will cost a fraction of a full-blown LMS, and there are no recurring costs, since your intranet license is already covered.
So when do you need an LMS? The answer varies with the organization, but here are some rough guidelines.
Otherwise, stick with a home-grown reporting tool and use that huge savings to get some courses ready.
So what is Step One? Figuring out what Step One is, of course. Look at all the people you serve. What are their duties? Where are the biggest area for improvement? What kind of impact would training make on performance? In other words, make sure you know who you are training and what courses they should have. Then it's time to figure out how.
There are two main directions to go: synchronous and asynchronous. Those are just 50-cent terms for instructor-led and self-directed. Which way to go is mostly based on how many learners you have, how many courses you intend to provide, and the course content, not to mention budget. Synchronous training is LMS-independent; classroom training has existed for centuries. Asynchronous training needs an LMS of some kind, but it doesn't have to cost much.
The essence of an LMS for many organizations is automated reporting. Test scoring, classroom scheduling, and course creation can all be beneficial, but for most trainers they are expensive add-ons. The bad news is that a traditional LMS includes those expensive add-ons and contributes to a huge budget footprint. The good news is that you don't have to have a traditional LMS to do your reporting.
If you have access to an intranet similar to SharePoint, work with a good developer to devise a solution for your internal or OPM reporting needs. The course and reporting can be hosted on your intranet and reporting data can be pushed to an external source as needed. The development will cost a fraction of a full-blown LMS, and there are no recurring costs, since your intranet license is already covered.
So when do you need an LMS? The answer varies with the organization, but here are some rough guidelines.
- Courses have expanded to a curriculum tied to a career path
- The learning population is over 200
- The number of courses exceeds 50
- You really want all the add-on features of a traditional LMS
Otherwise, stick with a home-grown reporting tool and use that huge savings to get some courses ready.
Saturday, November 6, 2010
Section 508 Blues
Technology is amazing. When it comes to online training, I am impressed with what a good programmer can do. I have both produced and taken online training in various forms, and I love it when I really get the subject matter. Programmers use lots of techniques and media to make training engaging, like interactivity, video, audio, branching paths, cool graphics and animations. True, some of it can be just eye candy, but a good instructional designer will employ multimedia to give learners further insight. Giving a high-level learning experience is so valuable, I sometimes wonder why federal government trainers do anything else. Then I remember -- Section 508.
In case you don't know, Section 508 of the Americans With Disabilities Act "... requires that Federal agencies' electronic and information technology is accessible to people with disabilities," according to www.section508.gov. What does this mean? Nobody seems to really know, because its broad interpretation leaves a lot of leeway. The spirit of the law, however, is pretty easy to understand: make the experience of a disabled individual as close as possible to that of someone who isn't disabled.
With that in mind, it's time to make all that interactivity and media accessible. Sounds pretty simple in theory, doesn't it? In practice, unfortunately, development tools like Flash provide only the most rudimentary accessibility support. Sure, it's easy enough to provide tab navigation to people who use interface devices other than a mouse, and providing captioning for the deaf and hard of hearing isn't that hard, either, though it takes some time. Section 508 for the blind, though, is a real challenge.
Out-of-the-box navigation objects and media containers just aren't built to work well with screen reader programs like JAWS. Online, screen readers want to examine every piece of content, regardless of its relevance. They aren't bright enough to know that a background graphic isn't as important as a lesson title. We have to tell screen readers what's important with good programming, and that takes lots of time and skill.
So why bother? We have other options. Maybe we can just make a website with no graphics or interactivity at all. That's pretty easy to make 508 compliant. The only problem is we've just fallen off the training wagon into a big pile of "information." If we can't do a little simulation, coaching, or interaction, it's hard to know whether learners can apply what we're trying to teach them.
Maybe we can just provide a "text equivalent," which is a transcript of the online course. It's a technical out but doesn't conform to the spirit of the law in any way. People who use the transcript will only be told, not trained.
It looks like we're stuck with providing a rich, valuable learning experience for everyone, regardless of disabilities. That means we have to make those custom interface controls, provide narration, and describe buttons, graphics, and animation. We will use a screen reader like JAWS to test our work. We will try to get as close to the same experience as we can with the resources we have. We want to train everyone, don't we?
In case you don't know, Section 508 of the Americans With Disabilities Act "... requires that Federal agencies' electronic and information technology is accessible to people with disabilities," according to www.section508.gov. What does this mean? Nobody seems to really know, because its broad interpretation leaves a lot of leeway. The spirit of the law, however, is pretty easy to understand: make the experience of a disabled individual as close as possible to that of someone who isn't disabled.
With that in mind, it's time to make all that interactivity and media accessible. Sounds pretty simple in theory, doesn't it? In practice, unfortunately, development tools like Flash provide only the most rudimentary accessibility support. Sure, it's easy enough to provide tab navigation to people who use interface devices other than a mouse, and providing captioning for the deaf and hard of hearing isn't that hard, either, though it takes some time. Section 508 for the blind, though, is a real challenge.
Out-of-the-box navigation objects and media containers just aren't built to work well with screen reader programs like JAWS. Online, screen readers want to examine every piece of content, regardless of its relevance. They aren't bright enough to know that a background graphic isn't as important as a lesson title. We have to tell screen readers what's important with good programming, and that takes lots of time and skill.
So why bother? We have other options. Maybe we can just make a website with no graphics or interactivity at all. That's pretty easy to make 508 compliant. The only problem is we've just fallen off the training wagon into a big pile of "information." If we can't do a little simulation, coaching, or interaction, it's hard to know whether learners can apply what we're trying to teach them.
Maybe we can just provide a "text equivalent," which is a transcript of the online course. It's a technical out but doesn't conform to the spirit of the law in any way. People who use the transcript will only be told, not trained.
It looks like we're stuck with providing a rich, valuable learning experience for everyone, regardless of disabilities. That means we have to make those custom interface controls, provide narration, and describe buttons, graphics, and animation. We will use a screen reader like JAWS to test our work. We will try to get as close to the same experience as we can with the resources we have. We want to train everyone, don't we?
Saturday, October 30, 2010
Uncle Sam Is So Anti-Social
Social networking sites have become powerful tools for connecting people. Whether it's a party, political event, or a business deal, people are increasingly getting it done through FaceBook, Twitter, and LinkedIn. Some workplace technologies, like SharePoint, have social tools to enhance collaboration. Status updates are replacing group emails, and it's starting to be difficult to know what's going on without logging on.
The federal government, however, is adopting social networking and Web 2.0 at a snail's pace. A few agencies, like the Centers for Disease Control and Prevention (CDC), are at the forefront of government use of social networking. Many other agencies, however, severely limit or even forbid their people from using these new tools in any official capacity. Instead, government workers are posting commentary and information unofficially and creating the same kinds of information conflicts the outright ban was levied to avoid.
Certainly, the government has a duty to protect some information like internal operations, personally identifiable data, and classified material. I'm pretty sure they have laws, rules, and policies to cover this stuff already. Does the medium really matter? Isn't distributing classified material already illegal?
These bans are a lot like the bans some states enacted on using a cellphone while driving. Distraced driving laws are already on the books; we don't have to cover every single distractive act a driver can commit. In fact, the more that laws against activities like text messaging get passed, the weaker the general distracted driving law gets. It's a vicious circle; as the overarching law weakens, legislatures feel compelled to pass dozens of mini-laws to cover it. By the same token, singling out a particular technology to ban implies that the others are somehow OK to abuse.
Web 2.0, including social networking, is simply a different way to communicate. It should be governed by the same information policies that regulate email, phone calls, and dinner party conversation. If the answer is not banning or policy changes, what is it? Training. How about allowing official use of Web 2.0 technology to communicate with the public after a review of established guidelines and practical training in their application? In other words, why not teach government workers about appropriate use of Web 2.0 instead of pushing it underground? Then discipline or dismiss the offenders without shutting out everyone else.
The federal government, however, is adopting social networking and Web 2.0 at a snail's pace. A few agencies, like the Centers for Disease Control and Prevention (CDC), are at the forefront of government use of social networking. Many other agencies, however, severely limit or even forbid their people from using these new tools in any official capacity. Instead, government workers are posting commentary and information unofficially and creating the same kinds of information conflicts the outright ban was levied to avoid.
Certainly, the government has a duty to protect some information like internal operations, personally identifiable data, and classified material. I'm pretty sure they have laws, rules, and policies to cover this stuff already. Does the medium really matter? Isn't distributing classified material already illegal?
These bans are a lot like the bans some states enacted on using a cellphone while driving. Distraced driving laws are already on the books; we don't have to cover every single distractive act a driver can commit. In fact, the more that laws against activities like text messaging get passed, the weaker the general distracted driving law gets. It's a vicious circle; as the overarching law weakens, legislatures feel compelled to pass dozens of mini-laws to cover it. By the same token, singling out a particular technology to ban implies that the others are somehow OK to abuse.
Web 2.0, including social networking, is simply a different way to communicate. It should be governed by the same information policies that regulate email, phone calls, and dinner party conversation. If the answer is not banning or policy changes, what is it? Training. How about allowing official use of Web 2.0 technology to communicate with the public after a review of established guidelines and practical training in their application? In other words, why not teach government workers about appropriate use of Web 2.0 instead of pushing it underground? Then discipline or dismiss the offenders without shutting out everyone else.
Saturday, October 23, 2010
I Will Not Make A Cloud Pun
The world is moving to cloud computing, where servers online act as organizational file shares and software is distributed as a service, accessed right through your web browser. Some describe cloud computing as a return to mainframes, and there are some similarities. If you don't know what a mainframe is, go ask your dad. One major difference is that internal networks and desktop PCs have a role in storing more sensitive data, serving location-specific needs such as printing, and hosting beefier programs and very large files.
One of the organizational benefits is to reduce need for network servers within an organization, thereby causing less IT headache. Users don't really know where their files are anyway, so switching to the cloud from a network share shouldn't be a problem. In the future, storage space, bandwidth, and application usage may be measured and billed like electricity or phones are now.
The federal government's CIO, Vivek Kundra, is looking to the cloud as a solution to the challenge of spiraling IT infrastructure costs. While acknowledging a transition period, he seems to believe that the cloud will result in greater efficiencies and huge cost savings. From what I've read, he bases his argument on his work with the Washington, DC government, where he introduced Google applications to over 30,000 government workers. Reportedly, over 4,000 (about 13%) are using the cloud on a regular basis. The federal plan is to roll out similar cloud services to 300 million worldwide government workers. With similar usage rates, there should be about 39 million regular federal cloud users within a year of the official rollout.
What I wonder is, can this cloud experience be replicated on such a massive scale? Whenever I am presented with numbers, I like to do some math. 300 million is 10,000 times 30,000. That's four orders of magnitude from DC government to the federal level. I don't think it's reasonable to expect the tech czar to recreate his success 10,000 times over, but let's look a little further before passing judgement.
To get another perspective, I googled "30,000." Here are some results from the first ten (out of 99,500,000):
The last two items seem particularly interesting. 30,000 patients seems like a ghastly amount of people waking during surgery, but out of 20 million surgeries in the US each year, maybe it's not so many. After all, 99.85% of patients don't wake up during surgery. Then again, if it were the fabled "5 nines" (99.999%, or down only about five minutes every year) of the IT server world, only 200 patients would wake up. If server uptime was 99.85%, it would be down for an entire day every week. OK, maybe that's an unfair comparison. Anesthesia has only been in regular medical use for about a hundred years; servers have been around for... wait a minute.
That brings us to the item about Facebook. Notice how the same numbers pop up: 30,000 servers, 300 million users, so that's 10,000 users per server. So what? Well, Facebook was down this week for hours, at least for some people. Will the government launch its cloud initiative with 30,000 servers? If only 13% of government workers use the cloud, we still need 3,900 servers to accommodate them, and for more activity than Mob Wars and status updates. Earlier this month, T-Mobile and Microsoft destroyed data for all of its Sidekick phone users, who lost all of their contacts and other personal information. What assurance will the government have that the cloud will be properly maintained and backed up?
The federal government has not had the best track record at massive IT upgrades. Search online for upgrade problems with NMCI or FBI and you'll find a litany of lost money and productivity. The cloud transition will require many of the improvements in government infrastructure that would be necessary without the cloud. Firewalls will need to be modified, browsers upgraded, bandwidth widened, etc. etc. All this has to be done by a group of internal IT folks who are often contractors with a vested interest in the status quo. Even the government employees in IT face reduction in force or at least a transfer.
Maybe a good first test is to push SharePoint into the cloud. Agencies have only been using it for a few years, so it shouldn't have such a backlog of files and legacy applications like so many other servers do. Users don't know where the SharePoint server is, and it doesn't matter anyway, since it is designed for external as well as internal access. Development of most SharePoint applications takes place through the browser or the free SharePoint Designer; there's very little need to login to the server directly. Since many government workers use some form of Microsoft Office in their daily work already, workflows can stay the same, and agencies can avoid supporting a melange of office productivity tools.
Though cloud computing is indeed what the future holds, it is just getting started in the corporate world. It's a good idea to start with technology that is well-suited to the cloud, but familiar to users at the same time. Pushing SharePoint to the cloud first will help ensure a smoother transition.
One of the organizational benefits is to reduce need for network servers within an organization, thereby causing less IT headache. Users don't really know where their files are anyway, so switching to the cloud from a network share shouldn't be a problem. In the future, storage space, bandwidth, and application usage may be measured and billed like electricity or phones are now.
The federal government's CIO, Vivek Kundra, is looking to the cloud as a solution to the challenge of spiraling IT infrastructure costs. While acknowledging a transition period, he seems to believe that the cloud will result in greater efficiencies and huge cost savings. From what I've read, he bases his argument on his work with the Washington, DC government, where he introduced Google applications to over 30,000 government workers. Reportedly, over 4,000 (about 13%) are using the cloud on a regular basis. The federal plan is to roll out similar cloud services to 300 million worldwide government workers. With similar usage rates, there should be about 39 million regular federal cloud users within a year of the official rollout.
What I wonder is, can this cloud experience be replicated on such a massive scale? Whenever I am presented with numbers, I like to do some math. 300 million is 10,000 times 30,000. That's four orders of magnitude from DC government to the federal level. I don't think it's reasonable to expect the tech czar to recreate his success 10,000 times over, but let's look a little further before passing judgement.
To get another perspective, I googled "30,000." Here are some results from the first ten (out of 99,500,000):
- a Washington Post article mentions that 30,000 jobs were created or saved due to the federal economic stimulus package
- the New York Daily News reports that 30,000 poll workers may not get paid for election work in the NYC area this year.
- 30,000 people a year wake up during surgery, according to msnbc.com
- a datacenterknowledge.com interview reveals that Facebook has 30,000 servers
The last two items seem particularly interesting. 30,000 patients seems like a ghastly amount of people waking during surgery, but out of 20 million surgeries in the US each year, maybe it's not so many. After all, 99.85% of patients don't wake up during surgery. Then again, if it were the fabled "5 nines" (99.999%, or down only about five minutes every year) of the IT server world, only 200 patients would wake up. If server uptime was 99.85%, it would be down for an entire day every week. OK, maybe that's an unfair comparison. Anesthesia has only been in regular medical use for about a hundred years; servers have been around for... wait a minute.
That brings us to the item about Facebook. Notice how the same numbers pop up: 30,000 servers, 300 million users, so that's 10,000 users per server. So what? Well, Facebook was down this week for hours, at least for some people. Will the government launch its cloud initiative with 30,000 servers? If only 13% of government workers use the cloud, we still need 3,900 servers to accommodate them, and for more activity than Mob Wars and status updates. Earlier this month, T-Mobile and Microsoft destroyed data for all of its Sidekick phone users, who lost all of their contacts and other personal information. What assurance will the government have that the cloud will be properly maintained and backed up?
The federal government has not had the best track record at massive IT upgrades. Search online for upgrade problems with NMCI or FBI and you'll find a litany of lost money and productivity. The cloud transition will require many of the improvements in government infrastructure that would be necessary without the cloud. Firewalls will need to be modified, browsers upgraded, bandwidth widened, etc. etc. All this has to be done by a group of internal IT folks who are often contractors with a vested interest in the status quo. Even the government employees in IT face reduction in force or at least a transfer.
Maybe a good first test is to push SharePoint into the cloud. Agencies have only been using it for a few years, so it shouldn't have such a backlog of files and legacy applications like so many other servers do. Users don't know where the SharePoint server is, and it doesn't matter anyway, since it is designed for external as well as internal access. Development of most SharePoint applications takes place through the browser or the free SharePoint Designer; there's very little need to login to the server directly. Since many government workers use some form of Microsoft Office in their daily work already, workflows can stay the same, and agencies can avoid supporting a melange of office productivity tools.
Though cloud computing is indeed what the future holds, it is just getting started in the corporate world. It's a good idea to start with technology that is well-suited to the cloud, but familiar to users at the same time. Pushing SharePoint to the cloud first will help ensure a smoother transition.
Friday, October 15, 2010
Full-Motion Panic
My industry reading is backlogged, so I didn’t see this item until recently. A press release from the Gartner Group outlines an article that predicts that by 2013, more than 25 percent of content that workers see in a day will be pictures, video, audio. The author claims, “enterprises that see such growth as irrelevant to their operations risk alienating themselves from customers who start to request video communication services.” Hold the videophone, this could be a sea change, perhaps a revolution. The article seems to predict workplace chaos. “Users … will not accept onerous restrictions of inflexible security, access controls or forced metadata schemes in the workplace.”
The Gartner Group is usually an excellent source of statistics, industry trends, and other hard-to-find research, but I’m not getting the urgency or danger here. Certainly, the use of video online has skyrocketed, partially because of the prevalence of broader bandwidth, better compression algorithms, and faster hardware. Mostly, though, video is more popular on the web because there’s something to watch. As we used to say before the .com collapse, “Content is king.” Employees are going to YouTube and Hulu to relax and enjoy themselves; they’re not checking out the CEO’s video blog in droves. Entertainment is different from office life, at least for most people. A tedious office video is equally boring in the conference room or on a desktop.
Video can be a great medium to demonstrate physical procedures, impart wisdom from an expert, or give a live view of an event or place. In the 60 or so years that video has been widely available, it has both entertained and enlightened us. Putting it on a computer isn’t something that organizations have to prepare for any differently than they had to prepare for voicemail, email, faxes, and the like. The most important question is not “What will customers demand,” or “What will our employees put up with,” but “What business need does video fill?” From that starting point, we can examine what to do about it and look back at the recently trod paths of websites and collaboration tools for some guidelines.
In order to put this technology in the hands of employees, we need to do a little scratchpad work on procedure. It’s a good idea to figure out what video is for in an organization before letting everyone loose with a camera and upload space. Every other method of business communication is governed by policy; untested ones like video should have some broad guidelines. I don’t mean to suggest locking the general counsel in a room until there’s a 400-page ironclad policy, but the same rules for trade secrets, appropriate language, etc. need to be in place for video. Next, let people try it. Employees can cover meetings, construction progress, depositions, or whatever they think makes sense. Let them record with cell phones, Nanos, videocameras, or anything else on hand. Give them space to upload within the intranet and take stock. Now that people have gotten their feet wet with video, the organization should have some ideas on further policies and directions.
Once the organization knows where they’re going with video, it’s time to look for technology. Any sophisticated video-handling system licensed within the next twelve months will probably be replaced by something five times as good and a third as expensive by 2013. Organizations must determine how immediate the need for video communication is. If they can wait, they should do so. There are plenty of content management technologies out there that handle video to a degree, but we’re a long way from a SharePoint-style video intranet server, at least for most groups.
What’s most important is not to panic. Audio, video, and pictures have been around a long time, just not on the intranet. I know it seems like a lot: we’re just getting used to “wikis and blogs,” now there’s video. Start small and see how it feels before taking the plunge. Otherwise, your adventure will be all licensing and servers, but no video.
The Gartner Group is usually an excellent source of statistics, industry trends, and other hard-to-find research, but I’m not getting the urgency or danger here. Certainly, the use of video online has skyrocketed, partially because of the prevalence of broader bandwidth, better compression algorithms, and faster hardware. Mostly, though, video is more popular on the web because there’s something to watch. As we used to say before the .com collapse, “Content is king.” Employees are going to YouTube and Hulu to relax and enjoy themselves; they’re not checking out the CEO’s video blog in droves. Entertainment is different from office life, at least for most people. A tedious office video is equally boring in the conference room or on a desktop.
Video can be a great medium to demonstrate physical procedures, impart wisdom from an expert, or give a live view of an event or place. In the 60 or so years that video has been widely available, it has both entertained and enlightened us. Putting it on a computer isn’t something that organizations have to prepare for any differently than they had to prepare for voicemail, email, faxes, and the like. The most important question is not “What will customers demand,” or “What will our employees put up with,” but “What business need does video fill?” From that starting point, we can examine what to do about it and look back at the recently trod paths of websites and collaboration tools for some guidelines.
In order to put this technology in the hands of employees, we need to do a little scratchpad work on procedure. It’s a good idea to figure out what video is for in an organization before letting everyone loose with a camera and upload space. Every other method of business communication is governed by policy; untested ones like video should have some broad guidelines. I don’t mean to suggest locking the general counsel in a room until there’s a 400-page ironclad policy, but the same rules for trade secrets, appropriate language, etc. need to be in place for video. Next, let people try it. Employees can cover meetings, construction progress, depositions, or whatever they think makes sense. Let them record with cell phones, Nanos, videocameras, or anything else on hand. Give them space to upload within the intranet and take stock. Now that people have gotten their feet wet with video, the organization should have some ideas on further policies and directions.
Once the organization knows where they’re going with video, it’s time to look for technology. Any sophisticated video-handling system licensed within the next twelve months will probably be replaced by something five times as good and a third as expensive by 2013. Organizations must determine how immediate the need for video communication is. If they can wait, they should do so. There are plenty of content management technologies out there that handle video to a degree, but we’re a long way from a SharePoint-style video intranet server, at least for most groups.
What’s most important is not to panic. Audio, video, and pictures have been around a long time, just not on the intranet. I know it seems like a lot: we’re just getting used to “wikis and blogs,” now there’s video. Start small and see how it feels before taking the plunge. Otherwise, your adventure will be all licensing and servers, but no video.
Sunday, January 3, 2010
Training in a Crisis
We produced a crisis communications e-learning course for a customer last fall, and their approach was very interesting. According to their policy, in a crisis, every single communicator is responsible for managing communications in a crisis. If the usual responder isn't available, the nearest communicator is called into action. I love this approach, and I think it should be applied more often to core duties, especially in a large organization. The communicators I spoke to seemed proud to serve and willing to be called upon.
For any organization, employees should know what to do in a crisis. Whether it's a building fire, stolen property, website hack or some other unfortunate incident, there should be a policy and procedures document governing employee actions. Most of the time the organization stops there. The employee gets a copy of the document, maybe reads it, maybe understands it, then signs a piece of paper. Is this good enough, considering you may be asking that person to step into a very demanding role?
Use the policy document to serve as the basis for a crisis course. Depending on the size and complexity of the organization, there may be a whole curriculum covering communication, management, finding alternate worksites, first aid, conflict resolution, even self-defense. While many of these topics would benefit from a seminar or a simulation, they can all start with an e-learning course. That first course in the curriculum can give an overview of the subject, add in some vocabulary and procedures, and form a common basis of understanding among the employees. Add in some self-check questions and scenarios, and you've really got something. E-learning is always available, so include it with your onboarding materials for new employees, and be sure to announce course updates.
As follow-up, update the course when the policy document is updated. Oh, yeah, any risk management professional will tell you to review your emergency policies and procedures regularly, so schedule that.
For any organization, employees should know what to do in a crisis. Whether it's a building fire, stolen property, website hack or some other unfortunate incident, there should be a policy and procedures document governing employee actions. Most of the time the organization stops there. The employee gets a copy of the document, maybe reads it, maybe understands it, then signs a piece of paper. Is this good enough, considering you may be asking that person to step into a very demanding role?
Use the policy document to serve as the basis for a crisis course. Depending on the size and complexity of the organization, there may be a whole curriculum covering communication, management, finding alternate worksites, first aid, conflict resolution, even self-defense. While many of these topics would benefit from a seminar or a simulation, they can all start with an e-learning course. That first course in the curriculum can give an overview of the subject, add in some vocabulary and procedures, and form a common basis of understanding among the employees. Add in some self-check questions and scenarios, and you've really got something. E-learning is always available, so include it with your onboarding materials for new employees, and be sure to announce course updates.
As follow-up, update the course when the policy document is updated. Oh, yeah, any risk management professional will tell you to review your emergency policies and procedures regularly, so schedule that.
Subscribe to:
Posts (Atom)