Copyright © Snyders.US. All rights reserved.
Responding to budget pressures by restricting travel for in-person meetings is a fool-proof recipe for guaranteeing the failure of a distributed development effort.
John R. Snyder
On July 13, 2013 the last telegram was sent. India's state-owned telecom company ended the last remaining telegraph service on earth1. From those humble tap-tap origins, telecommunications have advanced to e-mail, instant messaging, smartphones, and such--our meetings are held virtually. Traveling to the office is a thing of the past. But wait: Yahoo's Marissa Mayer recently ended the company's very popular work-from-home policy with the statement "people are more productive when they're alone...but they're more collaborative and innovative when they're together2."
Yahoo's iconoclastic policy has been disparaged by media types and energized discussions about work from home. Mayer has since clarified that the change was never a statement on telecommuting; rather, necessary to ameliorate the company's culture. And hardly a radical concept: looking co-workers in the eye will influence a position. Although it's difficult to measure and compare across projects, academic evidence typically supports conclusions that colocated teams enhance outcomes with fewer resources3. Our current technologies are just no substitute for a business meeting over lunch.
But project managers, software developers and support staff in some situations rarely, if ever, meet their project's primary stakeholders or even the project team face-to-face. A large number of projects are guided though the entire development lifecycle entirely by conference call and e-mail. The project team never meets in-person; they are voices on a telephone. Considering those communication barriers, it's amazing they are able to deliver a high percentage of projects on-time and under budget. They've figured-out how to function in this especial experiment of the virtual office. But remotely located, virtual teaming for IT projects doesn’t have much of a track record over the test of time--so it's possible we are experientially learning it's not the best project architecture.
Recent press seems to bear-out that something is amiss with IT projects4. Could one of the contributing factors be "death by e-mail"? That pernicious phenomenon occurs when a project is setup to conduct business by e-mail, but that modality becomes overwhelming and ineffective. An informal, unscientific poll of managers-directors in a software development organization reveals that many receive an average of 100-200 e-mails each day, some receive around 400. One high-level director said she didn't know how many e-mails she received in one day, as she had "over 1,000 unread messages right now" in her Outlook in-box.
It's easy to dismiss suggestions of e-mail overload as isolated in-box management or an individual's messy-desk syndrome. But consider the knowledge-document management aspect of running a project with even well-organized e-mail in-boxes. The project's artifact-data repository (for example, SharePoint) is in the hub, with project team members distributed around the endpoints of many spokes. But rather than use the repository to share information, project members e-mail attachments to each other. The information in these inboxes at each "spoke" is distributed; knowledge management becomes impossible, communications segmented and laborious.
There are recognizable attributes and side-effects of running a project by e-mail summarized as follows:
1. On conference calls, you hear the phrase "can you send that to me" often.
2. The pretext: "I didn't get the e-mail" is acceptable.
3. Filenames use dates, and the term "FINAL" attempting artifact version control (is anything "final" today?).
4. Each inbox contains that user's record of truth--which is probably different than the inboxes for the rest of the team; some of the team; the version you have.
5. As team members come and go, their record of the project's history is difficult to recover from server archives, so that information is lost.
6. Endless meetings are necessary to communicate status; meetings with no specific actions, objectives, or goals outside of communicating status and events.
7. Unless team members attend communication meetings--they feel "out of the loop."
An alternative to the death by e-mail paradigm is to centralize all project activities-communications around a "town center" hub of information. The repository becomes a (literally) center of knowledge management, program activities-communications and an attractive-efficient alternative to e-mailing attachments.
The opposites of death by e-mail in a project are described that:
1. Rarely does anyone ask for e-mailed correspondence-attachments, as the artifacts-data are available self-service anytime.
2. "I didn't get the e-mail" becomes unacceptable as "the dog ate my homework" when all project information is available on-line.
3. Files are version controlled in the repository; filenames do not use dates and remain constant for the life of the artifact (one artifact instead of one for each version).
4. There is only one version of the project's truth: in the repository.
5. As team members come and go, their record of the project's history is easier to recover as most of the activity is documented on the repository, less in e-mail.
6. Communication-status meetings are rare; daily status, project news, and data are available on a dashboard style of user interface for retrieval anytime.
7. Team members spend more time producing and less time working e-mail.
Weaning a project team from the e-mail approach requires technical standards and human discipline. Standards must be documented-enforced so that filenames and file locations are consistent and make sense for the majority; for example, filenames cannot change for SharePoint to see the artifact as a new version of the same file. On the people side, it will be easier to begin with a repository approach than to retrofit legacy projects that have been using the death by e-mail style. Admittedly, it's easier for a user to drag an e-mail into an Outlook folder than to save the attachment to disk, and then upload it to the correct SharePoint folder. For this paradigm-change the project members need to alter their mindset from "I need this" to "the team needs this" information.
The negative effects of e-mail on project team interactions-communication are a linear function of team size. A project with fewer than ten members may not have much of an issue, but over that limit e-mail becomes an impediment instead of an enabler for collaboration. Consider too the bandwidth, storage, archive and e-discovery costs of running a project by e-mail. One project regularly e-mails 2MB worth of attachments to the 73 members on a weekly meeting distribution. That puts 146 MB of data each week, roughly 7GB over a year, around the network needlessly--as the files could be placed in one location and referenced (never mind why that many people attend the project's weekly meeting!)
Centralizing project artifacts-communications into a repository may not be enough to ensure that important projects are successful. It may be necessary to colocate the core team of decision makers and stakeholders. Even colocation for short periods puts key project stakeholders in proximity so they can establish-maintain trusted working relationships. While experts disagree on most aspects of colocation, including the definition (and even spelling) of the word5, project practitioners acquiesce they will accomplish more when interdependent project members are just down the hall.
Why do thousands of fans regularly attend sporting events when they could sit in a comfortable easy-chair at home watching in high-definition? Because there's no substitute for being there! No matter how much technology we wrap-around the experience, given a choice, most prefer a person-to-person connection. Similarly, a substantial amount of face-to-face interaction is essential to an IT project's success. Project success depends upon flourishing collaboration, but working remotely behind the façades of technology imposes significant barriers. The technology impediments are imposed over what is already a challenge, as described by Morten Hansen in his book, Collaboration6. Hansen spots four typical barriers to collaboration:
1. The not-invented here barrier (people unwilling to reach out to others).
2. The hoarding barrier (people are unwilling to provide help).
3. The search barrier (people are not able to find what they are looking for).
4. The transfer barrier (people are not able to work with people they don't know well).
Add to these patterns the volatility of a project group that has never met in-person, do not know each other, but need to exchange and action complicated knowledge. While the first two barriers listed above are motivational problems, the last two are capability issues. To address the motivation aspect, it's easy to coalesce a group around a compelling mission as a unifying force. For the search barriers, the use of a centralized hub for project activities can guide a task group to the information they seek. But for the transfer barrier, there's no better solution than working face-to-face. If full-time colocation isn't practical, key project members must meet in-person at strategic points in the project's lifecycle to have any hope of becoming a team.
That term is used often: team. For example, an Integrated Project Team (IPT) is formed by submitting a list of cross-function personnel and putting them together with a conference call. The tendency is to call any group of people assigned to work together a team. But as DeMarco and Lister point-out in their seminal book Peopleware7, many of these groups don't operate as teams because "they don't have a common definition of success, or any identifiable team spirit" using the metaphor jell to describe the missing element. The authors describe that a "…jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts." Academically, a jelled team is a high-performance team8. A high-performance team has cut through the forming, storming, and norming right to performing. There are specific attributes of a high-performance team, but one that is essential: the team members must trust each other.
In the context of building a team, trust is the confidence that teammate intentions are good, so there is no reason to be protective or careful in the group. That is: being vulnerable by exposing individual weaknesses, skill deficiencies, personal shortcomings, mistakes and asking the group for help without worry of repercussions9. This is quite a shift for most career professionals who have been taught and experienced that in order to get ahead, it's necessary to be competitive and protective with peers. Turning-off those instinctive behaviors is difficult, but necessary for an assembled group to become a high-performance team.
It's unlikely that vulnerability-based trust can be attained over the telephone. Achieving that level of trust requires shared experiences, with an understanding that each member brings a set of unique attributes to the team. The group can learn those attributes quickly through face-to-face meetings with interpersonal exercises. For example, by going around the room and having each team member speaking to answer a few short questions about themselves: siblings, hometown, childhood challenges, hobbies, first job, worst job, and so on. Seeing this first-hand with visual, tacit insight helps a group relate to one another on a more personal basis, with greater empathy and understanding, melding a team. This type of interpersonal feedback must be repeated regularly over the project's lifecycle as people come-and-go to fill changing functional roles.
Colocation speeds the formation of high-performance teams and facilitates continuous reinforcement of powerful interpersonal dynamics. Two of the principal factors that inhibit performance on virtual teams compared to face-to-face teams are: the absence of paraverbal and nonverbal cues, and a limited social context10. Losing the nonverbal cues means that virtual teams suffer less social rapport and often, are not able to duplicate the normal give and take that occurs in a face-to-face discussion. These communication barriers lead to stalemates, analysis paralysis, social loafing12, and project delays.
History will record that in this century, we learned how to integrate technology into the workplace as humans learn--by trial-and-error. In the 1980's, we crowded around the green-screen dumb-terminal hungry for data and dot-matrix printouts. During the 1990's, we put colorful client-server monitors on every desk with Internet access. After sweating-through Y2K, we took the Internet home and didn't bother going to the office anymore. The dumb-terminal now fits into a pocket. After working from home for some time, we see evidence that many IT projects need more than conference calls, e-mail, instant messaging, and virtual meetings. The projects need face-to-face meeting time to be successful.
Finding the right amount of in-person meeting time is the usual balance of cost-benefit. However, there is a good amount of empirical evidence gathered from IT projects by the Atlantic Systems Guild to suggest the following general guidelines:
1. The key project leaders, responsible for coordinating work across functional teams need the most frequent in-person contact. These program managers, project managers, sponsors and co-chairs need to meet multiple times during the project's lifecycle--even quarterly may not be enough.
2. Developers, Quality engineers, release managers, technical writers, and their respective business counterparts need to meet at least once every six months. Establishing mutual credibility and team jell follows these team leads back home and allows them to positively influence junior teammates.
3. Allowing junior team members at least once a year travel to meet the rest of the team serves to illustrate how their work fits into the project's overall mission, and exposes them to mentorship-career development opportunities.
Responding to budget pressures by restricting travel for in-person meetings is a "fool-proof recipe for guaranteeing the failure of a distributed development effort.13" For successful IT projects, you need to increase, not decrease, your travel budget.
Telework with virtual interaction are appropriate for diurnal perfunctory and work that requires solo concentration and whisper quiet. But by definition, a project is composed of non-routine tasks directed to a goal. The PMBOK™ definition of project management adds that achieving stakeholder expectation "invariably involves balancing competing demands among scope, time, cost and quality and stakeholders with differing needs and expectations." That's not a process that lends itself to restricted communication modalities of e-mail and telephone between project managers and key stakeholders. Add technical complexity, fragile legacy software, tight software coupling, interdependencies between projects and there will be problems. We've come a long way since the tap-tap-tap of the telegraph--but are still neophytes with collaboration technology in the historical context.
Given the evidence of how in-person meetings influence IT project success, running projects solely by e-mail and telephone must be described as regressive. To transform mediocre task groups into high-performance teams, it will be necessary to change behaviors and the process framework. For example, e-mailing file attachments when shared project repositories are available. Meeting in-person may need to become a requirement for the launch and sustainment of Integrated Project Teams, with the associated travel costs categorized as sagacious investment. Colocation, viewed by some as a thing of the past, should be dusted-off and implemented whenever practicable--and required for mission-critical projects. It's cold out here in cyberspace.
(· · · – – – · · ·)
Reference and Notes
3. Australian Journal of Basic and Applied Sciences, (2009)
6. Morten T. Hansen, Collaboration, (Boston: Harvard Business Press, 2009), 17.
7. T DeMarco and T Lister, Peopleware, 3rd edition, (Dorset House, 1998).
8. R Pressman, Software Engineering: A Practitioner’s Approach 6th edition (New York: McGraw-Hill, 2001).
9. Patrick Lencioni, The Five Dysfunctions of a Team, (San Francisco: Wiley, 2002).
10. Stephen P. Robbins, Organizational Behavior, 10th edition (New Jersey: Prentice all, 1993).
11. Atlantic Systems Guild, Adrenaline Junkies and Template Zombies, (NY: Dorset House, 2008).
12. Social loafing is the tendency for individuals to contribute less effort in a group environment compared to working alone. The propensity may be enhanced by electronic façades and telework.
13. Atlantic Systems Guild, Adrenaline Junkies and Template Zombies, (NY: Dorset House, 2008), 42.