Global Project? Farther Away Can Be Better!

A study of the global project Microsoft Vista showed, when controlled for various variables, that quality was not compromised because of the global nature of the effort. As many projects are global these days, that is a reassuring finding. I have often observed something a bit additional, however. In an organization that is not generally doing well, the farther you were from the home office, the better you did. So if you want a successful project, make sure it is distributed and away from the central location.

Teams were distributed globally to do software development I was hired to project manage a part of the development of a high tech consumer product that was to be sold worldwide. We had gone from a single site development project (we were, in turn, just a component in an already global effort) to having multiple sites to manage. The VP whom I worked for said he had no problem managing the effort locally, but he needed help managing the four new remote teams that now came under his responsibility. Our sites consisted of a team at the main headquarters (HQ) site, the team at our local development Center site and three “leaf node” teams – two in other countries.

No problem. While they were far away, in different time zones, with different languages, and with different cultures, this should not be too hard. I had worked multinational efforts for the past 20 years, and while they were sometimes distributed, generally we were all working in close proximity.

To help in this new development, we had all the standard tools of e-mail, teleconferencing capabilities and an intranet that allowed us to easily communicate. Our defect tracking system was global. When someone entered a defect, everyone would soon see the same thing. Our feature and project management tracking systems were not as distributed. Information could be posted and viewed by everyone on the intranet, but the system itself did not directly help with making things available worldwide. It looked like a technical challenge to set up good communications which I was sure I could do. Otherwise, it was just good software development management 101. If only it were that easy.

The first thing I did as the new manager was to take the existing component project plan and contact all the other managers, introduce myself, and ask them where they were on the delivering the software we needed for our component. The managers to contact included other components, most of which were at the main HQ site, and our teams distributed as I indicated above.

When I called each manager, I got – eerily – the same response. They were very nice and welcoming. They expressed polite surprise over the commitment I claimed they had. They said they had made no such commitment. Oh boy. I didn’t even have a real plan to pull folks together, yet I had to report status against this plan to the corporate VP by the end of the month. It turned out that this plan was not worth much, but it was the official plan, and everyone eventually just said “yeah, yeah, OK – we’ll do it.” Not having a good schedule it seems was only part of the problem (see also Get The Schedule Right – Project Management Tools).

I captured status daily and updated our globally available project plan and schedule (e.g., Microsoft Project). That was not a big thing as stuff happened daily: things got done or things went to heck. This daily update was often unpopular as folks wanted to hold back on reporting until the problems were solved. The senior level managers I worked with regularly gave me a range of generic noncommittal answers. Luckily, when I talked directly to the software development leads, I got real information on where things stood. However, I noticed over time a troubling pattern that was a bit beyond the unrealistic schedule we were following.

HQ based manager was generally caustic and demanding When I talked with the senior level manager at the main site, which was 3 hours north of where I was, I usually got rather caustic statements that everything is going OK. He also demanded on knowing if things elsewhere were going well or not. This particular individual was clearly assuming that everything remote from the HQ site must be going badly. In fact, he would often state these remote sites were the reasons his team was not getting things done as fast as they could, but they would deliver in spite of it on-time. He would also tell me I needed to spent more time with each of these remote sites, and less with his team, because that was where the real challenges were.

At my own site, the Center for our component development, we had something similar. We were way behind in producing the architecture document and APIs (the way other components talks to our component). The local senior manager was getting annoyed that the other sites kept asking for these. The leaf node sites, those that were most remote and in other countries, had a hard time making any progress without the needed information. Generally the leaf node teams settled into an approach of making assumptions,strategizing how they would adjust them once real direction came, and pressing on doing the best they could against the deadlines they had been given.

What happened in this confusion and chaos? Everyone delivered their software for the first scheduled delivery. The HQ team’s software did not even compile successfully. After a bit of pointed questioning, the software lead of the HQ team admitted that his senior manager told him to just give us whatever he had – no matter the state of it. It seems his senior manager assumed no one else would have anything and so essentially tried to bluff by submitting code and assuming everything was so bad that no one would notice. The leaf node teams all submitted working software based upon their published assumptions. However, they would not work with the architecture and APIs that our Center site just completed and delivered. Our local Center site senior manager pointed at the other teams and said “they didn’t use the APIs correctly” which is why nothing worked together. What a mess.

Cycle of delivering and integrating code from development This cycle of delivering code to integrate into our component continued regularly over the next months. While the software slowly got better with time, the pattern seen on the first delivery was consistent and came into greater clarity.

