≡ Menu
Pawel Brodzinski on Software Project Management

How To Suck As Project Manager

Documentation.

Recently I answered a series of questions about the project managers in an organization I know a bit. One of questions was about least important role project managers fulfill there. After a thought I came out with being a keeper of procedures.

I see it pretty often – people who care more about job being done according to procedures than about job being done well. If the person which comes to you mind is a PM who sees projects as a combination of budgets and schedules instead of people you know what kind of personality I think about.

Actually keeping most procedures, not only project-management-related but also software-development-related, requires significant effort. You need police which would enforce procedures or practices at least until people get used to them. And if people don’t see value in a specific procedure they won’t get used to it ever. This is basic reason why time tracking in software development teams always requires some kind of police to enforce its execution.

The more procedures, the more time spent on maintaining them and less time spent on the real work. You know, work which actually pushes a project ahead.

This is something which always fascinates me – how do those procedure-keepers find time to go picky on every detail of new document templates? What point do they see in discussing 5-hour schedule change for an hour? In a room filled with a dozen people. Only because this change would make the project over budget. Why is fighting about initial schedule so important, even though scope has significantly changed in the meantime? Three times.

So yes, if you really want to suck as a project manager it is definitely a way to go. You should instantly start thinking about new cool procedures which would make everyone’s life more miserable. That’s how you demonstrate your power after all.

in: project management

7 comments… add one

  • Jorge Rodriguez August 26, 2010, 3:27 pm

    Excellent post Pawel. In case you want it, here is a translation to spanish of this post http://blog.continuum.cl/archives/515

    Regards.

  • Sam Barnes August 29, 2010, 6:14 am

    Ha, really love this article, short but to the point as always. I’m a big fan of keeping things tidy at all times, as completely disregarding procedure and general organisation can quickly become the new “norm” – however, it’s all about be able to judge the organisation efforts vs. the production efficiency – like you said, there are many people who seem intent on talking about how to work rather than actually working!! These people, to me, always fall into two camps;

    1) Those who know it’s unproductive but enjoy it more than actual work and like the bonus of sounding important

    2) People who genuinely believe you can have a completely linear process that if you follow each time will mean your projects and production teams will work as smooth as a robotic car making factory line

    Both of these types of people are not my kind of people!

    Keep the posts coming Pawel, love the harsh but honest tone of your writing :)

  • Pawel Brodzinski August 30, 2010, 2:46 am

    Sam,

    Actually I’m biased when it comes to procedures. I use to say that I hate all unnecessary procedures and at least half of necessary ones.

    Anyway talking about groups you point – the first one is hopeless. The best we can possibly do in this case is to keep them as far from our work as possible.

    I have some positive experience with the latter group though. Within ISO-like process we were able to maintain our light-weight and very informal approach to software development and project management. Actually we received pretty good feedback after an audit. The only thing we had to do was to prove our approach is consistent and coherent and we actually know what we do and why.

    It appears this is something few teams following overly-formalized processes manage to deal with.

  • Philip Wardel August 30, 2010, 6:57 am

    Nice post. I couldn’t agree more. I personally believe that times when managers were team secretaries have passed. Nowadays there are enough tools to assist project managers, so they can finally become team leaders!
    This post on similar topic is in my opinion is worth looking at as well – http://www.wrike.com/projectmanagement/04/30/2010/5-Most-Common-Mistakes-in-Managing-Multiple-Projects-Learn-to-Avoid-Them-Part-4

  • Pawel Brodzinski August 30, 2010, 11:06 am

    Philip,

    I think that availability of different tools is one of factors which reinforce many of bad behaviors, enforcing heavy-process being just one of examples.

    The key thing here is choosing right tools for right tasks and this is something we often suck in.

  • Chad Renando September 24, 2010, 2:35 pm

    Good post Pawel. Relevent for just getting the job done on a given project as a project manager. Also highlights the distinction between a project manager and a production manager / quality manager / PMO.

    I find myself desperate for the time to write a procedure when we roll out the 50th system deployment, and the new guy made the same mistake as that other guy on the 43rd deployment. I believe in legitimising the reality of organisational chaos. We just need to ask if the cost of writing, training, and maintaining the procedure is greater than the cost of the risk being realised.

    Having a team of 10 pumping out unique and complex projects, it can be difficult to proceduralise operations. Working with a team of 25 to build and support ongoing systems, procedures are a life saver.

    Just two cents of thought from a guy on the interweb.

    Chad

  • Pawel Brodzinski September 26, 2010, 7:15 am

    Chad,

    There is one distinction which should be made – procedure which enforces specific organization of your work is something different than just how-to or checklist helping you with doing some task in a way you don’t omit anything important.

    Actually I’m a fan of emergent checklists, especially those which are written using bottom-up approach, e.g. by people who do the task, not by managers of their managers. But I don’t consider them as procedures in the meaning I used in the post.

Leave a Comment