Remote Projects

Abstract

The authors illuminate the opportunities and the potential of delivering projects without the project team being physically close together. The concept sounds similar to the near-shore and off-shore approaches used since the nineties but includes some important differences and advancements.

1 Introduction

The term “remote work” (ILO 2020) gained a lot of traction due to the pandemic the world had to face at the time we wrote this article which has hopefully disappeared by the time you are reading it. We are certain that everything we have learned in 2020 will change the way many people work in offices for years to come. But this is in no way the only reason to carry out remote projects and is not the main driver nor the first one.

We, the authors, as well as the companies we have worked for, have carried out remote projects for most of the past 20 years, and we have collected our experience and knowledge to write this article and start sharing our experience over the following pages.

In the next subsection of Sect. 1, we will talk about how to identify remote projects, what they have to do with remote work and “shoring,” why you should consider them and the main challenges.

In Sects. 2–4, we will talk about culture, methodologies, and technologies to consider and use for successful remote projects. The great thing about these are: they are generally relevant for any other projects or even helpful for just remote work—so please keep reading even if remote projects are not for you or your organization.

1.1 Remote or Distributed, Near-Shore or Virtual? All the Same?

First, let’s define a “remote project”.

With our definition, we are focusing on projects and not on any other activities in your lines of business. A project has some very distinctive properties. The most important ones are a “fixed start and end (or fixed budget)”, “defined scope (or vision)” and they are a collaboration of different skills and/or departments (ergo: no easy tasks). Many projects incorporate external help, simply because they are by definition something you don’t do every day and might need extra expertise.

Let us have a closer look at what defines the “remote” part of it.

Do your employees have a day working from home (pre-pandemic) but are on site for the rest of the time? Or did you get external and remote help with a certain problem in your project for a few days (e.g., a performance expert, legal advice, etc.)? That does not necessarily make your project remote! A little bit of remote work does not automatically convert your project into a remote project. But if you completely outsource a large chunk of a project (e.g., development), then you have a remote project. Let us look at specific examples.

The first real remote projects were the outsourcing (offshoring) development projects in the 90s (Fig. 1).

Fig. 1

(© ifb SE)

Two distinct teams with one connection

Many projects and companies failed in this endeavor, but in the end this model did succeed and is still a very viable way of carrying out projects. The key success factors included developing better requirements engineering (the invention of the modern business analysis) and emphasizing the importance of testing. Both have made their way back to traditional on-site projects as well and should be considered the state-of-the-art when doing any kind of project.

Some of the methods in Sects. 2–4 have also been developed in these offshore models, but in the end the number of connections between the on-site project team and the off-site team is very limited to the point of only having a single line of communication that transmits requirements and test results (i.e., defects). Also, in most cases, both parts of the project are ultimately not remote because both teams are (for themselves) physically close.

These offshoring projects paved the way for the modern remote project. First of all, they developed many methods and tools we use in all projects today, but, secondly, the high chance of failure of these projects and the high costs of labor in the countries where the ordering companies resided fueled the creation of the modern agile project management methods that help highly experienced and expensive employees to still be competitive with these offshore projects.

Basically, you either had to be flexible in your approach or be strict or carry out outsourcing when it came to certain project deliveries. Therefore, the next question is: why not combine these two ideas? Shouldn’t being flexible and remote be even better?

This directly leads to the idea of the new remote projects. If we take it to the extreme, this might actually look like Fig. 2.

Fig. 2

(© ifb SE)

Connections between remote project team members

As you can see, the main difference is not someone being off site or being somewhere else, but the number of relevant connections increases exponentially.

In your remote project, you might find something in between these two examples, with more than just a few connections between teams that might be together locally and some experts working completely remotely (Wikipedia 2020). All of the above need more than what an offshore team needs and that is what this article is all about.

1.2 Reasons for Remote Projectsand Why Pandemics Have Little to Do With Them

Normally, we would start with many other reasons to go remote, but since this book was written during the first global pandemic in the lifetimes of all the authors, we should address the elephant in the room.

Yes, pandemics are a good reason to go remote. More precisely, disaster planning has always been a reason to not rely on being able to work from an office. Depending on where you are, snow storms, tornados, floods, civil unrest, man-made catastrophes, or extreme weather can surprise you, but “[…]it is safe to assume that office closures and public transit disruptions will happen at some point[…]” (O’Duinn 2018, 34).

