Virtually working – managing virtual teams

Posted on 2013/05/20 by markjowen

virtual-teams

I’ve worked in a globally dispersed team with colleagues in France, Germany, the Netherlands, and the US. The team worked really well.

Virtual Teams do require a little bit of extra effort, however, to get all the players to “gel” well together. The team I worked in had regular communication, and an awareness that things had to happen differently than in a usual everyone-in-the-same-building situation. There was no water cooler, or hall, conversations that resulted in any other (remote) team member wondering what the heck was going on. There was no surprises, and each member respected the culture of the other, as well as the fact that, for most, English was a second language.

When the team did get together in the same place, it was always “business as usual” – it never felt like we were meeting strangers.

Because of my experience with working in a virtual team, my interest was piqued when I stumbled across MVT‘s web site. MVT stands for “Managing Virtual Teams”. It’s a relatively young company (4 years) that provides consulting and excellent resources focused on managing multicultural virtual teams.

As well as several courses, and other services, MVT has a list of free Team Activities that can be used to improve the communication, and work, in a virtual team. You need to register, but there are 32 pages of the activities and they fall under the following categories:

Further to that MVT offers several free virtual team Guides on such things as Project Management, Training, Human Resources and Multicultural Teams.

MVT is run by Anna Danes. and Carolina Leon Maya. Anna has a degree in Psychology and is based in Spain. Carolina has a degree in Communications, and is based in Colombia. Theses facts make me believe that they understand the kind of work environment that I described in the opening paragraph of this post.

If you want to learn about getting your teams (virtual or not) working together better, I strongly recommend that you check out MVT’s site. Now that they are on my radar I am going to explore what hey have to offer more.

MVT site
Free Team Activities (registration required)
About MVT

Four C’s to Managing Virtual Teams (coffeeshophr.com)
Even Virtual Startup Teams Must Work Closely (alleywatch.com)
5 Uncommon Tips for Managing Your Virtual Team (wamda.com)
Finding The Right Balance Between Working Virtually and Working With a Virtual Team (versatelsolutions.com)
Managing Virtual Teams (networkadvisingu.wordpress.com)

How should a “Perfect” Search project be run?

Posted on 2012/02/14 by markjowen

What follows is a post that I recently published on AIIM’s site as an “Expert Blogger”. (The original can be read here)

———————————————————————–

How should a “Perfect” Search project be run?

It was Friday evening, and Charlie was meeting his friends for a drink. They all worked in IT and had, between them, years of experience, especially in the area of enterprises and enterprise search, and liked to get together to catch up with what each was doing.

After a few pints and small talk, Charlie said “Guys, what do you all reckon would be the best way to construct a large-scale enterprise search project?”

Martin, who had had quite a lot of experience in this area, looked up and said “The main thing is that you shouldn’t underestimate what is required to get the best from a search investment.”

Charlie nodded in agreement. “But how can we help the client understand what sort of a commitment is needed?”

Ken suggested using an Agile/Scrum approach for the analysis of what the client needed as well as the development of the search UI.

“Hear hear” called out the others. Otis took the chance to follow that up with “you need someone who really understands what search is all about”. Martin glanced at him, and nodded. Otis carried on. “Someone who cares about search metrics, and knows what changes need to be made to improve them.”

Jan chimed in “I agree with you on some points. You‘ve got to make sure that you include all the stakeholders, and also educate the customer. Get everyone in the same room, and start with a big picture, narrowing it down to what is actually required. And, yes, create demo’s of the search system using “real data”. It helps the customer understand the solution better.” “However,” he continued. “I’m still careful about forcing a Scrum approach on a customer that might be unfamiliar with it.”

Stephanus put down his glass. “I’ve just finished a Phase I implementation at a client. The critical thing is to make sure you is that you set the client’s expectations and get buy-in from their technical people. Especially in security and surfacing. And I agree with Jan. There are still a lot of companies that don’t use Agile, or Scrum, at the moment.”

Sitting next to Stephanus was Helge. He began to speak. “There are a few important things. Make sure you’ve got Ambassadors – people who really care, and promote, the project. And ask the important question – ‘How can the search solution support the business so that they can become more competitive?’ It might be necessary to tackle this department by department. Get the business users and content owners together, but as Stephanus just said, don’t forget IT. And also make sure that the governance of the system is considered.

Stephanus smiled. “Yes – the workshop idea is a definite must.”

