June 2013
By Bernard Aschwanden

Image: © Ratchanida Thippayos/ 123rf.com

Bernard Aschwanden teaches and consults on DITA, CCMS tools and technologies, and best practices for managing and publishing. He works with clients to analyze documentation, review workflows, convert legacy content, and identify best practices in technical communications. His business, Publishing Smarter, improves content creation, management, and distribution workflows through content analysis, legacy file conversion, training, and support.


bernard[at]publishingsmarter.com
Twitter: publishsmarter
LinkedIn: www.linkedin.com/in/bernardaschwanden


 

Delivering successful projects with global teams

Unequal time zones, dissonant expectations, and different work ethics – these are just some of the issues that international project teams are facing. So how can we ensure global team success?

This case study examines the release of the Adobe FrameMaker 10 Reviewers Guide and my personal lessons learned in working with an international team. My role was to beta test FrameMaker and to create a reviewer’s guide together with a team in India, Canada, and the United States.

Defining a team

When a group of people comes together for a project they are called a team. People of the same team share goals and leadership. Within the scope of their project team members depend more on each other than on people outside the core collective. They have a goal and are assembled to meet that goal. In our case, we were a team pulled together with a focused goal of building a specific documentation set for a project. We had our roles, and we needed to trust each other to deliver to set expectations.

Background

Our goal was to develop a reviewer’s guide. This entailed multiple versions of an interactive multimedia PDF document with video, audio, and detailed tasks. The project was to be done by a selected team of people who each had specific responsibilities to meet. Working together we expected to deliver the guide within about three months, on time and on budget. Geographically, the project involved India, Germany, California, Canada, and even the beaches of Hawaii – possibly not the most common places that come together within the lifecycle of a project. Over the course of the project change is inevitable, and it is important to understand where you started and be able to look back.

Lessons learned:

  •  Set team goals early.
  •  Keep an original copy of the project plan or charter to compare results against later.

Setting expectations

Initial communications via email helped to form our team and to establish roles. We quickly discovered a desire to meet in person – if or when possible – and to stay in regular contact with each other. The more information we could share, the better. As it turned out, the product manager, who was based in India, and myself, based in Canada, would both attend a conference in San Diego, California, so we agreed to meet there. This in-person meeting was great. It gave us a good idea of who would be in charge of what parts of the project, what our skills were, and helped to set expectations. An in-person meeting provided a good starting point to get to know each other. We took time to outline the project in general, identify who may be needed for the work, and set a plan regarding what needed to be done to make the project successful.

Lessons learned:

  • Communicate often and openly.
  • Set clear expectations for each team member.
  • Establish competence levels for all members.
  •  Have a vision for you project.

Initial processes

After our in-person meeting, we identified deliverables. There was agreement on what would be built, when it would be delivered, and what quality was expected. Initial ideas for content quickly grew to many pages. Once defined, a draft was delivered, evaluated, revised, and resubmitted. At this point we had a clear picture of what we needed and how to ensure it was correctly delivered.

Lessons learned:

  • Prototype so that each team member knows the expected standard.
  • Know who controls what part of a project.
  • Understand final quality levels.

Resource management

We needed servers, software, recording gear, and several skilled experts to help write and manage content. Since we knew exactly what had to be delivered, we could create better estimates of time, cost, and resources. This could be compared against the expected budgets that Adobe had set. Where we encountered discrepancies, we had to work together to give and take. It was clear that sometimes one person or another would pick up more or less work to help everyone succeed. That’s a part of being a team.

Lessons learned:

  • Compromise where needed to ensure teams are properly resourced and that realistic expectations are set.

The impact of geography

We started to develop materials with a team of two people in Canada, a team in India, and a head office in San Jose, California. We spanned 13.5 hours of time shift between us. Our task was to create materials, review feedback, update content, republish, share files, and track budgets. In many cases, the distance between us wasn’t the issue, but the time shift was. Stress developed over team members’ concerns about missing deadlines or not providing the right information. Timing for meetings often meant that someone had to get up very early or stay up very late and we needed to be aware of each other’s needs. We spent many hours simply trying to find hours to meet!