When going back to our normal list/priority of reasons to go remote, number one will always be “the real cost of an office” (O’Duinn 2018, 7), which consists of far more than just the rent. If you take into account the extra employees who are only there to take care of your building, empty spaces in offices that are too big, not enough space in offices that are too small, costs of architects, builders, desks, chairs, coffee machines, security doors, alarm systems, internet access, time to make floor plans, etc., you end up with much higher costs than expected. But if you then also take a look at hiring costs (how much do you have to pay someone to move to your office location) or diversity costs (the extremely skilled Mongolian JAVA developer who will never move to your office location—or is not allowed to, see also Kissflow 2020; Gale 2019) or the costs of higher salaries because you have an office in an extremely fast-developing area of Silicon Valley—you have a lot of reasons to think about going “remote” (O’Duinn 2018, 7–19).

While these reasons are all also valid for remote work they apply even more to remote projects.

Commute times impact the health and well-being of employees (and indirectly also part of their salary) greatly. For remote projects, with experts who have never decided to live somewhere close to YOUR office, this becomes even worse because we are not talking about commuting anymore but travel. This travel can take a day or more and will cost more than just an add-on to their salary, and you will have to pay their expenses as well as the travel times if they are excessive.

Thinking this through, people will spend more time traveling and less time working. In all the projects that we experienced, project managers were more concerned with travel expenses, but the real costs are opportunity costs. Employees are working fewer productive hours than they could, since they are on the road, in airplanes or trains.

If you run a consultancy firm, these travel costs will affect you even more, because until today travel times and being away from home are still the number one reason to look for another job and also a major factor in salaries for consulting.

What is even worse are inefficiencies due to being on site. We expect employees (internal or external) who are being paid to work on a project to work efficiently when they are on site. In a project office or an on-site location, they will always pretend to do just that and will certainly also bill you as much as they are on site. Does that necessarily mean they are working or are even productive? Most project managers know that skills are only needed at certain times. A developer is needed when a specification must be written or when defects occur but, if everyone is on site, all these people will bill you even though they should be working on something completely different. If there is a day without defects and new specifications, another customer (and you) would be better off if your developer worked for them. Instead, you put them in an office where they probably cannot do anything else for you at that time but will pretend to do so. That is not productive at all.

The situation above also relates to the main reason why (project) managers like having employees on site—it is neither the easier communication nor collaboration but control over what they are doing. This control is an expression of mistrust but also insecurity about the real status of the project and about the output of your employees. And it isn’t completely unfounded! Who doesn’t have or know a colleague or co-worker who is notorious for not answering e-mails and calls on the day they work from home? Is control the solution? Yes, it can be. But not by putting them in an office, because then they will do something even worse: appearing to be busy but not productive, bestowing you with an unfounded feeling of security. The better response to the situation is: more knowledge about your actual project status and the productivity of your project members, not by checking how they work but by what they produce. Read more about how to do this in Sect. 2.

When looking at human resources in projects (and not day-to-day business), we tend to pretend that assigning three people with 100% of their time to the project makes sense even though everyone knows that the real work can range from 0% to several hundred percent of a single person’s output. We still plan like we can always build a productive workload of tasks to do but that is not true for most projects and is also contradictory to the nature of projects.

What we would really need for a lot of tasks is “on-demand” resources, at least for the excess workload of a project. What should be obvious is that this “on demand” cannot happen on site if travel arrangements are costly and need planning ahead. Therefore, any part that can be worked on remotely is much more feasible. If I put my best experts on two to three projects at the same time from their homes instead of having them at one project one week and on another project the next, we end up with much better efficiency for all projects. This could only be mitigated if all these parallel projects were at the same office location but for external consultants or bigger companies that scenario is not very likely.

Imagine letting people only work for your project if they really had something important to contribute, they would work and bill far fewer hours for nearly the same progress in a project.

If these reasons are still not enough, consider the following question if you aren’t already remote anyway. Do you have different office locations across the globe/country/town and people rarely see each other and/or you have certain parts of the projects in India/Eastern Europe/or elsewhere already? Then you work remotely (in parts) and could easily go the next step towards creating a fully remote working environment. We are confident that this will help you save money and achieve your project goals much more efficiently and reliably.

1.3 When Should You Not Carry Out a Remote Project?

