Virtual meetings are easier to facilitate than semi-virtual meetings

I personally find virtual meetings where everybody in the meeting are forced to use collaboration technologies such as desktop sharing, phone conferencing and instant messaging easier to facilitate than semi-virtual meetings. In a semi-virtual meeting, the meeting takes place at a certain location with some participants on location and some joining in remotely via for example a web conference. All participants are invited to the web conference, but since some of them can communicate directly with each other without using the web conference, the communication to participants who are not physically present might suffer. In a semi-virtual, the participants who are face-to-face will naturally communicate more and with other means than with the remote participants. The typical example is when a person who is physically present at the meeting location all of a sudden forgets that some participants only can communicate via the tools provided by the web conference tool. Here's an example that happened in a semi-virtual meeting I facilitated last week:

We are having a discussion about a certain subject and one of the participant who is physically present has an idea which he needs to articulate to the others. He automatically looks for the best tool to do so and in a meeting room the most natural thing (and easiest) to use is usually the whiteboard. So he jumps off his chair and starts to illustrate his reasoning to the other participants using the whiteboard. As some participants are in the same room, he does not only choose to communicate via a tool that the participants joining in from elsewhere via the web conference does not have access to, but he also forgets to tell the participants that he is now going to use the whiteboard to illustrate his reasoning. At this point, the meeting facilitator(me) should probably make the person aware of that some participants cannot see the drawings on the whiteboard. But since doing so can also disrupt a creative process, it is something that needs to be handled with care. My choice was either to disrupt a creative process and a communication process that worked very well for the participants physically present in the meeting room, or to leave the other participants wondering what the heck the person was talking about.

What I did? I let him continue a short while until there was an opportunity to remind him about the participants joining in remotely. I also quickly made a simple sketch in PowerPoint of what he was writing on the whiteboard that I shared via the web conferencing tool. After having stopped him, I asked the remote participants if they had followed his reasoning (they answered "so and so") and then I made a short summary of it myself using the illustration in PowerPoint which they all could see. We could then continue the discussion using the PowerPoint sketch that I shared via the web conference.

Another more practical thing which is complicating the communication in a semi-virtual meeting is that the participants who are physically present won’t call in individually to the web conference. Instead they will all call in using one person’s identity and then put the speaker on. It wouldn’t work if all of them would call from their own phone or computer. But, when they share one person's identity it becomes harder for participants who are joining in remote to know who’s saying what in the other end.

To sum up; having semi-virtual meetings requires structure and discipline to follow that structure for all participants. Participants who meet face-to-face must always remind themselves that some participants are joining in remote and seek to use the communication tools which they also can use. This can in turn be a constraint to creative processes. So, to support creative processes it is even more efficient to have virtual meetings than semi-remote. Meetings where creativity is a key necessity to produce an outcome, it is probably better for all participants to meet face-to-face.

Dealing with (unnecessary) complexity

In his post "Clarify. Simplify. Implement.", Nathan Wallace presents a project methodology (or approach) to avoid or at least deal with complexity in a smarter way.

"Lack of time, politics and ego drive enterprises towards complexity. Complex solutions reflect our perception of the difficulty of our jobs, they reflect the important differences of every department involved and are an inevitable result of looking for quick wins by not challenging ourselves upfront.

As Mark Twain once wrote "I didn't have time to write a short letter, so I wrote a long one instead".

Unfortunately, most project teams take this approach, saving on delivery time and hard conversations and effectively hiding lifetime project costs in lost productivity, frustration and training courses.

Clarify, Simplify, Implement challenges this process and demands the writing of short letters. Users will thank you for it."

Radical ideas for efficient meetings

Don’t you just love those meetings that don’t have a structure, focus, expected outcome or purpose whatsoever? What you have is someone calling to the meeting – which due to unfortunate circumstances can be you – and a place and time to meet. When calling to the meeting, it is optional to specify a time when the meeting is expected to end. The reason for the meeting can be that someone expressed a desire to meet, that you have said that you should meet on Mondays at a certain time, or "I don't have anything to do, so I'll call to a meeting".

