Guides - Planning

Guide to Structuring Distributed Work

admin — Wed, 28 Sep 2016 14:48:09 +0000

Guide to Structuring Distributed Work admin Wed, 09/28/2016 - 10:48

The formal structuring of work has been found to be particularly useful in coordinating virtual collaboration (Hoch & Kozlowski 2014; Steinhardt and Jackson 2014). A fundamental approach to structuring work involves breaking tasks down into discrete, manageable chunks. This notion of task decomposition is at the root of everything from the division of labor to the work breakdown structure process in project management (March & Simon 1958; PMBOK 2001). The principles of modularity, which involve breaking up of work into well-defined chunks with specific interfaces, are particularly critical for managing complex science tasks in virtual collaborations.

Research into the many forms of virtual collaboration emphasize the power of modularity. For example, modularity is critical to successful distributed technological innovation, outsourcing relationships, and distributed software development (Baldwin & Clark 2000), including open source software projects (MacCormack et al 2006). The key to modularity are the two components: (1) break up work into discrete tasks, and (2) create well-defined interfaces between these tasks.

Task decomposition

The first step involves hierarchical task decomposition - to take the complex task and divide it up into smaller tasks. In project management this step is often referred to as creating the work breakdown structure. Take large tasks and break them up into smaller tasks, and break these up to even smaller tasks until you find the appropriate unit of work. Hierarchically enumerate these tasks. In project management practice, one then typically takes this work breakdown structure and organizes it according to a schedule in a Gantt chart (PMBOK 2001).

Of course, this process sounds simpler than it actually is in scientific projects. In scientific research, goals and outputs are not well-defined in advance and often change throughout the course of the product (Turner & Cochrane 1993). Simply, it is not quite apparent how to breakdown a team’s work in advance. A best practice for dealing with this is to identify key deliverables and the information requirements for those deliverables (Turner 2000). In an exploratory situation one can never perfectly predict things like the information content nor the duration of tasks, but one can predict the sorts of information that will be needed for subsequent steps. Deliverables of data collection involve the data. Deliverables of analysis may involve lab reports or statistical analyses. These deliverables can be further broken down.

The role of deliverables

An important note about deliverables is that they do not just mark the end and completion of a task, but that deliverables are used for many and multiple subsequent tasks. If one thinks about deliverables as the interface between tasks (i.e. all subsequent tasks) then the conversation moves to structuring the sorts of information - or the information requirements - of all subsequent tasks. It is critical to align leadership responsibilities, communication and incentives (such as reward systems) with deliverables to drive better performance (Hoch & Kozlowski 2014).

Even if work breakdowns can only be projected out for a short period of time, beyond which tasks are unknowable, work breakdown can be worthwhile for its side-effects. This is because working to accomplish simple tasks in a way that is visible to others in the initial stages of a collaboration can provide trust and knowledge of each other’s skills that can enable the group to adjust their work over time (Iacono & Weisband, 1997; Mitchell & Zigurs, 2009). Thus establishing a set of simple tasks whose accomplishment and deliverables are visible to each other is worthwhile almost regardless of the specific content of the tasks; certainly visible, structured, work is a promising alternative to long meetings early in a project. Further, science teams will have difficulty developing an accurate project schedule from a work breakdown structure, but the exercise of creating and targeting dates and date ranges for deliverables assists in coordination of a project. The importance of goal setting is perhaps the most well-established factor for better performance among innovative teams in the existing body of research (Hoegl & Parboteeah 2003), and the act of breaking down work, defining deliverables, and determining initial schedules are the fundamental activities in goal setting.

Meetings

So how does this all translate into structuring a virtual collaboration? First, it is well-established that face-to-face kick-off meetings are particularly important for virtual team success (Hertel et al 2005; Ferrazzi 2014). Kick-off meetings help build interpersonal relationships and trust that will be invaluable throughout the collaboration. But, as we discuss further below, the kickoff meeting should not be unstructured. During that kickoff meeting it is important to structure the work and to involve project participants in goals setting. Identify key deliverables, breakdown these deliverables into their lower level tasks, identify information requirements of tasks and codify them as standards for deliverables and assign teams to the different tasks.