There are pitfalls for remote projects, and it is good to know them. There are even some situations where remote projects can be damaging or are not feasible.

An obvious example would be that you cannot build a bridge remotely. That might sound like common sense and is also true at the same time, but is that the full story? In fact, the larger value gain in construction work is not on site. Most of the planning before and during construction work (or a construction project) is already done remotely and even those working in and with the planning team are instructed remotely by very clear specifications. But nonetheless, the building part is carried out on site by the construction team. The same can be true for any project. There might always be tasks that can only be done on site.

Another situation where a remote project is not a good option is when you are a small organization with everyone located in the same office on the same floor. In these kinds of project, a lot of overhead-producing project management tools can be left out and you are usually much more productive without these tools than with them.

But what if you still have all the resources in one location yet your organization has grown beyond the point where everyone can fit in one room and still work? In their 2009 article “How to manage virtual teams” (Siebdrat et al. 2009), show that the increased productivity of collocation only works for really small teams and really small distances. Even different floors are already enough to create all the disadvantages of a remote project and if you don’t consistently apply the appropriate management methods to these projects, they will end up producing worse results than real distant project teams. The effect of being dispersed but not feeling it makes it worse, because project members are not aware of their situation and don’t act appropriately.

If you are looking for signs that your whole team has gone remote already (even though they work in the same office), take a look at the following two interesting questions:

• Does your project team frequently use e-mail, telephone and other meeting tools to communicate? Do they argue and have intense discussions via these media?

• In a development project: has someone on the team worked hard to improve a function while others have worked on replacing it?

All these are signs that you should already treat your team and the project they run with the same tools you would use to run a “remote project.” Even more so, you could go “fully” remote quite easily after applying the methods described below and be much more efficient than you are today. We, the authors, also believe that you should always consider “remote project” methodologies because “[…] carefully organized work procedures outperform all-in-one location teams” (O’Duinn 2018, 59).

2 Are There Methods to Be Considered? Can I Jumpstart from on Site to Remote?

You cannot keep on working like before but just from home, it is not as simple as that. Some people tend to have problems focusing, so they have to do their work in smaller chunks, and they need an area in their apartment dedicated to work. Others struggle to stay up to date or are even prone to get depressed due to the lack of social contact, which is why dedicated face-to-face time and regular meetings are required. If you are managing projects and usually like to micro-manage your team, this will not work well in a virtual environment. So it makes sense to invest some time upfront to plan and in particular communicate a project properly. To not get caught on the wrong foot when moving to “virtual”, we have handpicked four areas of typical business interactions and compiled a collection of best practices and suggestions to help you lead your virtual team to success.

2.1 Being Prepared Is Everything—Set Up Your Tech Correctly

If you are planning to spend a lot of time in your home office and talk a lot to your colleagues virtually, this might be a good time to rethink your office setup and to recall basic rules on how to use your tech.

Since everyone has different ideas about how a perfect office should look, it is certainly a good idea to install your office yourself instead of relying on your IT department. Employees know best what they will need to work effectively from home. Hence, why not give them a budget to update their desk, to buy the latest tech, a nice lamp, or inspirational room decorations? Certain furniture purchases, like ergonomic desks for better health, can be encouraged. Make sure you avoid “forced budgets” by setting budgets that must be spent.

While designing your office, keep in mind how your colleagues’ work experience can be improved with visuals and audio. Muting your microphone when you are not talking should be a matter of course. Disturbing noise and a wrong video stream can be easily avoided like this (a lot of conferencing tools will show the video of the person talking). Also, when setting up your webcam, place it close to your chat window. This will create the illusion of eye contact with the colleague you are talking to. And, speaking of webcams, learn from professional YouTube streamers: the picture is always too dark! If you want to look good in your video, invest in a small USB LED floodlight to illuminate your face, and always keep the background in mind as well. People are curious and socializing will be easier if your counterpart is able to see your real office space rather than a green screen background replacement. For a great summary of video etiquette and technical advice, also see (O’Duinn 2018, 73ff.).

2.2 Plan Ahead and Use Your Time Wisely

When working remotely, communication certainly is key. You cannot quickly walk over to the other office to get the latest news or ask a colleague to demonstrate something on his computer. Coordination gets unreasonably complicated if you try to transfer all of your old habits from on-site to off-site working. As a result, a lot of people develop the habit of setting up a huge amount of calls and web sessions when isolated in their home office. You have probably experienced the consequences yourself: complaints about the lack of time to actually get any work done.