I’m not talking about ad hoc social meetings by the coffee station. No, I’m talking about real meetings during work hours. Personally, I find these kinds of meetings to be quite amusing. It is especially funny when someone – it can be anyone in the room and not necessarily the person who called to the meeting – tries to wrap up the never-ending meeting (due to boredom) in the middle of a discussion by whispering “well, I have another meeting…”

I don’t know if this is a typical Swedish way to hold meetings, but I have a suspicion that although some elements probably are universal some of them are typical Swedish. Anyway, if you happen to find yourself being in lot of these kinds of meetings and eventually start to get bored with them (like when you hear the same kind of joke over and over again), here are some radical ideas to ensure that your own meetings are efficient (besides the obvious things as preparing an agenda with meeting objectives):

• Book a meeting room that can take just as many persons as the number you have invited to the meeting. If any uninvited persons show up to the meeting, they will either have to stand up or decide not to participate in the meeting.
• Forbid all participants to bring their laptops and mobile phones into the meeting room. That will stop them from doing other things such as checking their email or sending SMS during the meeting. Build a pile with their laptops outside of the meeting room.
• Ask a few colleges (who obviously does not have anything better to do) to start circling outside of the meeting room and occasionally opening the door to see if it is empty approximately fifteen minutes before your meeting is specified to end. If your meeting is not on track by then, you will at least get a reminder for everyone to achieve something during the last fifteen minutes.
• Bring a bullshit button to the meeting and place it at a central location on the meeting table. Ask everybody to press it when the meeting is heading away from the subject.
• Provide every participant with a test before the meeting to test them if they have read the agenda that you distributed before the meeting. Those who fail get assigned tasks, such as taking notes, making sure everyone has something to drink, or watching over the pile of laptops outside of the meeting room so no laptop gets stolen.
• Record the meeting and inform the participants that you are recording it and will make the recording available to other stakeholders.

Pretty soon, you will probably not be able to assemble any people to meetings - unless it is absolutely necessary. And they people you need to meet will probably investigate other means of meeting and collaborating with you, such as chat, phone conferencing and good old e-mail. Your main benefit will be that more of your time will be freed up to get some real work done.

Personal experiences from managing virtual teams

Between 2002 and 2004, I was involved in my company’s effort to establish two development units in Serbia - first one in Novi Sad, then another one in Belgrade. The year before, in 2001, I had been business analyst in a project where we outsourced the software development to a company in Serbia and where the customer was situated in USA.

After we had managed the challenges of that project, we thought; why not establish our own development units down there? We were only around 15 people at my company (situated in Stockholm) back then and it was hard times for consultant firms. We simply saw the establishment of development units in Serbia as an opportunity to cut our development costs to increase our margins, and to be able to continue the development of our content management products. We calculated that we could hire approximately 7 skilled software developers for the same cost as one in Sweden. There was no need of a much more detailed business case than that.

I won’t go into details about the hardships that we faced during this period, but I can conclude that it was a successful endeavor even though I lost my hair and experienced the most stressful period in my life so far. It was one of those experiences that added ten years of experience in only two years.

Anyway, as product manager, project manager and requirements analyst in several projects I learned a few lessons about how to work with virtual teams for software development. Here are a few recommendations if you are up to a similar challenge:

• Expect a lot of overhead in terms of project management, requirements and test. Overall, the project will consume a lot more man-hours. Productivity will be significantly lower than if you would run the project at your own location. But since the cost per development hour is much lower, you will still be able to increase margins if the size of the project is big enough (minimum 1000 development hours).
  
• Ensure that you have a strong setup with a project manager, requirements analyst, test manager and architect at your own location. You then probably need to mirror that setup at the development unit. At least ensure that you have a project manager, lead developer and test manager at the development unit.
  
• Co-locate the team for a couple of weeks in the start of the project to learn to know each other and find ways to work together as a team. If you use the same team for several projects, you don’t have to repeat it for the next.
  
