Seems like an odd concept, I’m sure. And I’m not here to say that your project team can’t be trusted. As a project manager, you’ve assembled – or more likely been assigned – a team of highly skilled and very competent and generally trustworthy and well-meaning individuals. But that doesn’t mean they always act in the best interest of the project. That doesn’t mean they always make good decisions…remember, they are busy, likely working on several projects and have assignments of their own from their own supervisor.
So, as project managers, what must we be aware of – what must we be looking out for on our projects? In other words, what could our team members screw up? How could they harm – even unwittingly harm – our precious projects?
For me – at least from my own experiences and from what I’ve witnessed on collegues’ projects – concerns with team members fall into three main categories that I’d like to discuss in more detail below…
Careless time charging
Team members can sometimes get lazy with their project time charges when they’re working on multiple projects and can’t remember – in detail – what time they spent on each project. Use your team to help manage the project budget so that they are aware of how important their accurate time charging is to your project’s financial success. If you do this, I guarantee you’ll have less casual time charging to your project and your budget will be healthier for it.
Gold plating work
We may not know it…in fact our project team members may not know it, but they may be killing our project budgets by gold plating their work either on their own or at the request of the customer. Big egos want to create big things. Requirements are one thing, but to really deliver can be more enticing. Especially if the customer is right there indicating how they want things tweaked and how impressed they are with the developers’ work.
If your developers are spending a lot of time working directly with the customer, expect that there may be a possibility that their trying to slip some extra work in…asking your developers to add some ‘minor’ features that aren’t really part of the requirements. Case in point...I was leading a revamp of an organization's human resources management system. They wanted new functionality added that allowed for the entire interviewing, offer presentation, candidate response, and compensation package to be input, tracked and modified as needed. It seemed simple enough and together with the customer we had thoroughly documented the necessary requirements. Still, I caught two developers working closely with end users in HR who were adding functional requirements along the way and it was damaging my project budget...those changes needed to come through me and they needed to be documented as change requests with money attached.
This may not even be intentional on the part of the customer, but it’s your job as the project manager to educate your team and to get them to stay within the guidelines of the project requirements…because that’s all the project budget covers. Anything else can send the project over budget and towards financial failure. Many miscommunications can be avoided by focusing on a better central point for storing and sharing project information. A sharepoint solution is always a good option - made even better if you choose to upgrade to sharepoint 2013.
Task prioritization
Here’s another instance where harmless interaction with the customer can turn into disaster. If your developers are working closely with the customer and you’re not closely monitoring what they’re working on and when, you may find them working on tasks out of order according to the priority you’ve assigned to the task. They may be following the customer’s preferences without realizing it. It’s your job to keep educating your team on what tasks they should be working on and told hold them accountable to the tasks they are responsible for each week.