Here are a few tips and tweaks to enhance your time management in remote teams. To avoid constant interruptions and to increase your productivity, define a block of time each hour that is reserved for team communication. For example, the first ten minutes of every hour. This time window can be used to coordinate during calls and chats and should naturally be identical for the whole team. When the time is up, switch your messaging tool to “do not disturb” mode. Additionally, it can be beneficial to agree emergency guidelines with your team for if something unforeseeable and important happens that cannot wait until the next time window.

But even this practice might not give you enough time to focus on complicated topics. Instead, you could try to establish a “no meeting day.” Select a day of the week that works best for the whole team and make sure that there won’t be any meetings that day. You can try to block that day as “busy” in your calendar to remind meeting schedulers of your focus day. Don’t forget to regularly assess whether you and your team have picked the right day for this practice.

If, in spite of everything, you are still thrown off by an unjustified amount of meetings, try to rework your calendar. Sometimes, recurring meetings lose their purpose, but nobody dares to cancel them. Discuss the practice of removing every meeting once a quarter and re-adding what is necessary afterwards. Like this, you can ensure that only meetings that add value to your goal or are required for coordination will accompany you through the next quarter. When adding back a meeting, ensure that only the required people are invited. Use this chance to clean up and minimize the group of participants.

Planning gets even more complicated if your team is scattered across multiple time zones. Not only will it get increasingly improbable to find common time slots, the colleagues in the “minority time zone” will also feel more and more disconnected from what is going on in the project. Keep the following in mind to facilitate communication (Mahn 2020):

• Know the time zones: nothing can be more discouraging than if your counterpart does not even know what time it is in your location, or does not care whether you have to get up at 5 a.m. for a meeting. The same is true for local holidays. Add a second time zone and holiday calendars into your tools.

• Speaking of getting up early: make sure virtual meetings—if really necessary—are well prepared. It can be very frustrating to work at unusual times just to find out there are no productive results.

• Keep in mind that people who just started the day might not be up to date with the information flow yet. Give at least one hour of overlap before starting a meeting.

• Try to change your way of working to asynchronous communication. If you have a public Scrum Board, or tools like Slack, OneNote, Google Docs, etc., every employee (no matter in which time zone) can catch up at their pace. This is a good idea for every remote project anyway (also see 2.4).

2.3 Communicate Effectively, but How?

Be it in scheduled meetings or in direct one-to-one calls, at the end of the day communication will be a crucial stepping stone to the success of your project (see 2.2). If you do not see the reaction of your counterpart, especially, make sure everything has been understood (by overcommunicating or giving more time for feedback). Hold virtual meetings to reduce social isolation and to build trust. Suggest video chat to your team to see body language and each other’s reactions. Video will also be an important part of teambuilding, you are not just a voice on the phone anymore (Powers 2018). Try to join video chats early so you can have a casual chat and set the right mood. Share a funny story or a picture of your desk. Also, similar to real-life meetings but even more important now, plan the meeting in advance and send an informative agenda (a great list of ideas for ideal meetings can be found here [Foroni 2020]). In this way, your colleagues can already think ahead and thus ensure a productive meeting leaving more time for other things. In the meeting, try to address people by name. You cannot look at somebody and expect an answer. If not addressed directly, open questions will usually remain unanswered. This technique can also be used to encourage silent participants. While talking, the moderator should make sure that nobody is interrupted. Instead, announce the rule of using the “raise hand” feature several tools have, or just raise your hand on the video. If, on the other hand, nobody is talking, don’t underestimate the power of the “pause.” This needs to be much longer than in non-virtual conversations. But, after 10 seconds at the latest, one meeting participant will probably start to take the initiative. Once the meeting is over—and we have come full circle here—summarize the outcome of the meeting and make it available to everyone to enable asynchronous communication.

The importance of small talk was already briefly mentioned. However, this small period of time certainly does not suffice for getting up to date with the latest technical skills or to really share (non-project-relevant) knowledge with your colleagues. Continuous learning is such an essential part of being a good developer, so block some time for learning when everyone is available: Pizza Day. Everyone loves pizza. Use a lunch or dinner to present a new topic to a group of interested colleagues regularly over food and beverages (locally consumed at each location) (Keith and Shonkwiler 2020). The topic can be chosen by interest and doesn’t have to be related to the current project directly.

