I started this series of articles on what I consider to be the seven deadly sins of project management earlier this month with an intro article and the first deadly sin Taking the Customer’s Word for Granted) in the series of seven. My apologies for taking so long to get back to this vehicle, but I’ve had a few other article ideas I had to get off my chest first.
In this article, I’d like to discuss the problem of trusting your project team members without question. And by that I mean taking their word for granted on whatever they tell you – the project manager. We know they’re highly skilled resources – that’s why they’re on our projects. But as the project manager, it is always our job to question almost everything – whether it’s the customer, the project team, or even sometimes our executive leadership, if necessary. The project is our baby and we must protect its success potential as such.
So what do we need to look out for from our project team? What do we need to question? In my experiences, here are some of the areas, some are obvious, some may not be so obvious.
Estimates
Whether it’s figures provided for tasks at the beginning of the project or for change orders that occur during the project, the project manager must question all estimates that come in to them. Developers are notorious for padding numbers (I should know, I used to be one of them) and the last thing you want to do is send a bloated development estimate off to a tech savvy customer who calls you on it. For this very reason it’s best to have tech savvy project managers running IT projects.
Project managers without a technical background are easily fooled by developers when it comes to estimating timeframes and efforts. In fact, I usually estimate a change order myself and then run it by the developer to get their feedback. More than 90% of the time I’m almost dead-on.
Status updates and task progress
I was going to split these two up, but they’re really one and the same. When you get status updates or progress reports on tasks assigned to your team members, ask them questions. A percent complete isn’t always going to tell you if there is an underlying issue.
Likewise, your team member may be the type that doesn’t raise the red flag until the last second when it may be too late to take corrective action. Ask plenty of questions about where things stand on the tasks your team members are assigned. The last thing you want is for the customer to ask those questions of the team member during a weekly status call and have them uncover an issue that you knew nothing about.
Customer interaction
You may find that some of your project team members are interacting with the customer on topics and tasks that you knew nothing about. You can’t let that happen – and if it does happen you can’t let it continue. There are legitimate times when your team members must work directly with the customer, but you must be aware of those efforts and be on top of the status at all times.
The problem you can run into is that if you have developer working directly with a customer contact, subtle bells and whistles get requested without your knowledge. The developer – with a big ego and confident that a little extra development work costs nothing – can end up blowing your project budget out of the water with extra work that they customer slips in behind your back.
Schedule conflicts