In projects it’s important to focus on results. The business case is the main result we want to reach. But the teams also need to book smaller results, contributing to the business case, the work packages. Without finished work packages the business case is not fullfilled. So as a project manager I have to focus on getting the results, within time, budget, quality, accepted risk, etc.
So what to do when a work package is delivered later than planned or with a lower quality than agreed? Well, that depends. Of course there is a margin. While giving the work packages to the teams I am used to keeping a time margin, which means that some delay is possible, lower quality can be fixed in the time margin. So sometimes a problem with the delivery of a work package does not immediately mean a problem for the project, because it can be fixed within the overall planning.
But what if a team delivers the work packages not a as agreed for a longer time or with a difference too big to correct? Well, then they run out of tolerance and it is becoming a project problem. So when that happens most important is to find a way to have the team manager sticking to agreements. Unfortunately in IT the most used solution is overwork, the team has to work evenings or weekends. And I really hate it when that happens. On the other hand… why does it happen? The team is not delivering according to agreements (read: accepted work package). So it’s the team that feels the consequences.
Asking the team to work evenings or weekends… does it make you a good project manager, because it’s sticking to agreements? Or does it make you a bad project manager, because you don’t seem to care about the team? I guess I know what the team thinks (see the title of this post), because the team always has good reasons to not deliver according to planning. Work was estimated wrong, the experience level was too low, sheer bad luck, etc.
Probably a good project manager gets the work done this time, but also helps the team in finding out what wend wrong in accepting and delivering the work package and how to fix that in the future. If this works out nice the cooperation between the team and the project manager goes better next time. If not, either the project manager is not as good as he thinks, or the team is uncapable of learning from mistakes.
Filed under: Componence, Project Management | Tagged: Prince2, team management
IT is a funny kind of work, because it is so much in the hands and espescially in the minds of the person who is writing code. And in writing code, well there is just a lot more uncertainty than in physics of chemistry.
Espescially in Portal / integration projects where many different services, systems, people are involved, the chance of wrong estimations is just high. That is why I invest time myself to really try to understand what needs to be done and to be able to make estimations myself without having to just trust on a developer’s estimation. And if you succeed in that, then usually you will be able to decide on the margin that you calculate on top of these estimations. And even better, hopefully you can ask the right questions back to the developer to validate his epectation.
But the above takes time, so a second approach is to make sure that a development team really understands and shares my pain if a delivery is too late or doesn’t meet the quality expectations. Because 1 thing is certain, these situations will occur in such complex projects. And in all those cases the best remedy is to know that the person on the other side will everything in his/her power to help you. That kind of bonding is what can make real good teamwork.
So in this case I would suggest you plan more time to work side-by-side with the team, with the goal to really create understanding.
))
I would distinguish 2 cases here:
1) The team could do better but did worse. This can happen very often if a team is not composed of good guys or if the team manager on that side is not really a running engine of that team, etc. In this case you just need a good “feel” on people attitude. You’ll need to be there in-place and to watch carefully to detect who are not good enough to work with you and should be thrown far-far away. When team is destructed, not-motivated than making them overworking on weekends will not really help. They can even make a look that everything is good inside. I believe that regular personal visit to the team and spending with them sometimes a week in a tight cooperation (just sit with them in one room, don’t concentrate on humor and fun-side of the work and keep an eye) can prevent.
2) Team is good, you trust each head there and you know PM is a PM there BUT project is really hard. For example this can be a development of a cutting-edge technologies system where experience plays a lot and 90% of you good people are under-qualified. Currently I run part of the project with quite complex Flex front-end and sometimes quite complex Java backed. I have a release soon and in one most complicated module I still have some critical bugs. 2 months I had a very qualified guy in my team, just a star and he developed the framework of this module. Now this guy went to work another thing and if I put on my PM mask I would only be able to tell my guys “You can’t do the thing, come on weekend and on the next weekend. We must deliver this.” But would it help? NO. They are good guys and they do EVERYTHING possible. Sometimes the complexity of thing to develop is just to high for a particular person. So I started to work with them, to code Flex and put really a lot of my time into this. Thanks God I like it.
I really enjoyed that moment, much more than I would be able to appreciate the thing being just a PM. He will not be able to fix the bug without me, neither I would be able to do myself. Working together and feeling how they feel is the only way to really understand.
Today I’ve spent 4 hours just sitting with one of best dudes, debugging and analyzing one particular problem. And finally near 9 o’clock in the evening we killed the bug
I’m the first to be on a weekend if thing is still not good enough. And they respect me for this. But I’m not just sitting in a chair and telling “come’n guys ! we need to do!”. I’m doing.
If you see that case is 2 and team is really good and still you don’t meet the goal… then just accept it. Team is not guilty for a thing that just impossible to meet
The funny thing is … at this project for another client, I gave really short deadlines. But the team, despite of many issues (http://componence.wordpress.com/2008/11/28/offshore-lessons-learned-feedback-from-our-jaipur-unit/) decided themselves to work 10 – 12 hours a day to catch up.
And when I came to Jaipur, they were ahead of planning, while 1 weeks before they were still behind the planning. And they even did more themselves. So a team can find the spirit and dedication to satisfy the client.