7 Sins of Dysfunctional Project Management

1. Not adapting a PM standard with written process description and templates

"Projects" have been a buzzword for decades: I go to buy some sausages, that's a project; I'm visiting my mom, that's another project; I have so many projects going on, from going out with my friends to the bar on Friday night to going into coding. If it lasts for so long, it becomes socially accepted, it's for sure accepted and spread by journalists of any calibre, but it still doesn't mean to me that it should be accepted by PM professionals. Well, project implies some artifacts, to say the least, none of which are in place in the aforementioned cases for sure. The same goes for PM as a discipline, it implies practices and procedures, as well as templates, which do not just lie somewhere, but which are used and against which projects are checked and deviations are eliminated.

If you started your journey into the PM discipline from the PMBOK, I can feel nothing but sorry, because this standard is vague and overwhelming at the same time, unless you already know what PM is and what you need. And even if you do know, reading it will bring you to tears. That's why I prefer PRINCE2, which is a lot more practical, down-to-Earth and applicable to smaller-scale initiatives. The templates are also great and available for free, as well as (my favourite) Project Management Office (PMO) process diagram.

Adapting any practice, including PM, is a change, and it includes making a top-level decision, conducting training, making PM mandatory, controlling the progress and, again, taking actions including escalations, when things don't go as planned (they won't). If you don't feel the pain of a change, you are probably not advancing.

2. Not tailoring a PM standard to the company's requirements

When I'm writing about adapting a PM standard, it's not about implementing it as is, it should be tailored to the company's requirements, and it's 80% of the work in this aspect. I'll give some examples, which are not applicable in every case, but I did it in most of the cases I build PMOs:

1. Cutting unnecessary steps and templates from the process; here we balance the resources we have and the risks we can take, still trying to implement something "in the direction of PM".
2. Deciding how to deal with initiatives, too small to be called projects, I call these tasks. You don't write a project passport for the tasks and you don't conduct regular status meetings, but you need a decision to use resources, you need some brief description of goals and a plan, and management needs PMO to track these tasks. Tasks can be distinguished by the amount of money spent on them, by the way.
3. Choosing the regularity for status meetings and PMO meetings, it's all about spending resources: too seldom can get things out of control, too often makes them completely boring, so your busy top-managers lose interest.

There's a cultural thing as well: you need to explain and I'd even say "educate" your staff what PM is, using the cases and vocabulary, the pain points in a particular company. And you also explain the rough (and probably painful) edges of living with PM using these pain points, or you return to the previous step and adapt your PM approach further, if this roughness is not justified. That's what people get paid for.

3. No gateways in place for project/phase start/close

The definition of not working PM as an approach is things slipping away. It can be negative, like budget or time overrun, and it can be "positive", like accepting the deliverables for the stage with a proper procedure or off-line meeting. You can tailor the procedures, but you don't do it retroactively. If the procedure is in place, if I were paid every time I've heard "do we really need to do this?", I'd be rich on my yacht somewhere in the Caribbean. Yes, that's the point of procedure, they work or they do not exist.

It feels right to simplify things "on the fly", but it's not. I didn't allow it, but when the off-line discussion took place, I almost always heard someone who wasn't satisfied, and you need to address these issues here and now. Formal acceptance or stage/project start approval eliminates the need to return to these steps afterwards. This returning is hell, and it's a completely different type of hell than PM is by itself – it's the hell you create yourself and you could evade.

People who created these procedures for project/phase start/close definitely had some experience in terms of knife handles sticking out of their backs; I'd trust these guys (and gals), unless you want these kinds of surprises for yourself.

Being too formal with these meetings is another trap, I've seen it. In case you didn't know, the rule for meetings in PM is "no surprises", so yes, everyone should be aware of what's going on and agree before the meeting. And if you prepare the meeting like that, you'd probably still get manageable objections, otherwise you'd be screwed.

So, to get this procedure up and running, you need the discipline to get all these top-managers to these meetings, as well as competent project managers to prepare the people for the meetings. Yes, it's tough – well, life is tough and PM is tough as well. :)

4. Not requiring PM certification from the suppliers

In PM and in management in general we often hear the term "team", and it refers to the team inside one company. With projects, you share the risks and the activities with the supplier, so it's fair to consider their team as well. And their team has a project manager, so to be aligned with this project manager regarding the basics, he/she/them/they should probably be certified project managers. From my experience either a project manager is certified, or he/she/them/they doesn't believe in project plans at all, and that's a disaster. This project manager will then relocate all the resources to the task with the nearest deadline or do some other crazy stuff. We all have some crazy stuff to do besides breaking basic PM rules, just cut it off.

5. Punishing for revealing delays

Projects always come with the bad news: delays, new problems, risks, changes and so on. Good news? Almost never heard of them. In this context, everything you can ask any team member to do is not to panic and to bring the news to the appropriate level as soon as possible. There should be absolutely no hesitation to bring the bad news and to escalate the message. According to the basics, by doing this, a person lets the whole team down. And there's no substitute for the culture, which welcomes the bad news, no matter what. There's no "HR BS" to let the team know that they'll never ever be punished for doing so. This permission and even encouragement to bring the news in is applicable for the whole team, and it's a vital PM practice. People get the real message very fast, right after the trust is broken and anyone is discouraged from bringing in the news.

6. Not punishing for revealing delays post-factum

What PM is about regarding the schedule? Well, a classic PDCA cycle: plan-do-control-act. There's something else, called forecasting or predicting, and I'll not cover it here. I'll just say that if a project manager only states the delay post-factum, it means he/she/them/they doesn't manage the schedule at all. There's no reason for that, that's the job; every drunk project manager should be able to report the critical path and the probable delays. I wouldn't put it as a practical test, though, for obvious reasons. And yes, normally I'd fire for that.

7. Not having a formal project prioritization framework in place

Resources are always limited. I had a case when I suggested pausing 9 projects out of 10, because the most important project was eating all the resources. I can also confess that I could have 10 projects without a formal prioritization framework, and I regret not having it. Things just become so clear when you have it. I prefer RICE, by the way; you could also use another framework using quantifiable effects, but you need trustworthy business cases for that. PMO is for supporting top-management in any circumstances, and these circumstances can be shocking, meaning closing or pausing a significant part of the projects. When it happens, you don't have time to evaluate, you need to make decisions, and you need to be able to explain these decisions. With a formal framework, you can give the scoring table, and the decisions become clear; that's the beauty of it.

Conclusion

The signs I enumerated sound random, and they probably are, but they uncover some fundamental things below processes and practices: what it means in terms of "modus operandi" to have project standards in place, how a sane PM culture looks like, when you fire your project manager, and how your PMO is helping the business when a storm is coming. That's all for today, folks. I wish you survive all the storms, play safe.

• Previous
  Structuring the Job Search