Project Management Studies 14th and 15th of October

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.

Project Management Studies 23th and 24th of September

First two contact study days of Project Management course were interesting. Even though I have been involved in project management through my work at Humap and I have been studying it before, I learned how little I actually know about the subject in detail. First I want to share little bit how we are managing our software projects at Humap.

In Humap I have participated in managing projects among with other software developers and sales team members for roughly five years now. Our approach to project management is a result of lots of practical discussions and we have tried to remove all unnecessary parts from our project plans. We have had all kinds of iterations of our project management tool, but the current version in our intra is quite lightweight and has only few inputs.

Usually when we create a new project, we input only priority, roles (responsible, lead and project members) and start writing specifications for the project. If we know strict deadlines, then we also input end date and possibly start date too, but this is optional step. If there are no deadlines, we just do projects in prioritized order. Quite often we don't input explicit information about the project size, but usually we do input rought budget estimation to give us some picture whether we are talking about "rabbit" or "planet" size project. Because of the small size of people involved this has been working surprisingly well for us and us programmers have been able to do less worktime estimations and concentrate our focus more to implemention.

If needed, the project can be split into subprojects and for each subproject we input even less information. For subprojects we define a person who is responsible and write down some specifications for the subproject. In both project and potential subprojects we can have discussions via comments about who does what when, are there any issues to be solved or is there anything else we need to discuss about the project or subproject. Actually our subprojects contain such minimum amount of information that they could be seen more as tasks rather than subprojects.

Usually worktime is tracked only if the project isn't fixed price and in some rare occations when we want to know how profitable a project really was. Quite often in fixed budget projects we can skip this step too as we usually know quite accurately what needs to be done and how much time it's going to take. This way we are again able maximize our time used in implemention.

This model has been going back and forth between current light version and micro managing projects and tasks and using a lot of time to specifications, planning and reporting. I've learned along the way that project management can very well be adjusted according to such variables as project size, schedule and budget, amount of people working with the project, their background and expertise in required technologies.

What I realized during the first two days of Project Management course studies was that in Humap we have been privileged to work in such environment that enables us to skip parts that are commonly part of PMP. This is probably why so many terms and concepts, such as WBS, scope, change and communications management were completely new to me.

Learning about project management in detail has naturally been possible earlier too, but I didn't know what I don't know so I didn't have any need to learn more. What we are doing in Humap works for us. But now knowing how much there is to learn about project management and understanding that in bigger projects and in bigger organizations our PM model in Humap would probably not work very well, makes me want to learn more. Luckily now via this course we have a good list of resources where to start looking so it's easy to get started. In addition, through the oncoming lectures and dialogue with fellow students I'm sure I'll get quite quickly deeper into the theories and best practises in project management.

I'm really looking forward for the next contact studies in Project Management course. Until then I'll dig into the given resources and get into IPMA self assesment and planning my studies with MS Project. This is fun step too as I haven't used MS Project in many years and back then I used it only for couple of days for testing purposes. During Saturday's studies we already got into testing MS Project a bit. The first impression was bit chaotic and I felt bit lost, but once we got into few main features and basic usage, MS Project started feeling more and more natural. Once getting into few tricks such as defining dependencies using syntax like 4SS+3d (task starts three days after task 4) or defining work via 4eh (elapsed hours) the power of MS Project started to unveil. The amount of features does make MS Project bit heavy though, but I guess for defining comprehensive and detailed PM plans many of those features are really needed.

Back to school

Autumn is here and for me it means that my studies at JAMK University of Applied Sciences continue. I graduated as Bachelor from Degree Programme in Media Engineering by the end of 2006. Now I started studies in Degree Programme in Information Technology and my goal is to graduate as Master of Engineering in 2013.

I will write my Project Management course learning diaries here in this blog. You can follow them via tag project-management.