1. The team at the main HQ site was the least communicative and the least cooperative. The senior manager there continuously challenged what everyone else was doing and highlighting the problems in other site’s software. The curious end of the story for this team was the senior manager was eventually removed from the job. Once he was gone, this HQ team became one of our better and more responsive teams (they also reported directly to me for awhile). But until that time, they were hands down the least effective team. It appeared to be that way because of the constant other demands placed on them and their senior manager by the schedule induced chaos at the HQ.

2. Our Center component site was suppose to pull everything together technically and architecturally. However, their senior manager essentially stopped talking to me. This senior manager would regularly produce his own status of what everyone was doing (because everyone had to work with them through the architecture and for software builds). This status would contrast starkly with my official status. The VP I worked for once told me I had better sync my status with the local senior manager. My response was the local senior manager needed to be providing me with his updates and not trying to report his own self serving status. Since I talked directly to all the software development leads I had the accurate details. These details were not as optimistic as everyone wanted to present them. The Center senior manager largely made up a good story each time that generally alluded to how other organizations were the reason we were behind. Somewhat humorously, I came to find out that the official plan I was trying to execute was originally created by this same senior manager before I came on board. He had also made up this plan (i.e., neither coordinated nor committed with the other managers). It had gone forward and became the official plan because it fit the overall schedule. In his defense, all the other component senior managers had done something similar to fit into the required schedule. (For more on this see Honesty Is Just More Efficient – Project Management Tools).

3. The leaf node sites all delivered their software as they promised based upon the assumptions they publicly made. They had to rework their software numerous times to get it to work with the evolving architecture, but it was always software that we could rely upon. At one point another component senior manager expressed how he would love to be far enough along to use the working functionality that one of our leaf node teams had demonstrated.

Develop software far away from your chaotic headquarters I took away a general rule from this experience that remained true, at this organization, for almost the entire time I worked there. The rule was that the farther the development team was from the HQ site, the better the team performed as to schedule and quality. This was apparently due to the fact that these more remote organizations were less impacted by all the chaos at the HQ. At the HQ things could change in a moment by a conversation over a cube wall or in a corridor. That change could then change again several times throughout the day and week. These changes didn’t propagate to the remote sites very quickly. In fact, most of the changes became non-issues or changed again, so the remote site never got the brunt of the thrashing. The remote sites also worked harder at communicating what they were doing and fighting for feedback. The HQ and our Center often refrained from communicating a change because “it isn’t finalized yet.” The leaf nodes seemed to do what they did both because they were remote, and because of language, time zone and culture differences. They seemed to know they needed to constantly ask questions, regularly confirm what they already knew, and report on what they were doing. When needed information was not forthcoming, they would make an assumption locally, tell the world what they are doing, and then press on.

The notion that distributed software development was inherently “riskier and more challenging than collocated development” was recently challenged in Communications of the ACM, August 2009, “Does Distributed Development Affect Software Quality? An Empirical Case Study of Windows Vista.” They went on to say “Based upon earlier work, our study shows that organizational differences are much stronger indicators of quality than geography.” Our experience on this high tech product development aligned well with that notion and further suggested that the more remote the location, the better the development quality. Keep in mind that this organization had significant problems in the first place in the form of a completely unrealistic development schedule. In this context one could readily see the advantages and strengths of being a remote development site. An organization without as significant an issue, might not as readily see these factors.

If your organization is having significant issues, it might make sense to do project development of that new killer product in a remote enough location to keep it away from all the nuttiness of the problems at HQ.

Thank you for bookmarking and sharing these articles as this tells me which ones are the most helpful.

Filed Under Change Management, Communication, Reporting | 3 Comments

Tagged With Change Management, Communication, Project Communications, Project Management Tools, Reporting, Schedule, Tracking

Comments

3 Responses to “Global Project? Farther Away Can Be Better!”

Twitter Trackbacks for Global Project? Farther Away Can Be Better! | Project Management Tools That Work [pmtoolsthatwork.com] on Topsy.com on August 31st, 2009 3:36 am
[...] Global Project? Farther Away Can Be Better! | Project Management Tools That Work pmtoolsthatwork.com/global-project-farther-away-can-be-better – view page – cached A study of the global project Microsoft Vista showed, when controlled for various variables, that quality was not compromised because of the global nature of — From the page [...]
pliggvote.com on August 31st, 2009 11:35 am
Global Project? Farther Away Can Be Better! | Project Management Tools That Work…
Studies have shown that quality is not compromised because of the global nature of an effort. In addition, from my own experience with many struggling organizations, the farther you were from the home office, the better your project did….
Anonymous on September 3rd, 2009 1:15 pm
Idan Roth, worked for Amdocs and completing his PhD these days on this subject. You might want to contact him.

Leave a Reply

Project Management Tools | Global Project? Farther Away Can Be Better!