Gaston, who was sitting next to Charlie, said “An Agile approach has worked for me in the past. Creating prototypes is important. Most clients don’t know what they want until they see something tangible.” “Ok” said Charlie, “how has that worked?”

Gaston continued “Build a small team consisting of a UI designer, a developer, a search engineer, someone from the IA team, and no more than two of the business users. Having someone there from QA is also handy. Start with a couple of couple of day long workshops to go over project objectives, scoping and requirements gathering. Use one week sprints, and then aim to produce workable prototypes. At the end of the week, schedule a time where the prototype can be demo’d. The point is to get feedback about what is working, and what the goal for the next sprint should be.

Mike, the last one in the group, looked around at everyone, and then back at Charlie, and said. “Charlie – there’s a lot of great advice here. One important thing to remember is that you have to work with the client to ensure that the search solution is part of the strategy. As the others have already mentioned, work with the client and educate them. Getting all the stakeholders together for some common education, collaboration and planning can really go a long ways towards getting the necessary buy-in and commitment needed for a successful project. It also is great for setting expectations and making sure everyone is on the same page.”

Charlie was impressed. He had some pretty smart friends. “Thanks guys. You’ve all had some excellent points. Let me buy you all another round”.

The above “conversation” was all based on a discussion in LinkedIn. (Click here to read it).
Many thanks to the contributors in that discussion who graciously allowed me to write this post:

Working with Global Teams: Not all in the same room

Posted on 2012/01/23 by markjowen

This is part of the Working with Global Teams series

Previous Post: Working with Global Teams: Pesky Time Zones Revisited

———————————————

A friend of mine,Shoaib Ahmed, has an excellent blog on Agile, and Project Management.

He’s based in New Zealand, and as New Zealand is literally so far away from “the rest of the world” (said with a cheeky wink), he has a pretty good idea of some of the challenges that are met when working in a globally dispersed group.

Shoaib’s latest post goes into this in more detail. He mentions things such as time difference, culture, and reporting lines. Click here to read what he says.

Related posts:

8 Tips for Teaming Across Time Zones (openforum.com)

Different Systems and Different Silos – A Real-life Disaster

Posted on 2012/01/22 by markjowen

What follows is a post that was recently published on AIIM’s site as an “Expert Blogger”. (The original can be read here)

———————————————————————–

Different Systems and Different Silos – A Real-life Disaster

Discussions had been going on for months. Plans had been drawn up. Even though the main tasks had been itemized, there was agreement that these would still have to be refined further into the project.

Nothing had been done to assign owners to the tasks, but there was a mutual agreement that whoever could, would work on each task as they saw appropriate.

In any case, the goal, and the timeline, was clear. There was no disagreement there.

Over the weeks, considerable time and resources were committed to working through the various items that made up the project task list, and the necessary information was diligently recorded, and documented.

Progress was regularly reported to the various parties involved. This was done verbally. It involved the person who took ownership of the task describing what had been done, along with what else had to be done, and any impediments that they had encountered. If they felt it was necessary the task “owner” could describe a plan of action to overcome the impediment. The other parties involved could ask for more information, or give suggestions.

Communication was informal, but each party were confident that they were apprised of task activities, and that they knew the status of the project.

Then, one day, everyone involved, got together to “walk through” the progress of the project. This involved visiting the various locations where the tasks were done. It was, essentially, an internal, informal “audit”, and a complete day was scheduled. As is necessary for such an event, all “distractions” were removed. Everyone was asked to turn off their mobile phones, Blackberries, or similar handheld devices. An extended dinner was planned. Everyone had been working hard, and this would allow them to relax, and discuss the results of the audit, as well as talk about whether the project goal was still valid, or whether it needed to be modified.

The walk through of the first task went well. The recorded information was double-checked (obviously by someone other than the task “owner”). Everything looked good. Everyone was happy. The walk-through of the second task (identifying potential candidates for future sub-tasks) also went well.

But then, major issues were starting to appear. And these were not to do with the actual data, or even with the tasks themselves.

It turned out that each party had used their own system for recording information. This meant that the data, although present, was stored in two different systems. And in each case, the data had been recorded in a way that “suited” the person entering it. This meant that there was no “common” structure, and different metadata. And there was no way to simply “merge”, or import, the data from one to the other.