Focus the subsequent virtual meetings and documentation on deliverables with participants from the appropriate teams responsible for these deliverables. Team members do not need to participate in meetings, conference calls, or email chains, unless they are specifically associated with a given task for a deliverable. To the extent possible, schedule meetings around deliverables and include only those assigned to particular deliverables for those meetings and included in those tasks.

Limits of modular work

It is important to note that complex tasks like science projects can rarely be considered to be perfectly modular. They inevitably involve unforeseen interdependencies with other tasks in unanticipated ways. Nobel prize winning economist Herb Simon referred to this as the “near decomposability” of complex systems (Simon 1962). So it is important to realize that a perfectly modular work breakdown is likely unattainable and no team will get it right the first time. So teams should occasionally coordinate across modules. This cross-module coordination involves periodic cross-team meetings, but these cross team meetings should focus on deliverables and information requirements to reduce unnecessary discussion. Broader meetings across groups (i.e., meetings across groups responsible for different deliverables) should be scheduled before, during, and after deliverable handoffs, and when interdependencies become evident.

A note about scale

An important note is that the coordination requirements of virtual collaboration scales with the size of the virtual team (Boh et al. 2007, O’Leary & Cummings, 2007); bigger teams, teams with more diverse expertise, and teams from different organizations and in different time zones all require more structure to avoid the inefficiency of too much ad-hoc, discussion-focused coordination that may be fine for smaller, homogenous teams (Cummings et al 2013; Nguyen-Duc et al 2015).

Tags

Guides - Running

Guides - Planning

Weight

Guide to Distributed Data Management Plans

admin — Mon, 26 Sep 2016 15:34:43 +0000

Guide to Distributed Data Management Plans admin Mon, 09/26/2016 - 11:34

Many institutions support their researcher communities by developing guides to data management plans. These are some of the most well-developed and thorough.

MIT Libraries guide to data management plans
Cornell University Research Data Management Service Group
The Data Management Plan Tool developed by the University of California Curation Center of the California Digital Library

Tags

Guides - Planning

Weight

Guide to Choosing Distributed Collaboration Technology

admin — Mon, 26 Sep 2016 15:31:22 +0000

Guide to Choosing Distributed Collaboration Technology admin Mon, 09/26/2016 - 11:31

Technological platforms make virtual collaboration possible. It is imperative that virtual teams take the technological platform seriously, because platforms do not just enable virtual collaboration, but they can also get in the way of virtual collaboration (Gilson et al 2015). By platforms we mean a wide variety of technologies, including email, video conferencing tools, shared document storage, shared document editors, content management systems, project hosting such as HubZero, and commercial software suites marketed as “groupware” systems like Microsoft Sharepoint or the Jive Collaboration software.

Despite marketing hype, platforms by themselves don’t do anything: what matters is the ways in which they are used (Desanctis and Poole, 1994). For example, there are many open source virtual collaborations that are registered on Github. Github, as a platform for open software development, offers useful tools, but projects vary widely in if and how they use different tools. Successful projects establish and maintain norms around platforms. Norms are simply the established or standard ways of working on a platform. For example, a collaboration may develop a naming convention for versions of documents (such as including a date and last author’s initials), or develop a norm about using comments in an online editor such as Google Docs.

Collaboration platforms are effective when they are a central meeting place for participants and when participants learn shared norms and conventions for their use (Maruping & Magni 2015). New platforms are constantly being created, and they make it easy to get started. Often it only takes a single member of the collaboration to sign up and send out a link to others. This can quickly lead to a fracturing of a collaboration’s records and documents, with multiple semi-abandoned platforms associated with a single on-going collaboration. Chopping and changing platforms leads to fractured attention. Even worse, it undermines the time and shared experience needed to evolve and learn shared ways of using platforms. There is value in establishing and maintaining a specific platform long enough for norms for its use to emerge and to become shared. As frustrating as older platforms can seem in comparison to shiny new platforms, having a single, well practiced, platform is likely of more value in the long run than any enticing features of a new platform. Some of the most successful open source teams, for example, only use email lists, even for practices such as voting (Crowston et al, 2012). New features are seen to solve immediate problems, but adopting a platform is a key decision with important consequences for the whole collaboration and should be undertaken rarely and with the involvement of all participants.

