You Are Your Best Project Management Tool

The Dilbert Comic strip is a great example of how to bring about change. No, not by being negative and skeptical. Instead, it is about being willing to say — out loud — that we are doing silly things.

Any good consultant will tell you that the best way to figure out what needs to be fixed in an organization is to simply ask the folks in that organization. Most of those things that need fixing, as to bad management practices, are known. These bad practices are the cancer that drag the organization efficiency and effectiveness down. Once we’ve rid organizations of these practices, the teams — without any other changes — shot up in productivity and morale. The simple tool we often used was to state the unmentionable: “Gee, that approach has not been working well, let’s do this instead.”

One good example is the over abundance of meetings. I’ve had more senior managers tell me that “meetings are the way we do business” and couldn’t see that they were symptoms of, for example, poor project communications and tracking. In this case we fixed these by daily publishing brutally honest project data to the whole team, rather than holding it as a secret in our hip pocket. We still had meetings of course, but they were now down to a reasonable amount — though it took awhile for everyone to finally feel it was ok not to call and require multiple daily meetings.

What Scott Adams does is take all the silly management practices and has Dilbert say them out loud. This is in essence what we need to do. Consultants/HR/PMs help to facilitate this by doing surveys or other activities that surface these issues without repercussions to those saying them. The Software Engineering Institute’s approach, when I did software maturity assessments, was to have folks being interviewed sign a joint non-disclosure statement saying that what we were told would not be disclosed in a way that would identify individuals. We actually did away with this in the assessments we did, as in my mind it only further reinforced the notion that management was inherently bad and untrustworthy. Our approached seemed to work because when we highlighted everything that needed to be improved, everyone — manager and practitioner — had things to change. This removed a lot of the finger pointing.

Another example was an organization where we were always late on project and product delivery. Always months late. Telling a project team, who had just that day received approval from senior management on a new project, that their project was destined to be three months late was not something that was well received. This conclusion was supported by the actual past performance of similar projects that showed a probability in excess of 90% that we would not achieve the stated schedule. In this particular case, no previous project had in fact been able to do something similar this fast and every one that had tried had been at least three months late.

In this particular case, I buttressed this conclusion by presenting at the status meeting a slide that showed our past performance at detecting and fixing defects in our new products. The historical rise-peak-fall trend of defects was on order of eight months which would align with a milestone where the project only had four months remaining (the beginning of formal testing in this case). That did not make the business manager happy. His solution was to say I was sending the wrong message at the beginning of the project and I needed to fix the slide so it showed that the quality/defect curve would align with the shipment date and only take four months instead of the typical eight. Not agreeing to do that (as it was objectively incorrect), he then loudly — in front of the entire project team — told me to “never show that slide again.” I did (yes, it is one of the silly things I do — that works). We eventually adjusted the schedule out by three months and we went to deliver the product on time, the first time in the memory of the organization (and our customers).

Effective project managers have the ability to say the problems out loud without being shuffled off to an obscure job where they are then let go at the next quarterly downsizing exercise. I usually “warm” folks up to the problem by showing the objective data, the disconnect, as early as possible (“gee, look at this — this could be a problem”). I often do this as part of risk management (i.e., listing the potential risks we need to monitor). Then as things start to go predictably bad to then present something like “looks like this is in fact a real problem, here is the change we need to handle this and the sooner we correct the better things will start to go.”

This is clearly one of those hard project management tools to use. However, many effective tools are hard to use which is one indicator that the tool is making a real change. One indicator is to notice what people don’t want to talk about (“never show that slide again!”). This usually means the company culture or sometimes a particular manager has conditioned everyone to accept the bad practice as normal.

Say it out loud, diplomatically, but objectively and often. Have a plan or strategy to fix it and then do it and hope you don’t get a call that Catbert wants to see you (i.e., the “evil HR director” in Dilbert).

What counterproductive practices are being done in your project that you wish could be called out and changed?

6 thoughts on “Why Project Management Dilbert Style Works”

Will,

I love Dilbert because someone (or a lot of someones) is feeding Scott Adams real stuff that happens everyday. It is funny because it is so true.

I’ve seen that the difference in performance pretty much boils down to those that can rise above this kind of stuff and get things done without all the hassle and overhead. Tim Cook said “You don’t have silos built up where everybody is trying to optimize their silo and figuring out how to grab turf and all these things. It makes all our jobs easier to we’re freed up to focus on the things that truly matter.”

Apple is good in part because they’ve apparently avoided a lot of these silly habits. If anyone does it in their own industry, they can and do become much more productive and at least a step ahead of their competitors (a step ahead, but we all work in crazy places, it is just what level of insanity we have compared to others).

Yes, I don’t put a date on articles, except for any quotations (you will currently see dates if you use your mobile phone to access the site). This is because I’m trying to focus on fundamentals where the date it is written is (or should be) irrelevant. I know of many things that worked fine for me 35 years ago that still work fine today (and people still don’t know about them and act surprised when they hear about them).

Thanks for the feedback.

Bruce

willsays:

Pretty interesting. You might be interested to hear about a colleague, who used to review Dilbert every day to see what issues would come up in weekly meetings. While it sounds like ‘good clean fun’, about 90% of the time Dilbert was relevant to something going on at the time.

Could just be that PM is ‘same sh-t different day, different subject matter’ by and large. So Dilbert will be on-track because all projects face the similar events. The difference in performance between different industries might then come back to the cultural values of your specific area (building, chemical, software, production, etc.)

One last thing. I really wish bloggers would put a date of publication on articles (thanks just my pet project for the web).