Further to this, because there was no real management of the tasks (as mentioned, it was a very informal process), it turned out that there was a duplication of activities. It appeared that some of the “unassigned” tasks, had been worked on by one party without knowing that others were also working on them. Result – a duplication of data. And, with the data recorded in two disparate systems.

To fix the “problem” would involve deciding which system would be the “master” system, and then manually entering all the data, from the unwanted system, into it. It was going to be a big job, and there was a lot of tension. The elaborate dinner that was planned was called off.

At this point, I turned to my wife, and suggested that the next time we were going to move house we need to make sure that we write everything down on the same notepad, instead of each of us having our own…

Based on true-life events.

Scrum- are there actually any rugby balls to be seen?

Posted on 2012/01/10 by markjowen

In an earlier post, titled “The Fast and the Furious – SCRUM“, I talked about how I had discovered that there is another way of doing a project than following a waterfall approach. And this new way was called SCRUM.

Yeah – I thought a scrum was something that a bunch of large men did while disputing ownership over a small oval ball. Well, turns out that, actually, there is actually a connection.

In 1986, two Japanese business experts (Hirotaka Takeuchi and Ikujiro Nonaka) published a paper in which they describe the (then) current product development process to be similar to a relay race with one group of functional specialists passing the baton to the next group.

What Takeuchi and Nonaka proposed was a different method where “a team tries to go the distance as a a unit – passing the ball back and forth”.

And this was the basis of what we know call the SCRUM methodology og project management.

You can read their paper here.

Other Great Links

Rugby and the origins of agile (lunatractor.com)
Goodbye Prince II? – Raise a DP4 for the last time (chrisdixon.net)

Agile & Prince2 – do they work together in a crisis?

Posted on 2011/07/11 by markjowen

Shoaib Ahmed has just written a post about Prince2 and Agile.

In it he describes how he uses Prince2 as the project management methodology with Agile practices to deliver each part of the project.

Shoaib lives in New Zealand, and is working with the Canterbury Earthquake Recovery Authority (the agency established to coordinate the recovery effort following the earthquakes of September 2010 and February 2011).

Can the two (Prince2 and Agile) be used to deliver a project in a time of crisis?

Read his post here.

The Fast and the Furious – SCRUM

Posted on 2011/03/04 by markjowen

One thing I used to hate was working on Projects that had no “definition”. They were usually just a case of stumbling along, hoping that everything was going according to plan (not that there ever was a “plan”). And then working madly at the end to get something that was close to what a sales person had promised a client.

Then, over the last 5 years I have learnt a more methodical way of carrying out a project. A way that ensured that the project was well defined, had suitable requirements, had appropriate milestones against which the progress of the project could be measured. This methodical way ensured that the correct documentation was created at the correct time, and followed a suitable life-cycle. Very much based on the PRINCE2 methodology.

And I liked this way of doing a project. It had structure. And is still very relevant and appropriate to many situations.

Recently I have become more aware of the SCRUM methodology. Originally I thought it was to do with the sport Rugby, and since I was brought up to worship the All Blacks (part and parcel of the culture I grew up in) I was surprised that SCRUM, in this case, had nothing to do with men in rugby jerseys fighting over possession of an oval ball.

No – SCRUM, it transpired, is a “different” way of doing a project. The more I read about it, the more I thought “hey – this makes sense!” SCRUM also has a set of practices, and a set of predefined roles. Whereas PRINCE2 has it’s Executive, Key Customer & Key IT board members and a Project Manager, SCRUM has its SCRUMMaster, Product Owner and Team. However the difference is that, while PRINCE2 is a process-driven project management method^,SCRUM is reactive/adaptive method.

This is highlighted by the fact that the SCRUM methodology involves several sprints - periods of two to four weeks – where the team work on creating a potentially shippable product based on high-level requirements.

Obviously this way of working is not suitable for everything. I mean, just imagine a company building a motorway, or a high-rise building, where every four weeks that make changes based on “high-level” requirements. In those situations, you do want your processes.

However for smaller projects, such as developing a corporate portal, or similar, the SCRUM methodology seems to really make sense. Especially when you are relying on requirements from users who don’t really understand, or know, what they want. In this case, the build it, and then “rebuild/modify” based on feedback is a faster way of working.

I’ll be the first to admit that I am no expert when it comes to SCRUM. Heck – I’ve really only “discovered” it. There are some pretty good references on the internet. (See below).

Reference:

———————————————————————————————————————————–