Lessons learned:

  • Co-ordinate schedules.
  • Compromise when needed.

Expected completion

The team expected that the project would be done by early December. When it became clear that this wouldn’t happen we moved the deadline to mid December with the hope of having completed content before Christmas. Even this extension could not be met (for many reasons), and we needed everyone to understand that there were delays, that there were holidays coming, and that we needed further extensions. Together, we re-evaluated deliverables and deadlines. The team agreed to more realistic timeframes for final delivery.

Lessons learned:

  • Conditions change and teams need to be flexible.
  • Communications and compromise make it easier to agree to change.

Project creep

Due to an extended set of topics to deliver, new formats to deliver in, and additional processes that had been put in place, the team had an increased workload, but originally didn’t have the time to complete it. What we did deliver was seen to be of high quality and met all expectations, but the volume impacted timelines. We also had some issues with the international nature of the project (time zones, holidays, other responsibilities) that impacted the delivery dates. Each member of the team had other priorities that would draw away energy and focus. By revisiting the original plans we could make changes that all of us agreed to and reset our course.

Lessons learned:

  • Compromises during a project may result in more effort, so revisit your original project charter along the way.
  • A clear understanding of project targets, and a willingness to adapt as the scope changes, results in more support from all.

Delivery

When done, we provided the legal and engineering teams with our content for review. The expectation was that minor cosmetic changes may be needed. We had managed to deliver 31 files within the restated timeline. However, the team was then tasked to also create several portfolios with cover pages, introductions, scenarios, links, and redeliver this content. People outside the core team added requirements beyond the original scope. More stakeholders emerged with specific requirements.

My own schedule had me in Hawaii for a family vacation during this time. With the new requirements we had to continue to work even from the beach! However, people accommodated the time change, and the need for personal time to relax with family.

Lessons learned:

  • Set a charter early.
  • Ensure all stakeholders are identified (including those outside of the immediate team).
  • Change happens, be adaptable.
  • Accommodate for the team member’s holiday time when possible.

Project conclusion

After completion of the project, the team decided to write a case study to identify how things had changed over the course of the project, how we dealt with these changes, and why the project succeeded. The general understanding was that change occurred when people who were not originally included in the team became involved. By remaining in constant communication with each other, meeting each other personally, and remembering that everyone involved is a person, not just “a resource”, we worked through any issues and resolved them before they became problems. The project success was due to the way that people worked with each other.

Lesson learned:

  • Projects are run by people. Teams consist of people.
  • Regardless of geographic or time divides, the people make or break the team.

Conclusion

The project taught us a lot. Time estimates shift, reviews take longer than expected, delays occur. If you can define deliverables, communicate well, support scope changes, work with competent people, ensure you collaborate well and often, set clear expectations, and commit to the project – then a team of good people can accomplish almost anything. The geographic divide was huge, but our international team worked because we understood each other, respected each other, and agreed that if any one of us failed, then the entire team would fail. We worked together to ensure team success and we each succeeded individually as well.

Since this project was completed many of the team members have moved on to other projects. We’ve also regrouped a few times and delivered as expected, applying what we learned on our first team project, and we continue to work well together.

We keep communication open, use the tools we have to their full capabilities, and – since we are global – we strive to accommodate time, culture, family, and work in order to keep a healthy balance.

Final delivery

What we provided looks sharp. We have received compliments on it, and Adobe sees value in it. The materials provide clear demonstrations to new users, people who upgrade, or to those looking to learn about FrameMaker 10. And, as a final word, the product management wrote to the team to let us know that they “love it!! A good showcase of FrameMaker as a DITA authoring tool (since we created the content in DITA), single sourcing and reuse (we re-used topics extensively across multiple reviewers’ guides) and showcases the Adobe Technical Communication Suite functionality (embedded Adobe Captivate videos, rich media, PDF and online delivery, etc.)”