Holding a collaboration focused on learning and using a particular platform is an important leadership role. As with most pieces of technology there is a well understood tendency for the most powerful members of an organization to use their status to resist using unfamiliar technologies (Grudin, 1988; LaPointe and Rivard, 2005). It is difficult for less powerful members of a collaboration to influence the more powerful to work in particular ways. Conversely, visible and enthusiastic use of a platform by the leaders of a virtual collaboration sends a powerful message and shapes use of the platform throughout the team. Scholars refer to these effects as a form of “social proof” (Cialdini and Goldstein, 2004) and the ability of leaders to drive uptake as “information cascades” (Bikhchandani et al, 1992).

Finally, virtual collaborations have fluid and partial memberships. This means that all participants are unlikely to be working on an virtual collaboration full-time and that their involvement will be bursty, with a lot of activity during certain times, but inactivity for long periods (Ahuja et al 2003; Steinhardt and Jackson, 2014). Moreover, the power of a virtual collaboration comes from being able to access diverse skills and experience, which means being able to bring new members on board quickly and easily, often from new organizations, and to identify skills and experience of these new and existing team members. A directory of such capabilities - sometimes referred to as a “transactive memory system” - helps virtual organizations perform better (Choi et al 2010). It is imperative that virtual teams keep a current directory of “who knows what” and “who is responsible for what” over the course of a project, particularly for larger, more complex virtual teams, and those that are entirely virtual (Kanawattanachai & Yoo 2007).

Fluid and partial memberships also influence the impact of pricing schemes for virtual collaboration platforms. Some commercial platforms are expensive, requiring fees that give access to a particular number of users (often called per-seat pricing). These do not match fluid and bursty participation well because the collaboration has to pay for seats even during the times of low participation. Similarly, per-seat licensing often has steep pricing threshold built in, such as free for up to 10 users and $1,000 per user once you go over 10 users. Pricing schemes like that can make growing virtual collaborations, or replacing members, very painful. Similarly, platforms (e.g., Microsoft Sharepoint) are sometimes available free to members of particular universities through site-licensing. Yet building a virtual collaboration means extending across organizations but if a platform is limited to one set of users adding users from other organizations means adding on new platforms, undermining the centrality of any platform and disrupting the norming process that leads to effective platform use.

Further, because virtual team membership tends to be fluid and partial, it is critical that the team develop norms and expectations associated with the use of platforms and other collaborative activity. Since this partial and fluid membership and attention is so prevalent in virtual teams, the role of central people in the project is even more important (Ahuja et al 2003). Central people, such as leaders and administrative support who schedule and lead the activities must be fully engaged and consistent with coordinating all activity and setting a good example, reinforcing the norms of collaboration. A key critical finding of virtual teams literature highlights the importance of leadership to both setting the stage for effective collaboration with strong norms and conventions, and also constantly monitoring and reinforcing those norms (Bell and Kozlowski, 2002).

There are platforms for synchronous work and asynchronous work. For synchronous work such as meetings, conference calls, and web conferences, it is imperative that the medium both scale to the appropriate number of users and provide reliability at that scale. Many free web conferencing platforms that are fine for small groups do not scale well to bigger groups and can have issues with reliability. It is important that the team standardize the platforms and use the same platform across the collaboration as a part of admission.

Thus there are a number of important platform-related activities that must take place during the startup meeting. First, it is important to choose platform and begin using it at the face to face meeting. It is particularly tempting, since we are used to meeting face to face, to treat the startup meeting for a virtual collaboration like any other meeting. Yet it is important to remember that the working circumstances of the startup meeting will not continue: rather than being nearby, after the meeting participants will be at distance. Rather than all being present for long periods of time, participants will be returning to their busy work lives. Participants at ApacheCon, a meeting of a very successful open source community, had a norm for scheduling meetings when all members of a collaboration were available. Yet when they met they continued to (and practiced) using the platforms they used when at distance (Crowston et al., 2007). The startup meeting, therefore, should focus on learning to use the platform that will enable ongoing work after the meeting. Simply, projects should seek to start as they will continue. Being together but using platforms designed for remote work will seem strange at first, but will build norms to make working at distance more effective.