• Focus on visuals before text because of the language barrier. Use visual modeling and prototyping to communicate requirements and facilitate an understanding of what the project is to deliver. Use a common notation such as UML for modeling.
  
• Use tools that make it possible to trace the requirements to design, implementation and test.
  
• Use an easy-to-use web based issue management tool to define, delegate and follow up on tasks.
  
• Use a versioning system with branching that can be used for multi-site development.
  
• Make sure every team member has access to e-mail, IP-telephony and instant messaging and encourage them to use these when needed. But define some basic rules for when and for what to use these - you don't want to have IM conversations going on with each developer all day long.
  
• Make each developer write a diary (we used e-mail and hadn't discovered that we could use weblogs instead) about what he or she has done during the day and listing any issues they are dealing with.
  
• Set up a web based developer community (wiki) to share everything from instructions on how to set up development environments to code.
  
• Use a project workspace with a document repository where the latest version of all project and requirements documentation can be made accessible.

There is not much magic here. The magic you'll have to add to this recipe is the right people. With "the right people" I mean that they must have the right skills and the right attitude. Regardless of what you do of everything listed above, you won't succeed if you cannot get the right people to your team and keep them motivated.

How to present an upgrade?

When upgrading an off-the-shelf application or service that is configured for a client, rather than code customized, you would expect the supplier to provide a script that is executed to convert all necessary data and configurations. A script like that must of course be executed a couple of times and proper testing done in each iteration by both the supplier and the client.

This is all fine and well, but if the customer also wants to take advantage of new functionality or if new features force the client to make additional configurations, then the upgrade has to be planned more carefully. When upgrading software that is a configured service there is always the element of client and supplier activities and expectations that have to be aligned and met. Still, a project like this is small and well defined which should make it easy to plan and execute.

Considering these facts one might wonder why these projects fail so often and why the client seem surprised every time an upgrade like this fails. In my experience, the villain of the piece is - as usual when something fails - communication. The supplier presents the upgrade as a walk in the park and the client communicates internally about all new fancy functionality that will be available with almost no effort. Nothing could be more wrong - maybe it lies within the human nature to be naive when presented with the possibility to make a process smoother through new or improved features?

Some Comments on Team Collaboration and Project Management

Project management is about getting the right people to collaborate as efficiently as possible in order to achieve a common goal - on budget, in time and in line with (or, if possible, above) expectations.

It surprises me how many organizations seem to believe that project management is first and foremost about making budgets and time plans and how little effort they actually spend on creating a sound collaborative environment for their projects, even when they are using remote (virtual) teams. Project managers should not be seated in front of their laptops to create time plans and budgets with a project management bible in their lap. Instead, they should try to create an environment for their projects that fosters efficient communication and collaboration. With that in place, they can focus on defining and clarifying the goals and main deliverables of the project, finding the right people and making them connect and get to know each other. After having defined what the project is to achieve and what resources are available to it, the project manager should use the time constraints and budget to shape and trim the project.

As a project manager, it is essential to try to understand what is needed for achieving efficient collaboration within the team and with project stakeholders. James Dellow points to the following collaboration challenges for remote teams in a post about Collaboration challenges and success factors:

• "Willingness to collaborate (driver by a combination of necessity and opportunity);
• That all the people involved have the right collaboration skills; and
• Having access to and selecting the right information and communication technologies (ICT)."

He then presents the following critical success factors for creating a sustainable virtual team:

• "Control - does the team have a clear sense of direction and progress towards their objective;
• Enabling Resources - this includes providing people with time to collaborate, funding for travel when required, people to provide support and also the right work environment and facilities, etc; and
• Communications - extra effort is required to supplement the social capital that is created naturally in a co-located team through a combination of formal and informal communication."

He continues with making this important point:

"Underlying these challenges and critical success factors was the point that all these issues that can be managed, but often required forward planning (through a start-up or refresh process for existing remote teams)."

It is clear to me that a lot can be done to create an environment that can foster efficient communication and collaboration for projects, and that providing access to the right collaboration technologies is a big part of that work. In a post about team-based project management, David Coleman gives this simple and powerful example of how the proper use of collaboration tools can shorten the project execution time:

"Imagine you’re a contributor on a project and you are in the project space looking at a document and you have a question for one of the authors of the document. Today, the mechanism to deal with this is e-mail. You have to flag the document. Possibly highlight the area in question, and then e-mail your question to the author(s) in question, a process that could take days!

Now imagine the same scenario, but you had IM and Presence Detection integrated into the project software. You could see that one of the author’s is on Yahoo Messenger, you can ping them, ask your question, make the change to the document, and be done in a matter of minutes instead of days .

This is where RTC (real-time collaboration) tools really shine, in facilitating the interactions between those in a project, not cutting the task time down (although that may occur also). If you look at how the work really gets done on a project, it is the time in between the task work that really kills your schedule. If some of that inactive time can be made productive and cut way down, then the whole project will move faster."

Organizations that execute a lot of projects with remote teams should not hesitate to embrace Enterprise 2.0 technologies such as wikis, blogs and real-time communications and find out where and how these can contribute to a more efficient environment for communication and collaboration.

What It Means To Know The Business, The Technology And The People

I felt a need to elaborate a little on my previous post “Three Questions to Answer Yes to Before Starting an IT Project” where I argue that the probability of project success depends on how well you know the business, the technology and the people that are to be involved in the project. So here are a few examples of how it will help a project manager to make the project successful.

When you know the business...

...you don't have to spend a lot of time and energy on learning and trying to understand the business
...you can avoid misunderstandings since you have enough knowledge about the business context to interpret what stakeholders really want
...you can focus on the goals and deliverables of the project
...you know the politics of the organization and can hopefully manoeuvre the project to avoid major political conflicts
...you know who actually makes the decisions and can anchor the project and requirements with those stakeholders

When you know the technology...

...you know what skills to require from your team members
...it is likely that the technology is mature and proven and thereby less like to cause problems to the project
...the capabilities and limitations of that technology are well known which makes it easier to capture realistic requirements

When you know the people...

...you know what they are capable of and can put together a team that has all the capabilities you need in the project
...people tend to compensate each others weaknesses and complement strengths
...you don't have to spend a lot of hours and energy learning to know each other
... territorial pissings and conflicts within the project team are less likely to occur
...you know how to communicate with each other and can focus on communicating what is necessary instead of everything

If the business, the technology and/or the people is unknown to you or any of your team members, then you know where to expect problems and can focus your risk management efforts in these areas.

Three Questions to Answer Yes to Before Starting an IT Project

In my (work) bookshelf there is a book called “Project Secrets – Making Things Happen” by Donald Davies, co-founder of Donald Davies & Partners and project / program manager with over 50 years of experience from the IT industry. I have met him in person and even discussed becoming a partner of Donald Davies & Partners a few years ago, but I had other plans at the time (such as leaving Stockholm). Anyway, his book contains a lot of thoughtful reflections, experiences and valuable advice from his incredible long career and I particularly like his advice “Avoid three new things at one”, which goes like this:

“It is difficult to:

1. be a new and unknown company
2. enter a new market
3. introduce new product

If all three occur at the same time the chance of success is low, so entrepreneurs should not attempt it unless they have plenty of cash, enough experience and knowledge to make it happen, and time enough to meet the window of opportunity.”

I find this to be very true. The advice made me think about what needs to be fulfilled to start an IT project and here is what I came up with:

Don’t start or accept to be assigned responsibility of a project when you are in a situation where you have to answer no to all of the following questions:

• Are you familiar with the customer and/or their business?
• Are you setting together a team with known people?
• Are you planning to use a known and proven technology?

I certainly have managed a few projects where I would have had to answer no to all of these questions if someone would have asked me. I am also completely sure that these projects made me go (almost) bold. Fortunately, I have learned a lot from these projects, such as simply not accepting responsibility for a project where I cannot answer yes to at least one of the three questions above. But was losing my hair a feasible price for learning that lesson? No.