In my 10 years as a CIO, I've strongly believed that productivity is optimized when everyone meets and works in close physical proximity. That way, teams get the benefit of being able to brainstorm in person, respond to urgent issues as a group and build trust among one another. I didn't think telecommuting was right for IT departments.
This article is my official about-face on telecommuting and flexible work arrangements. A variety of factors have changed my opinion on the best way to get work done.
First, the travel required to bring employees together in an office has become burdensome and expensive. Metropolitan areas are clogged with traffic, and gas prices are causing financial hardship. On average, I spend 1.5 hours in my car each day commuting a total of 20 miles to and from my office. Many of my staff members spend as much as four hours a day commuting. That's almost the equivalent to half their workday. At the same time, people's awareness of the environmental impact of those long commutes is on the rise. If working flexible hours reduces an employee's commute by an hour or more each way, productivity and staff satisfaction will rise.
What's more, face-to-face meetings that take weeks to schedule no longer support the pace of IT change and the level of service demands. Finding all the talented employees I need on staff within a reasonable commuting distance is also challenging. And for some jobs, the interruptions an office brings may actually reduce employee productivity. Blue Cross Blue Shield of Massachusetts recently piloted a flexible work arrangement and found that productivity for 200 staffers working from home rose 20 percent; only two participants had performance issues.
Given these facts, I believe IT leaders are obligated to explore the entire spectrum of flexible work arrangements including telecommuting, homesourcing (a combination of outsourcing and telecommuting), virtual teams, and replacing travel with teleconferencing. Staffing an office from 8 a.m. to 5 p.m. doesn't make sense if it requires employees to spend hours in traffic.
Telecommuting's benefits have long been proven. In the 1970s, Paul Gray, a now retired Claremont College professor of information science, studied the effectiveness of telecommuting among government workers in London. His studies, chronicled in "Telecommuting-Transportation Tradeoffs: Options for Tomorrow" (Wiley 1975), showed that once co-workers have an initial in-person meeting, they're "able to work in dispersed mode with no loss of effectiveness," he wrote.
In 2008, we have many technologies for communication: e-mail, instant messaging, teleconferencing, wikis, online meetings, secure file transfer, blogs and virtual private networks (VPNs). Internet connections are fast, reliable and cheap. I pay US$40 a month for a 20Mbit/sec. fiber connection in my basement. These technologies are making flexible work arrangements possible and productive.
Of course, there are issues to overcome.
A home office needs infrastructure support--networks, desktops and a connection to the corporate phone system. Figuring out the best way to service hundreds of remote locations requires planning and pilots--extra work for IT departments already stretched thin. However, the technology required to support home offices and remote workers doesn't need to be complicated. Videoconferencing isn't always necessary, for example. Phone calls and Web-based presentation tools often work better.
Managing employees who work remotely also presents unique challenges, such as ensuring they maintain their productivity and continue to communicate effectively with management, staff and customers while offsite.
Equity is another problem. Some staffers, such as those doing direct desktop service or training, need to be onsite. They may resent their coworkers who can work from home. You need to find ways to offer some flexibility to staff who need to be in the office, such as letting them work four 10-hour days.
Then there are the security and privacy questions, which loom especially large for me since my IT organization is part of a large healthcare provider, Beth Israel Deaconess Medical Center in Boston, Mass. If employees are to access sensitive health data from their homes, I need to investigate biometric devices, re-examine application time-outs, strengthen surveillance of audit logs and ensure end-to-end security from data center to the home.
I've dealt with all of these issues over the past four months, as I've piloted flexible work arrangements inside my IT organization. I've studied the technologies, policies and business processes required to manage technology professionals engaging in flexible work arrangements. I even spent a week telecommuting, from November 26 through 30, 2007, just to see what it was like. In this article, you'll find my evaluation of a variety of technology tools-- blogs, wikis, and instant messaging and more--that you can use to support teleworkers. You'll also read my description of common management and infrastructure challenges you may encounter--along with ways to overcome them. I hope my experience implementing flexible work arrangements will give you the information you need to establish fair and effective policies in your IT organization.
Flexible Work Policies
Over the past three months, Beth Israel Deaconess Medical Center has explored the policies needed to support remote work arrangements for our call center employees, medical record coders and our desktop engineering team. We determined these three groups of employees were ideal for the pilot for a variety of reasons: JetBlue previously demonstrated with its customer service staff that call center employees can successfully work from home. We chose medical record coders because they're difficult to find in Boston and because their work doesn't have to be done in a traditional office space as long as they have access to patient medical records. Finally, the IS engineers who design Beth Israel Deaconess Medical Center's infrastructure benefit from a quiet environment that's conducive to the concentration required for their work.
The goal of the flexible work arrangement we're piloting is threefold: to enhance productivity and cost savings, improve employee recruitment and retention, and to more efficiently use existing office space. We chose employees for the pilot on the basis of whether letting them participate in a flexible work arrangement would advance any of those three goals.
We modeled our flexible work policy on one established by Blue Cross Blue Shield of Massachusetts, which has been an early leader in homesourcing. Blue Cross Blue Shield of Massachusetts created a flexible work arrangement worksheet that's designed to help managers evaluate if an employee's job tasks can be performed remotely. The worksheet also establishes an agreement between an employee and manager about the employee's job performance and productivity while working remotely. We are in the process of customizing our own flexible work arrangement worksheet based on Blue Cross Blue Shield of Massachusetts's.
Creating a policy that is flexible enough to support many employee roles while specific enough to identify which employees can work remotely and which cannot is challenging. Blue Cross's policy provides employees and managers with a framework for discussing the possibility of flexible work that sets mutual expectations, identifies the employee's responsibilities and codifies criteria for success. This framework has enabled me to have open discussions with pilot employees interested in flexible work arrangements and to maintain a sense of equity since everyone understands what can and cannot be done. Extending this framework to the entire population at Beth Israel Deaconess is still a work in progress. The next step is a series of focus groups scheduled for April and May 2008 with over 40 managers from throughout the medical center who will document their unique needs and the challenges facing their departments with respect to flexible work arrangements.
With a pilot policy in place, we can think about the infrastructure required to support flexible work arrangements.
Enabling an employee to work from a remote location is like extending the corporate office to hundreds of new sites. Seamless telephone transfers to the home office, desktop support, network connectivity and security support are just a few of the services IT departments will have to provide. Furnishing employees with all the technology necessary for them to work from a home office is key to implementing a successful telecommuting or flexible work policy. You can't expect employees to maintain the same level of productivity and service that they do in the office while at home if they lack access to the files and applications they need to do their jobs and if they lack technologies such as instant messaging that ease communication and collaboration.
At the same time, security issues cannot be overstated, especially in healthcare. We do not want connected to our network a home computer running Windows 98 Second Edition that's infected with a keystroke logger. So we have to provide computers to remote workers. We decided to outfit them with thin client computing devices from HP, which provide a low-cost, self-contained computer without any moving parts--the hard drive has been replaced with Flash RAM. The devices, which cost about $300 apiece, do not allow users to do any configuration or install any software. They plug into a network just as a phone plugs into a wall. If a device fails, we issue another one. Our thin clients run only a Web browser and Citrix for applications such as Outlook and those few clinical systems that are not Web-based, such as our transplant system, cardiology systems and medical-record coding systems, so users can access all files and financial and clinical information via our intranet. At present we've deployed a dozen of these thin client devices, but we plan to deploy more in the future as we expand our flexible work arrangements.
To make sure that internal and external customers can easily get in touch with employees working from home, we worked with our telecom provider, Avaya, to forward calls from teleworkers' offices to their home phones.
Being a remote employee in 2008 requires full integration with the workflow of the company and access to all those applications and files that a person onsite would have.
One way to extend the office into a remote location is to extend the network. The use of secure socket layer (SSL) virtual private networks (VPNs), such as Juniper's SSLVPN, works extremely well and across platforms (Windows, Mac and Linux.) Our SSLVPN examines the remote computer, ensures the appropriate operating system patches and antivirus software are up to date, then enables the remote user to join our network via the public Internet. Our SSLVPN connects inside our firewall, but we have a secondary internal firewall in place so that SSLVPN traffic is further examined by our network intrusion detection and prevention systems before it gains access to our most secure resources.
Finally, remote collaborators need to be able to share files, no matter what the size. Juniper's SSLVPN enables corporate employees to access home and shared directories remotely. To support file sharing among collaborators in different companies, a secure file transfer appliance, such as that offered by Accellion, works very well. This appliance supports file transfers up to 2 gigabytes using Web technologies to place the file on a secure website and then e-mailing a user name and password to the collaborators who need to access it.
Remote desktop applications, such as the remote desktop functionality built into the Juniper SSLVPN, also enable remote users to access their office desktops and effectively use all the tools on their office computer from their home workstation.
In addition to these standard remote access methods, we may need new applications to support remote workflows. For example, our medical records coders need access to the paper medical record. Since shipping thousands of sheets of paper is a logistical nightmare and a security risk, we elected to digitize all our in-patient paper records and make them available securely via the Web. Specifically, we use EMC's Captiva software to scan each portion of the medical record, render it as a PDF, then upload it to a secure Web application for remote access.
In the next section, I discuss in detail specific communication, collaboration and presentation sharing tools that are both useful and necessary in supporting remote workers.
E-mail, ListServs and Instant Messaging
The most basic way to communicate remotely is via text sent among collaborators. There are many ways to do this synchronously and asynchronously.
For me, asynchronous text communication works best since I'm interacting with 40,000 Harvard and CareGroup customers 12 hours a day (CareGroup runs Beth Israel Deaconess Medical Center, and the Harvard Medical School teaches at Beth Israel). And since I find it challenging to speak in a meeting, listen attentively, keep my train of thought intact and text at the same time, e-mail is my preferred method of asynchronous communication. It has mature standards, cross-platform support and is interoperable across corporate networks, so there are few barriers to using it among collaborators. I live by BlackBerry, answering 700 e-mails a day using my 8320 over GSM/GPRS/EDGE and Wifi. I don't find the Treo, iPhone or any of the Windows mobile devices as efficient as the BlackBerry for high-volume e-mail management. (For a review of different Smartphones see, The Business-Savvy Smartphone Review.)
I use Entourage 2008 on OS X Leopard, and I am quite pleased with its functionality and stability. I use Outlook Web Access 2003 in Firefox, but am frustrated by its lack of a Gmail-like search feature. Finally, I have a Gmail account for family and personal correspondence, which works well with any browser on any operating system.
I also use listservs, both moderated and unmoderated, to send communication among large groups of collaborators. We've used listservs in IT for strategic planning, to discuss points that came up in in-person committee meetings, and to develop documentation as a group. Whenever I sign up for listservs, I always configure my account for "digest mode" so I get one e-mail per day summarizing all of the discussion threads. The chatter on listservs can be very annoying, so digest mode helps me manage the amount of e-mail I receive from the list.
As for synchronous messaging, many companies have developed an instant messaging (IM) culture for communications. Given its adoption by younger workers, IM is a major communication medium that modern CIOs cannot ignore. I certainly can't ignore it: My 14-year-old daughter and her friends use IM while reading, surfing the Web and talking on the phone.
When I started this pilot, I hadn't used IM much so I took a deep dive into the technology. I opened accounts with AOL Instant Messenger (AIM), GoogleTalk, MSN Messenger, Yahoo Messenger, Skype and even BlackBerry Messenger for real-time communication with my staff.
To me, effective chat needs to work across all platforms, so I tested all of these platforms with an Ubunu Linux laptop, a Macbook and a Dell OptiPlex 745 desktop running Windows XP. For Linux, I used the Pidgin open-source instant messaging application and the Skype client. For the Mac, I used iChat plus specific clients from MSN, Yahoo and Skype. For the Windows machine, I downloaded clients from AOL, MSN, Yahoo and Skype. For GoogleTalk, I used the Google Web client, which is part of Gmail, by using a Firefox browser on all three computers. I also tried meebo.com, a web-based IM tool that works with all IM providers.
My first impression is that IM can be an effective communication tool for real-time, emergent situations, such as a server or application outage, for quick questions (when is the meeting?), and for brainstorming as a group. But my frustration with it is that I must use the same service as the person whom I want to message. Since my collaborators have accounts on different IM platforms, I must use all of them. Though some clients enable me to log in to multiple IM services simultaneously, I still need to create and remember the credentials for the accounts on all these services. There are emerging technologies such as OpenID that will simplify account management across IM providers in the future.
All of the IM services I tried support text. Some of these services support audio and video chat, but just about every audio/video experience I had was not cross-platform and did not work well on corporate networks, since many ports used by IM clients are blocked by firewalls and corporate intrusion prevention systems. Specifically, here's what I found:
-- AOL Instant Messaging (AIM). The Windows AIM client supports text, audio and video. Same with Mac iChat. Linux Pidgin supports text only. All use the proprietary OSCAR protocol. AIM audio worked fine between a Windows machine and my Mac. I could not get AIM video to work on my corporate networks. Why? Take a look at the instructions on AOL's website:
If either you, or the person you want to Video IM with are behind a firewall and are having problems getting Video IM to operate, work with your Internet Service Provider, your company's system administrator or modify your firewall software yourself to open ports 1024 through 5000."
It's highly unlikely that a corporate networking group is going to create a permissive firewall for ports 1024-5000 for AOL video support.
-- MSN. The Windows Messaging client supports text, audio and video. The Mac and Linux aMSN open-source applications support text and video. All use the proprietary MSNP protocol. I encountered the same problems with video on MSN as I did with AOL.
-- Google Talk. Google uses a hosted implementation of the industry standard Extensible Messaging and Presence Protocol (XMPP) and the extended Jingle protocol. It works with any standards-based chat client such as Trillian for Windows, iChat for Mac and Pidgin for Linux. It supports audio via a downloadable Google talk client for Windows and works with iChat for the Mac. No audio support is available for Linux.
-- Yahoo. The Windows Yahoo client supports text, audio and video. The Yahoo client for Macs supports text and video. Linux Pidgin only supports text. All use the proprietary Yahoo! Messenger Protocol. I found the same issues with video on Yahoo as I did with AOL and MSN.
-- Skype. The Windows and Mac Skype clients support text, audio and video. The Skype client for Linux only supports text and audio. All use the proprietary Skype protocol. Interestingly, video worked well, with no firewall issues between Windows and Mac Skype clients. Sound quality was irregular given the many uncontrollable quality of service issues on the Internet connection between my laptop, the Skype servers and my collaborators.
There are also several free, open-source IM clients available that support just about all IM providers:
-- Adium is an instant messaging application for Mac OS X, released under the GNU general public license, which makes it available to developers at no cost. With Adium, you can connect to any number of messaging accounts on any combination of supported messaging services and then chat using those services, which include AIM, MSN, Google Talk, Yahoo, Bonjour and MySpace IM.
-- Trillian Astra is the upcoming version of the Trillian instant messenger. It supports AIM, MSN, Google Talk, Yahoo, Bonjour and MySpace IM for Windows, Macs, and mobile platforms such as the iPhone.
Finally, there are Web-based services such as meebo, which do not require any software other than a Web-browser to connect to many IM service providers.
After trying all these services, my conclusion is that text works very well across all platforms as long as your collaborators are on the same IM service. If I have collaborators on Yahoo, MSN, AOL and Google, I need to establish accounts on every one of these services, install the clients for these services and check multiple different applications to determine if my collaborators are online. Audio is problematic across platforms and has very uneven quality. The poor sound quality is a function of many bandwidth bottlenecks from desktop to desktop via the Internet and the IM service provider. Even if video was available across platforms, it will still have the firewall issues I described above.
In sum, I recommend using e-mail and listservs for asynchronous communication and text-only IM for synchronous communication. If you need audio and/or video, stick with teleconferencing technologies, which I describe next.
Audio and Video Teleconferencing
I'm a fan of audio teleconferencing. It works well, is low cost, and the technology is mature. I do not need an engineer to set up a teleconference, and I can use any mobile or landline phone I wish.
Using a local phone system to initiate a multiparty conversation works well for a small number of participants, generally about three. For a large group, numerous services are available such as Reservationless conferencing from Intercall or Ready Conference. "Free" conference calling (it's a toll call for participants) is available from freeconference.com and instantconference.com.
Video conferencing is a bit more complicated. I evaluated the following technologies:
-- Windows: Polycom PVX software, using H323 and SIP teleconferencing protocols over IP.
-- Mac: Xmeeting, an open-source H323 and SIP teleconferencing tool, iChat via H264.
-- Ubuntu Linux
: Ekiga, an open-source H323 and SIP teleconferencing tool.
My first observation about video conferencing systems is that poor video can be tolerated, but audio must be nearly perfect for the technology to be useful. Polycom has figured that out and seems to preferentially use available bandwidth to ensure the quality of the audio.
I used the Windows-based Polycom PVX software to connect via H323 to a Mac running Xmeeting. It worked perfectly, offering "good enough" video from my desktop Logitech Fusion camera and headset microphone. The Mac side running Xmeeting provided barely passable audio and passable video. Although not an H323 solution--and therefore not interoperable with existing corporate teleconferencing systems--iChat via Bonjour using the H264 protocol provides much higher quality audio and video on a Mac than the Xmeeting H323 approach. IP-based teleconferencing (as opposed to ISDN teleconferencing, which I'll touch on momentarily) worked on these machines without any configuration hassles or incompatibilities.
The positive aspects of H323 are that the standards are mature; I did not encounter any firewall issues; and cross-platform communication worked among all the computers and operating systems I own. The downside is that video takes a lot of bandwidth, and it can take teams of engineers to get H320 and H323 working.
My experience with H320 ISDN teleconferencing, which requires a series of digital telephone lines, is that it can be quite finicky. Typically when I do ISDN teleconferencing to existing corporate ISDN-based teleconferencing systems, the engineers on both sides of the call need 30 minutes to ensure equipment compatibility and get the connection working. I've had many ISDN teleconferencing presentations fail completely, be interrupted mid-presentation and have variable quality during the course of the call.
My second experiment involved connecting a Mac running Xmeeting with an Ubuntu Linux laptop running Ekiga. Although bandwidth should have been sufficient, I found that the Linux laptop did not perform the audio or video tasks well. This could have been because the laptop has low-powered graphics hardware and only a 1.06 Ghz core solo processor. Many other folks I've spoken with have found that Linux does not seem to be an optimal platform for high-end, real-time audio and video applications at this time.
The bottom line from these experiments is that PolyCom seems to really have a business-quality desktop teleconferencing solution that enables me to connect with collaborators using H323 protocols. Xmeeting came in second place with its barely passable audio quality and passable video. Ekiga was not usable for business purposes, although it may suffice for casual chat. I recommend reserving video for just those situations that require face-to-face contact to build relationships, such as an initial kick-off meeting for a project or the first-time meeting with an important collaborator. Instead, use audio teleconferencing and the Web-based presentation sharing tools I describe in the next section of this story to facilitate conference calls.
Collaboration Tools: Blogs, Wikis and other group publishing systems; Forums, Chats, Social Networking Tools; Presentation Sharing/Remote Desktop Tools
I tried a host of collaboration tools--including blogs, wikis and online forums--that have potential usefulness for virtual teams. The beauty of these tools is that you don't need to be in an office to use them. All you need is a Web browser and Internet connection.
A blog is a Web-based content management system specifically designed for creating and maintaining short articles. Although blogging is not a real-time collaboration tool, it is a remarkable way to spread information. Each day, I write 1000 words on my blog, GeekDoctor, for 3,000 daily readers. Although I don't use my blog specifically as a tool to support flexible work arrangements, it is a remarkable way to stay in touch with all my staff and customers. Instead of writing a broadcast e-mail or posting to a listserv, I can describe all the details of a strategic initiative in one structured document that everyone can read. I have found that blogging has replaced many meetings, phone calls, newsletters, and e-mails because every stakeholder, onsite or working remotely, is on the same page. As an external relations tool for communicating information, proposing ideas or marketing concepts, it works extremely well. Blogger, WordPress and TypePad are leading blogging sites.
A wiki is software that allows users to create, edit and link webpages easily. Wikis are often used to create collaborative websites and to power community websites. They are being installed by businesses to provide affordable knowledge management and are extremely useful for a community of authors to create shared documentation. At Harvard Medical School, the information technology department uses the open-source software Twiki as an enterprise wiki infrastructure that supports over 300 knowledge repositories authored by departments, professors, IT staff and clinicians. Having knowledge about commonly encountered problems, policies, reference materials and contact information on a wiki is a real asset to remote workers: It gives them access to institutional knowledge from anywhere in the world.
A forum is a threaded discussion with multiple participants. It is not real-time. Participants can read and respond to entries any time. At Harvard, we created our own threaded discussion forums that a diverse group of geographically dispersed participants use for strategic-planning activities. Forums are good for ongoing discussions between large groups of collaborators who want to engage in a dialogue asynchronously. The downside of forums is that they can take a lot of time to read through. As such, they have not been that popular in general. However, Harvard Medical School has used forums to support its strategic-planning initiatives and to ensure that multiple stakeholders can comment on proposed initiatives. My IT group has not used forums specifically to support remote workers in our department, but collaborators have used forums to continue their dialogues after hours. Consequently, the tool makes sense for supporting flexible work arrangements.
Chat is a real-time, synchronous discussion group with many participants that typically requires specialized chat software. I have not found a business use for chat rooms. It seems that chat has been largely replaced by instant messaging. For example, Google's Gmail includes IM with the ability to invite multiple people to a chat. However, all must be online to participate in the discussion. Forums can be more convenient than chat because the parties involved in the discussion don't have to be online at the same time. We've used multiple party IM to bring together a virtual group of IT workers spread across many locations to respond to problems, but we've not used "old fashioned" client-based Internet Relay Chat to support flexible work arrangements.
Other types of group document collaboration tools include Gobby, which enables multiple authors to edit a document in real-time. Document repositories such as Microsoft Sharepoint, Documentum and home built intranet portals support group document sharing. I've used Sharepoint as a document repository to coordinate the nation's healthcare data standardization process at HITSP. Sharepoint has become an important document repository for my teams, both onsite and offsite, to ensure we all have access to working documents, project plans and budgets.
Social Networking sites such as Facebook, LinkedIn, Plaxo and MySpace encourage users to interact through chat, messaging, e-mail, video, voice chat, file sharing, blogging, discussion groups and more. To test the value of these services for collaboration, I established accounts with Facebook, LinkedIn, Plaxo and Second Life. Although I initially did not see the business value in Facebook, it has become an increasingly important way for ad hoc groups to form, exchange ideas and launch innovative applications. Recently, the CEO of Beth Israel Deaconess Medical Center created a fundraising site using Facebook's Causes application. Hundreds have joined, and contributions are flowing. At this point, we're using Facebook for collaboration with external customers and are relying more on Sharepoint for internal collaboration, though we could use Facebook to create ad hoc work groups to help remote employees stay in touch and refine ideas. LinkedIn and Plaxo have been primarily a way for individuals to maintain contact with me without requiring a specific corporate affiliation. Many high-tech employees transition every few years, but social networking sites enable them to stay connected since their networking identity is not tied to a corporation. We've found LinkedIn and Plaxo are more useful for contacting external collaborators than internal groups. Our e-mail, listserv and Sharepoint applications are the choice of our remote workers.
Presentation sharing tools seem to be the most promising for supporting remote collaboration. This class of tools enables a presenter to deliver content over the Web. They may include audio, question-and-answer features, a whiteboard and survey capabilities. I evaluated WebEx, Adobe Connect, Elluminate and GotoMeeting.
-- WebEx has the most features. It supports the entire collaboration workflow. You can use it to schedule conferences and send e-mail notifications to attendees. It also integrates with Outlook. All of WebEx's functions except video teleconferencing worked on all operating systems: On Linux, video teleconferencing is view-only, meaning you can view others, but they can't see you. It costs $375.00 per month for up to 15 users.
-- Adobe Connect. Formerly known as Macromedia Breeze, Adobe Connect worked well under Windows, but had stability issues (it locked up) under Macs in my tests with other collaborators. Video teleconferencing was view-only in Linux. The cost is $375.00 per month for up to five users.
-- Elluminate is Java-based and includes a free basic service, Vroom, which supports whiteboarding, remote presentation and group instant messaging. It has a very intuitive user interface but lacks WebEx's scheduling and automated conference-calling features. The full-featured version is $180.00 per month for five users. As with the other applications, video teleconferencing is view-only in Linux.
-- GotoMeeting. This Web-based product only works on Windows machines and Macs. Priced at just $39.00 per month for 15 users, GotoMeeting includes an integrated voice conference service in which participants are charged their standard long-distance rate for calling a toll-based number.
Remote presentation tools enable me to assemble virtual teams, convey ideas, seek feedback and avoid commuting. They are a truly powerful tool. I did not find the lack of video teleconferencing support across all platforms to be a significant problem; I believe the need for a 'talking head' visual is limited. I prefer WebEx for its workflow support. As for the other communication and collaboration tools I evaluated, I'll continue to use blogs to share ideas, wikis to document organizational knowledge and Facebook for collaboration with external collaborators, as well as e-mail, listservs and forums.
To evaluate the implications of flexible work arrangements on productivity, employee satisfaction and IT staff providing remote infrastructure support, we ran two pilots: one with our desktop engineering team and one with our medical record coding team.
One of our desktop engineers worked from home four days a week and in the office one day a week. This particular engineer is responsible for developing the desktop images used on Beth Israel Deaconess Medical Center's 8,000 managed workstations. His work demands a quiet, controlled environment where he can concentrate on complex programming, configuration and testing activities. From a management perspective, his deliverables are deployable software images for specific configurations of PCs that are due on specific dates. During our pilot, he used e-mail, IM and teleconferencing to stay in touch with management and customers. He met all of his deadlines, and no one complained about his availability, work habits or responsiveness.
For medical record coders, one employee worked from her home in California and the other three worked from their homes in Massachusetts. The Massachusetts-based coders came into the office on average twice a week for work distribution or meetings. From home, they did all the work they would otherwise do in the office: They reviewed and applied diagnosis and procedure codes on path reports, operative reports, lab reports and notes in our ambulatory medical record. They used e-mail very frequently to communicate with their managers and to clarify with clinicians issues in the medical record. During the pilot, they coded 10 percent more records than they typically code when working in an office.
Coders are challenging to hire in Boston due to the large number of hospitals competing for a small number of qualified employees, so flexible work arrangements enable us to hire without geographic restrictions. Given the IT job market and the difficulty of recruiting replacements, the benefit of such flexibility cannot be overstated when you have a seasoned employee who knows your systems well. We were able to retain a coder who moved and we included her in our pilot. For medical record coders, the pilot program was very successful. In the spring we will expand the program to in-patient coding.
We observed many other benefits. The flexible work arrangements improved employees' quality of life. They're not stressed or tired from commuting so much, and they're saving money on parking and gas. The flexible work arrangements have also freed up office space. In addition to these benefits we observed, we learned some important lessons about implementing flexible work arrangements and managing remote employees.
Flexible work arrangements work best for highly responsible, productive employees with good track records who don't mind working alone. And employees' personal preferences play a large role in the success of such arrangements. One coder who lives by herself said she felt distracted at home and missed the social interaction with coworkers. Another coder who also lives alone loved working at home since she experienced no interruptions and got more done.
When you begin offering flexible work arrangements, it creates the expectation that everyone will be able to work from home. Clearly, this is not the case. Some employees' jobs may not be conducive to working outside the office. Some employees may not be trusted to work from home. Our answer to these issues is to use a flexible work arrangement framework, such as the one we adapted from Blue Cross Blue Shield of Massachusetts, as the basis for discussion. Employees can understand objectively how a flexible work arrangement may or may not work for them. If a flexible work arrangement, once started, does not work out, it's easy to refer back to the framework document to understand how expectations were not met and to justify the suspension of the agreement. For those who cannot do their jobs remotely but who require flexibility due to long commutes or family demands, you can let them work different schedules, such as 10 a.m. to 6 p.m. or four 10 hour days. That way, more people can participate in flexible work arrangements, which eliminates much of the friction among staff in different roles.
Flexible work arrangements will also be hard to extend to new employees who don't know the people, processes and policies well enough to work effectively on their own. I recommend waiting at least six months to let new employees work from home.
One thing my staff and I learned is that we're not as likely to call someone at home because we feel that we are invading a private space. If we create a sense of connectedness that goes beyond a geographic location, we create equivalence between home and office. If you need to reach a person by voice, you dial a number, not knowing or caring if they are onsite or remote. Cell phones would work, but even they have a stigma of urgency that can impede a casual conversation. In our case, by connecting our office PBX system to a phone in the home office, we create five-digit dialing that eliminates any hesitation to call a colleague who may be working remotely.
Flexible work arrangements also challenge traditional command-and-control methods of management: It's hard to manage people you can't see. You can't walk into their office or cube to ask them a question or give them a new assignment. By changing the culture to make e-mail, phone calls, IM, blogging, wikis, and WebEx the means of communication and management control, the need to walk into a cubicle lessens. On the employee side, regular status reports to the manager ensure that there are no surprises about the employee's performance.
Of all the lessons learned, the most important is that employee and manager create a written plan for the flexible work arrangement and describe specific expectations for performance. Both employee and manager need to constantly communicate and be comfortable with the basic technologies I outlined here: e-mail, IM, phone conferencing and remote presentation.
Flexible work arrangements are not only possible for me and my staff, they are necessary in 2008.
Some technologies are ready to support telecommuting. Ideally the technology should run on any operating system and with any browser, be compatible with firewalls, be usable on a wide variety of bandwidths and require minimal support. The technologies I have chosen to keep using after my three months of investigation are:
1. E-mail via BlackBerry as my principal means of asynchronous communication.
2. IM for interaction with some companies and workgroups. I have elected to use meebo.com as a free, cross-platform, web-based client for IM text exchange. Meebo supports all the major IM service providers.
3. Video teleconferencing over IP using a Polycom H323 appliance. This resolves any issues with client software running on my Windows computers that aren't Windows-based.
4. Blogging via Blogger.com for external communications.
5. Twiki for creating shared documentation wikis.
6. Accellion for Secure file transfer.
7. WebEx plus audio teleconferencing for virtual meetings and presentations. We use WebEx's conference calling, and Ready Conference and Intercall for ad hoc conference bridges.
8. Juniper for SSLVPN, including access to file shares and remote desktop control.
9. Citrix for access to client/server applications needed remotely.
10. For infrastructure I use a Macbook Air, which can run all these tools.
Although these 10 technologies are empowering, it's the policy changes and management framework supporting flexible work arrangements that are most important. We learned that creating a flexible work arrangement template and encouraging a cultural change in favor of remote and asynchronous communications (over in-person meetings) were key to our successful pilot of flexible work arrangements.
Now that we've completed the initial technology and policy evaluation, we'll expand our pilots over the next few months. I'm optimistic that we'll meet all three goals for the project: increased productivity and lower costs, improved employee recruitment and retention and better use of space. I'll report back on our progress. In the meantime, I'd love to hear about your experience with flexible work arrangements.
John Halamka is the CIO of Beth Israel Deaconess Medical Center and Harvard Medical School. He frequently contributes to CIO.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.