I recently found a case study written by Mark Hooper (Project Manager - University of Bedfordshire - Academic Into Business Computing Centre). It’s about my last finished project (Cardguy) and I think Mark really sums up what I have achieved with the project. At the end of the day the ABC prooved to be useful as we had a satisfied client and I received a lot of experience.
Not a long time ago we had to do a presentation on a topic selected by ourselves for the module “Software Engineering”, this was assignment one for the previously mentioned module. I choose the topic Project Management and did a research on Managing Geographically Distributed Projects.
Before doing the research I never really thought of how projects are run these days, how many problems and barriers project managers have to face. After reading a couple of academic papers I started to enjoy this topic more and I became more and more curious. How project leaders manage time differences? What about cultural differences? How the client and the developing company establish trust? How they communicate?
As you might know already, managing IT projects have radically changed in the last couple of years. Years ago, one project was usually run by the same company and usually within one building. These days the projects are distributed, work is outsourced and both the client and the company could be offshore.
Finally I choose the academic paper by: Talha Javed, National University of Computer and Emerging Sciences, Pakistan - Manzil-E-Maqsood, National University of Computer and Emerging Sciences, Pakistan and Quaiser S. Durrani, National University of Computer and Emerging Sciences, Pakistan titled “Managing Geographically Distributed Clients Thgroughout the Project Life Cycle”. (Š2006 by the Project Management Institute - Vol. 37, No. 5, 76-87, ISSN 8756-9728/03)
The authors of the paper use the 12 issues on which projects usually fail and identify 6 of them which are crucial when speaking about geographically distributed projects. These 6 points of possible failure are:
Common understanding of project domain and requirements
I think I’m not going to say something new, it is vital that the project is defined clearly from the start, unclear objectives and requirements can contribute up to 18% toward the failure of a project. Also bare in mind that the overall cost of the project may go up as (more) time is spent on defining the project but results in an end-product that meets the client needs and on the end of the day, you will have a happy and satisfied client.
Managing changes requested by client
This second point is as obvious as the first one: changing requirements can contribute toward the failure of a project. Controlling and managing the changes can consume your resources. The common experience with projects is if the clients review the progress of the projects they require additions / modifications, hence expanding the scope of the projects. (This is called the “requirements creep”.)
Managing delays from the client side
Ever heard of a project finishing well after the deadline? Good. Delays can’t be only caused from the developer side but also from the client side. If the client is not keeping the schedule developers think that the client is non-serious and/or disorganised. The delays from the clients can also lead to schedule pressure at the development end which leads to excessive schedule pressure and that reduces the productivity.
Managing Time Differences
The working hours often have a small (or no) overlap, thereby the number of ways for communicating is reduced to e-mail and voice mail (or video conferencing). As a result communication between the client and the development team reduces. It is vital that the communication structures are established in the early stages. Also, an extra care as to be taken as misinterpretation could happen between the developers-analysts-client(s).
Trust and Cultural/Language Differences
In the early stages of the projec the possibility of winning business depends on the relationship established during the marketing cycle. A good way to gain trust (and enhance the communication level) is to use an onshore coordinator. It allows the offshore organisation to meet the client’s needs better and also helps to establish a strong relationship.
Due to cultural and language differences it is much more difficult to communicate one’s meaning clearly and precisely across geographical borders.
IT managers also have to explore the culture of the given country they work with. Let me give you an example. Assume you work with a development team located in Spain and you would like to call them up to discuss an important thing at 1400. I think a lot of people know that Spanish people usually have their “siesta” from 1200/1300 to 1500/1600. In my opinion these little differences make managing (geographically) distributed projects a really interesting topic.
Feel free to download my presentation: Managing Geographically Distributed Projects
Google announced not a long time ago that Google Docs can now be used offline as well. Google Docs offline is powered by Google Gears. The new release allows offline editing of word processing documents however there are plans to expand this service to support offline access to the remaining Google Doc products namely Presentations and Spreadsheets.
Users are able to work on their documents offline and all the changes to the document will automatically be synchronised up to the online version as soon as internet connection is available.