Another communication idea we would like to share, even if it appears outdated at first, is newsletters. Everyone used to have one until mailboxes got flooded and either spam filters started deleting or users started ignoring these messages. But in times of virtual work, newsletters might experience a second boom. If the whole company or a complete team is working remotely, it is difficult to spread information that is of interest to everyone. The office grapevine does not work as fast anymore, if at all. Of course, newsletters could be much more modern than they used to be. Ask your managers and team leads to write a short summary of their week, introduce new employees, highlight technically interesting features or present the results of Pizza Day. Also, this update does not have to be sent by e-mail. Whatever tools suit your company best will work (e.g. MS Teams, hashtag #News).

2.4 Requirements, Agreements, and Status—Managing Remotely with a Single Source of Truth

Of course, communication is a crucial factor for managing projects. You will, for instance, easily get an impression of the status when others talk about their progress in calls. Or will you? How is your counterpart evaluating the communicated progress? Maybe they relate to the kick-off meeting at the beginning of the project, or requirements from a stakeholder, or what you discussed in e-mails with them? They might have gotten their information in private channels back when they needed it or made verbal agreements in face-to-face meetings. Which version of information in which communication channel is the correct one?

This example highlights the importance of a single source of truth (SSOT, also single version of truth) available to everyone (Dykes 2018). A platform used to store all information is needed to make a project a success: requirements, open issue lists, documentation, meeting minutes (yes you need them) and test artifacts. Making this work is not rocket science. Most project management tools will already enable you to work in an SSOT kind of way. You can also create the SSOT manually using Excel spreadsheets or other files and clean and merge data yourself. The greater challenge is the change in culture to accept the advantages of having up-to-date information centralized in one place. Of course, it is easy to quickly store files locally in your notebook or calendar, but if it comes to sharing the documents or to communicating the progress, the increased time to coordinate destroys that time saved. Publicly accessible information will at the same time reduce the need for continuous meetings where, according to a Harvard Business Review study, 15% of an organization’s collective time is spent. In the large company examined, just one weekly ExCom meeting accounted for 7000 hours a year (Mankins 2014).

On the other hand, a single source of truth, where everyone sees who’s working on what task, will make everyone stay accountable. No excuses like “I thought you took care of that.” This transparency will automatically reduce the need for lengthy status meetings and align the team (see The Teamwork Team 2019). Productivity is increased by eliminating dependencies and preventing the toggling between sources of information, also fostering data-driven decision-making based on that one source (Kim 2020).

2.5 Onboarding the Right Way—Some Hands-on Tips

Even a well-coordinated remote team with effective best practices does have a weak spot: integrating new members into that team because they don’t know the rules nor the people yet. To make it worse, it is the new employees in particular who are often reluctant and shy to ask for help. So how can onboarding be facilitated in an off-site team?

First of all, create a well-defined process to provide tools like laptop, phone, and access rights. Make the good impression that you have been getting ready for the new colleague, rather than too busy to focus on onboarding. Consider adding a personal message and company merchandise to the laptop parcel. These goodies will be useful and create a common company spirit. Instead of being completely remote, you may want to grant a small budget for real-life meetings in the first few weeks. This provides a chance to get to know each other better on a personal level and also shows the new team members how important they are to the company. This on-site meeting could also be combined with onboarding training or coaching, enabling the new colleagues to get up to speed quickly.

However, just one training session will usually not be enough. Therefore, one way of coping with the long-term onboarding process for new joiners is to establish a “buddy system” (Walker 2020). A more senior member of the team who understands its culture will block up to 50% of their time to be their “buddy.” That time is used for helping and mentoring the new member, as well as explaining the team’s processes and practices. This effectively fosters a sense of belonging quickly. Certainly, being a buddy is challenging. The chosen mentor needs to be able to cope with the additional responsibility and have a good attitude to their job. The new joiner should pair with the buddy as much as possible. Screen-sharing is a great way to learn during that time and, while being in contact, an uncomplicated chance to ask questions. While the new joiner is working, the mentor can offer suggestions. Every couple of hours, the roles should be swapped, and the mentor has time to work on something, while the new joiner observes.

Try to break up tasks into small chunks, as is naturally done in some working environments, like Scrum, and set clear short-term goals to reduce confusion and misunderstanding. Making the goals achievable and hitting them will be very satisfying for new colleagues, while clear communication minimizes interruptions in the workflow and fosters focus. Don’t forget to check regularly how the new hires are doing independently from the buddy program (e.g. in lunch calls or regular check-ins). Starting a new job can feel overwhelming and they might be hesitant to approach you as they want to seem competent. Also, this chance can be used to survey the level of happiness of your employees to find out if they have regrets working for you.

Keeping these strategies in mind within the first 90 days will ideally prepare your new employees for becoming part of a highly productive team where they feel welcomed and accepted.

2.6 Team Spirit—The Most Difficult Challenge

Working remotely can be isolating, so good team spirit becomes even more important than it already is. You have to ensure that everyone in the team is connected and foster a common team spirit. Even though it seems reasonable to assume your team members perfectly understand their role and function within the team, being off site needs overcommunication. Building trust takes a lot of interactions and will not happen overnight. Therefore, make sure you talk to your teammates daily. If a family member walks into the video, introduce them (coming back to using video as often as possible). Do not underestimate the value of explaining to everyone the manner in which they contribute to the project goal and what you expect from them. Ask for their opinion on topics and value accomplishments. Highlight how a milestone or increment could not have been possible without everyone’s contribution. With these practices, it becomes evident quicker if team members cannot connect with their work anymore or don’t agree on “putative” common values.

To build a stronger commitment and better relationships, getting together is in our human nature. We have discussed the importance of real-life meetings in 2.5 already, but the same holds true for more senior teams. If possible, get your team together at least twice a year to improve the morale. But try to get away from boring, old-school seminars or scary outdoor adventures that reveal anxieties. Ideally, let the team choose what they would like to try (Some ideas: cooking classes, escape room, city scavenger hunt, team laser tag). You might even consider inviting family members along as well.

But social interaction is also important in the rest of daily working life. Find a way for employees, including the boardroom, to socialize virtually if the office kitchen is not available. You can probably use the tools you already have: chat groups about hobbies, interests, favorite holiday locations, and other random things (see [Bariso 2020] and [Embry 2016] for more ideas and methods). Anything where people are able to post pictures and comment on posts is feasible.

3 Do We Have Any Tools at Hand for Remote Projects?

The obvious answer to the question above is: yes, there are plenty of tools. Aside from soft-skill tools like leadership styles, coaching techniques (driver, enabler, director, and supporter), conflict resolution styles (collaborative, competitive, compromising, etc.) and guidelines (ethical standards, collaboration codes of conduct, etc.), remote project teams can choose from an array of software tools. But before breaking down some of these in the subsequent sections, it is equally important to clarify the structure of the virtual teamwork, i.e., whether a rather dispersed or more centralized convergence comes into play: while a centralized project structure improves knowledge management, a more dispersed makeup promotes remote accessibility as well as remote updatability. They are both compatible with each other and can co-exist, facilitating each of their advantages.

3.1 Tools to Be Considered for Project Planning and Conduct

There are different types of tasks arising during a remote project, for which corresponding technologies exist. While some tasks are of a creative nature, including idea generation, or negotiations, others are of a structural nature, including routine actions or planning. The corresponding technologies can be divided into basically two categories (Rouse 2005):

• Synchronous groupware covers all tools enabling the virtual team members to communicate in real time: shared file editing, file transfers, audio, video and web conferences, electronic chats.

• Asynchronous groupware includes all tools facilitating collaboration between multiple participants at different times.

Groupware aims at the supportive control of a group process, i.e., the cooperative or collaborative leadership of the team when working out a result or the transformation of information from an initial to an end state. With that function in mind, the two illustrations Figs. 3 and 4 indicate some of the main characteristics of each tool. On the one hand, these characteristics should be balanced with the personal as well as project intentions and goals, avoiding miscommunication and any sort of surprises due to misleading tool applications. On the other hand, including the aspect of “tasks to be carried out” in the tool selection processes further reduces the degree of miscommunication and misleading tool applications. Considering these previous thoughts increases the overall chances of efficient communication within the remote teams resulting in a highly successful project outcome.

Fig. 3

(© ifb SE)

Illustration of synchronous groupware and some of its characteristics

Fig. 4

(© ifb SE)

Illustration of asynchronous groupware and some of its characteristics

3.2 When Is Best to Use Which Tools?

Now that light has been shed on the two categories of technology useful for remote projects, the question of when to use which tool during remote project tasks still needs to be addressed. There is no doubt that in the end communication and collaboration choices are strongly dependent on the teams per se, e.g., preferences, personalities, teamwork, and so forth. However, general statements can be made on the usual suitability of most communication and collaboration tools within a remote project. These statements ought to be understood as mere guidelines and should be altered according to each project and especially each team.

Table 1 Communication tool allocation to purposes

Table 1 is a summarization of appropriate tool use, while considering the relevant tasks and the characteristics of the various displayed tools. The classifications are “less suitable,” “moderately suitable” and “suitable.” For each classification in each cell there are keywords provided explaining the labeling as such. Nevertheless, as mentioned before, in the end it depends on the individual team members, the team as a whole and the project itself with their preferences, notions, goals, and many more things, requiring the remote teams to conduct extensive mutual exchanges in these topics and extraordinary prior planning as well as organizing.

3.3 Let’s Scale Up Our Remote Project!

Many factors that are also relevant for scaling remote projects have already been addressed in the previous subsections. What is meant are factors such as transparency, trust, communication, hiring, and onboarding as well as tool selection. However, when it comes down to scaling, new challenges come along with the topics mentioned and new ones occur.

As for communication, it is far from a secret that an increasing number of team members or teams results in an increasing number of communication channels. In that sense, well-established, stable, and appropriate communication channels are required. One aspect among others linked to the factors of communication, transparency, and tool selection alike, is real-time arrangements, i.e., continuous merging and delivery of work packages within a scaled virtual team demands exceptional coordination skills and the corresponding tool (Asproni 2019). The same thoughts apply to further aspects, e.g., finding mutual agreements or taking hold of structured feedback loops.

Apart from thorough planning, preparations, tech setups, goal setting, trust and availability, which all apply to scaled remote projects as much as to unscaled ones, but simply in more extensive ways, there is one factor requiring more attention here: measurability. In a small team, whether remote or on-site, the ease of measuring results lies simply in the outcome and interim meetings. In a scaled remote project, however, it is rather easy to lose track and fail as a result. Measurability with the right selections of metrics and indicators is imperative for the success of these kinds of virtual endeavor. What needs to be measured is not just the outcome, but many more aspects influencing the outcome: utilization, workload, quality assurance, team member satisfaction, etc. Appropriate measurability enables optimization processes and, hence, increases the success rate.

Another important factor is knowing the limits of scaling, which prevents avoidable project failures (Asproni 2019). For one thing, this factor applies to the number of people within a team as well as the overall number of teams and the right timing of enlarging these numbers in remote projects. That means there is a threshold in every team and project where additional manpower results in a productivity decrease instead of increase. This is also strongly dependent on the timing in which the team expansion takes place, since an already advanced project is likely to be inhibited and an early stage endeavor is more likely to benefit. Therefore, at a certain point, it is advisable to allocate more time instead of adding more workers. Then again, the factor of knowing the limits of scaling also applies to the capacity of tools. This means there is most likely a threshold here, too, above which either the tool hits its limits—resulting in system crashes and lags—or communication via tools becomes inefficient, or both. There are many more aspects of the limit factor to consider, varying from project to project and hence requiring an analysis in each project prior to scaling.

In summary, prior to scaling a remote project, examining how much it makes sense to do so for one’s own projects by considering what additional efforts and challenges are going to be faced in existing factors, what new factors will have to be included, what are the limits of scaling in each project, how can I measure the effectiveness and many more questions is strongly advised.

4 On-Site Culture and Virtual Culture: Is It a Thing?

If we try to wrap up everything that has been said about best practice and how remote teams work, the result could arguably also be labeled “virtual culture.” Fostering that culture within the project team will help your endeavor to succeed. However, there are not many literary sources offering a general framework for remote projects with a focus on culture. One could mistakenly come to the conclusion that there is no noteworthy difference in project culture between on-site and remote projects. The following subsection will critically discuss this observation by outlining key points of a virtual culture and illustrating successful approaches to setting up such a framework accordingly.

4.1 I See no Changes… Do I? A Shift in Mindset

When addressing culture in an on-site project, it looks like a relatively simple matter due to, for example, rather similar individual cultures (in the strict sense) working together, direct communication and absence of factors like different time zones. However, there is more to culture than solely geographically conditioned differences: there is also a “project culture,” even though it will naturally be influenced and co-determined by the former.

In virtual teams in particular, this project culture has to contain a shift in the mindset of each team member to cope with the complexity that remote project work entails, requiring a higher degree of transparency and trust at the same time (Panagoulias 2019). What appears to be a contradiction can be broken down as follows: trust toward team members is required to give them the leeway on how to tackle, conduct and complete their work, while at the same time maintaining transparency by involving every employee engaged in the project in the decision-making process. More ideas on promoting this trust are investigated by Paul Zak’s key management behaviors (Zak 2017). He introduces essential actions (see Fig. 5) to be conducted by management specifically with the purpose of endorsing strong mutual trust within a team or even an organization.

Fig. 5

(© ifb SE)

Illustration of Paul Zak’s key management behaviors leveraging trust

With an awareness of project culture, it will eventually become much easier to work remotely and, consequently, to hire people for your project from all over the world. This facilitates another shift in mindset, an embracing attitude of the strengths that diversity, e.g., the cultures involved, brings. With the change from on-site to remote, each (new) team member may also gradually work at different locations, embedded not only in the local culture and, thus, background but also differing more in nationality, disability, generation, way of life, personal experience and so forth.

For issues on culture (in the strict sense and in contrast to project culture), geography, habits, etc.—which are especially relevant to international projects now—different applicable models, dealing with the values of each region and offering context, do exist and can be consulted. To mention two, Trompenaars’ model of national culture differences (Trompenaar and Hampden-Turner 1997) or Erin Meyer’s eight scales (Meyer 2014) are recommended to the interested reader. However, for points such as differing personal experiences, clash of generations, etc., a substantial amount of emotional intelligence is still required to get the best out of these diverse teams. Therefore, communication within a remote project framework will always be of extreme importance and strongly linked to the established culture in a team (Coon 2017). Besides providing trust plus transparency, therefore, establishing a working communication culture is another aspect to focus on more thoroughly in remote projects than in on-site assignments, and will be addressed in the following subsection.

4.2 The Right Culture for Communicating Over Distance

Where else does culture play a role in projects? You might have heard the term “feedback culture,” but in general we could also call it “communication culture.” When we generalize what is known about effective communication from Sects. 2.3 and 4.1, specific factors influencing the way we communicate in remote projects can be found. Trust, choice of tools, leadership style, coaching competencies, conflict resolution management, planning scope, feedback culture, and group dynamics come to mind. The Project Management Institute (Project Management Institute 2013) offers five of these factors and an approach on how to improve the related communication culture in Fig. 6. It is one way out of many to tackle a communication improvement process.

Fig. 6

(© ifb SE)

Illustration of PMI’s five-point communication model

Also, appropriate leadership as well as coaching styles should be considered as part of your remote project communication culture, see (Bonnie 2017). When managing remote projects within an international scope especially, team members can have very different (cultural) backgrounds and personalities. In some cases, a diplomatic leadership approach with sophisticated communication and caring feedback may be far more suitable than being a straight-shooting coach giving direct feedback. In other cases, it can be advantageous to seek consensus in the whole team rather than acting as the sole decision-maker. A certain sensitivity, the ability to read the room and the right interpretation become more important (contextual intelligence). However, if things get out of control, the team needs a plan for conflict management over distance as part of the team’s communication (Twist 2019). One way to achieve this could be using techniques from Retrospective meetings (known from the Scrum framework) virtually and on a regular basis.

Being strongly related to culture, (team) identity remains a fundamental factor in a virtual context as well. Due to the abstract nature of working from home, the leadership should therefore not tire of communicating the vision and mission of the project on a regular basis, enhancing the identification of team members with the remote project. Once these foundations for trust and transparency are in place, combined with a conflict management plan covering various scenarios, a remote team culture will slowly start to emerge, increasing the acceptance and feasibility of the best practice mentioned.

5 Conclusion

In this article, we roughly introduced the topic remote projects, including differentiations from other forms of projects, best practice and scaling considerations. It should be stressed once again that changes in the way business works (and beyond) are not only driven by pandemics or costs, but also by ecological considerations, a change in lifestyle and better ways to handle remote work in general. Companies that adapt to these developments technically and culturally on time will be better prepared for upcoming challenges. Hence, once again, adaptation is the key to success.