Tags

Guides - Planning

Weight

Guide to Types of Distributed Organizations

admin — Mon, 26 Sep 2016 15:30:28 +0000

Guide to Types of Distributed Organizations admin Mon, 09/26/2016 - 11:30

Virtual organizations, also known as virtual teams or distributed teams, work primarily by remote communication (e-mail, telephone, VOIP tools, and text chat, e.g.). Even with the ease of establishing electronic communication, to be successful, distributed teams depend upon their members making significant investments of time, creating and maintaining collaborative structures in order to coordinate their activities.

As a result of advances in communication technologies, contemporary innovation can be highly digitally dependent, cross-organizational, geographically and temporally distributed, and made possible by broad-based platforms and infrastructures (O’Leary and Cummings, 2007; Tiwana et al., 2007; Tiwana et al., 2010; Yoo et al., 2012). Diverse experts are able to work together on problems that require intense collaboration and coordination across vast geographic distances with the aid of digitized exchanges.

There is a significant investment in collaboration and coordination that must be reinforced by shared vision, social factors, trust and relationships, organizational factors, leadership, or complementary information systems. Social factors such as shared vision and trust-- in leadership, the organization, and the information systems-- are vital: these reinforce members’ investment in the collaboration and coordination which allow the project to succeed.

Concepts

When defining distributed teams, there are two overarching structural concepts: organizations and platforms.

Organizations

Organization-based distributed occurs when a parent organization contributes to the structure of the work. Under this model, the team maintains access to and is constrained by the resources, knowledge flows, and tasks of the parent organization (Winter et al., 2014). The two main types of organizational teams are the agent relationship and the work team.

The agent relationship encompasses outsourcing, offshoring, and arm’s length interactions. At its core, an agent performs work for the parent organization by meeting agreeing upon outcomes (Schilling and Steensma, 2001).

The work team exists with respect to the boundaries of a particular organization and is the most common virtual team structure. Work teams are often seen in project management (Pinto el al., 1993) and new product development (Edmondson and Nembhard, 2009).

Figure 1. The relationship of organizations and platforms.

Platforms

Unlike organization-based teams, platform-based teams do not maintain a reference container, but instead rely on information systems. Organizations spring up in relation to existing work - where the work and the infrastructure precede the organization (Winters et al., 2014). The platform provides the structural basis for a virtual organization, acting as the information system that organizes the work (Tiwana et al., 2010); rooted in digital platforms (Howison and Crowston, 2014), and the team adjusts the platform to fit their preferences (Howison and Crowston, 2014; Majchrzak et al., 2000).

The open project consists of interdependent tasks or small, individual-level tasks that can be easily modularized to accommodate publicly accessible projects. This structure relies on multiple modes of electronic communication. (wikipedia, open source software, platform enabled projects) Due to the low barriers to membership, public knowledge-sharing, and public distribution of work outcomes, participants are free to come and go (Shah, 2006) and members consume the work product (Raymond, 1999).

The managed crowd works independent from one another when tasks are simple and numerous with little or no information sharing (Vakhaira and Lease, 2013). The ideal solution can be described and measured and occurs when the parent organization chooses to shift work outside the boundaries of the organization.

Type Shifting: From Platform to Organizational Structures

Under some conditions, an organizational unit can migrate toward a different work pattern. Arm’s-length coordination may evolve into a period of intensely collaborative work teams, after which the group may revert to a previous or adopt a new form of arm’s length coordination (Brent et al., 2010) A managed crowd may start behaving more like an open project as connections beyond the organization’s boundary are introduced. When connected to knowledge and expertise, they may begin to form connections outside the traditional organizational boundary, extending the original organization teams.

Open forms of organizing tend toward the organizational container and classifications are not static and may evolve over time as the project changes. Examples of a shift from platform based to organization based structures are the Mozilla and Apache foundations, which began as open projects and grew to have organizational momentum (Mockus et al, 2002).

Figure 2. Movement of the team structure

Tags

Guides - Planning

Weight