Project Management Studies 14th and 15th of October

on Sunday, October 16, 2011
Last Friday two lecturers, Mark Halmagiu and Heikki-Pekka Noronen, talked to us about distributed software development and team management and evolution.

Mark used MeeGo development as an example how things can go wrong in distributed software development. MeeGo was an excellent example as development teams are span all over the world in Finland, France, UK, Eastern Europe, Far East and USA. Mark said that they had only little or no overlap at all in working hours between some teams across the world. This creates a real challenge in planning work distribution. If workload is poorly split between teams who are working in completely different timezones, the other team might have to wait a complete day before receiving any information from the other team. These kind of dependencies can really stall development. Therefore it's important to split work into such packages which development is not (at least not much) bind to each other.

Another challenge was cultural differences. Cultural differences might sound obvious, but the Mark's examples were eye opening. For example, in China people didn't listen to you if you didn't have a fancy title. It seemed like they were listening, but afterwards people asked for confirmation from someone else who had more impressive title. There were also major differences in self-initiativeness between different cultures. Mark said that sometimes it required really specific instructions to get a team in Eastern Europe to start doing some tests, but once they got started, they produced results like clockwork. So even if it's clear that teams around the world have cultural differences, these examples reminded me that the problems that may arise can be quite surprising.

In Mark's presentation there were also good examples that should be considered in all projects, not just in distributed software projects. Good goals are essential to any project. They should be clearly described, achievable with reasonable time frame, lead the project to right direction, not change too often and goals should never conflict with each other. It's easy to see how project can go wrong if one or more of these goal principles fail.

Good communication is essential in order to project to be able to succeed. In the presentation, Mark told us about good examples how not to handle communication. The development teams were communicating quite well with each other, but there was some political interference in development. Far too often messages came somewhere higher from the hierarchy and teams had to change their priorities and start doing something else without any reasonable explanation why priorities changed. This effectively removes the feel of control and ownership from developers. Even in such cases where all the information cannot be told, instead of silence it would be better to deliver a message like "we are changing things for such reasons we cannot tell you, but we assure you this is important".

I think good communication is the key to success in many other areas too, not just in project management. How and what information we exchange (or decide not to exchange) with each other is extremely important for shared knowledge and understanding. Not exchanging information can also be important. Generating information waste can be so overwhelming that all working hours are used to read emails that have no real meaning for you.

I once saw a good graph describing the most usual problem in software development communication. Generally sales people are skilled communicators in customer's language whereas developers are experts in tech talk, but both parties tend to face issues when communicating in the opposite end of the graph. There's probably no need for sales to speak fluent tech and developers don't probably have to be as fluent customer communicators as sales people. The crucial point in this graph is the gap between customer and tech talk. A good software project needs someone being able to communicate fluently in this gap. Exchanging information between developers and sales people in such way that both parties get shared understanding is essential for the outcome of the project.


Heikki-Pekka's presentation was about team management and evolution. We discussed about self organizing teams, high performance teams, building and evolution of teams and how to manage different kinds of teams.

Later on after the presentation I realized how good situation we have at Humap. Our development team members have not changed in couple years, we all know each other well and each of us has shared understanding of each developers skills. This way we have been able to constantly polish our cooperation and at the moment our team works at extremely good performance. It was very good to hear about different kinds of problems in team building, evolution and management. It made me appreciate my current situation at Humap even more than I already did.