Home > Agile, planning > Project Management – the root of technical debt?

Project Management – the root of technical debt?

I’m currently labeled Project Manager. According to Wikipedia, that is defined as:

A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development.

If you read that definition, you can see that the project manager is responsible for the project. The guardian of the project. Responsible for the project being finished on time, on budget and with the right features.

Many companies are conducting their development in project management style. When introducing a new big feature to the IT environment, a project is formed and a project manager assigned. So far, so good. The introduction of project management is often a huge step forward for organisations previously just using ad hoc system development, but there are also big risks to be taken into consideration. It’s not for nothing that the agile software development movement has risen. Projects are over budget, late and include the wrong features. But even if we overcome those problems, there is still other problems with project management and that is project management guard the project, not the complete system environment. In the definition it does not say that one should look at the whole system of an organisation. And the same picture can also be found in the literature I’ve covered in my class in project management. You could bring it down to the following: make sure YOUR project is successful.

So, what does this mean. This is an example I’ve seen to often. A project is started and when the time is running out, it becomes clear that a current feature can not remain as it is when the project is completed and has to be remade. The project manager thinks this is not part of the project and refuse to include the changes on his budget, since that feature has nothing to do with his project. So, the other feature just stops working or a poor developer makes a quick fix, which works poorly.

Another example can be that a project is carried out and a new process is introduced. This can be automated, but this is more expensive. The project manager does not want this on his budget so the process is manual. Then a new project is introduced and the same process is to be used. Since the first project uses the manual process, the project manager thinks this is ok in this case too. The operations (for they are all too often the ones to carry out the manual step) starts complaining that this takes too much time and that there are room for so many errors. But the project manager thinks that automating that process should not fall on his budget.

Yet another example is when time is running out, the developers fight hard to meet the deadline. So, bugs are introduced and technical debt is built through the using of in the long run poor quick fixes. The project is completed, the final report is written. But then after a month or two, the incidents start to build up. The project was successful in itself, but the effects on the whole was a failure.

This is not acceptable. Perhaps these stories are not as common as I believe, but I keep hearing them all the time. Project management can be the root of sub optimizing and there are few tools within the project management field to cope with these questions.

If you boil these issues down, I see them as technical debt. You are harming the system as a whole to make sure a new feature is working. And this is OK if all the other systems are useless or worth less. But we all know that this is not the case. The project manager might think so, but…

I have some statements I would like to add to the role of a project manager. I’m fully aware that this can make the title misguided, but I think the issues are more important than the title.

  • We consider the deployment environment is to be considered as holy ground.
    A project manager should tread carefully on the deployment environment and guard it like it was sacred. We guard the environment to make it safer whenever this is possible
     
  • We don’t cause harm to current functionality
    We don’t introduce code which is worse than the one which was there! We don’t make things worse for operations!

I’ll probably get back to this subject, if I’m not killed as a traitor by some other project manager.

Advertisements
  1. 2012/03/12 at 8:20 am

    thanks for all information your site very ok

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: