The Dilbert Comic strip 2010-10-26  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 down the organization efficiency and effectiveness.  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?