As project managers we try to be a value-added resource on our projects. We want to bring positives in everything we do. After all, the success of the project is ours to own, right? We succeed or we fail, and it’s our name that goes with it. Sure, I’ve certainly had projects that were failures…but not on purpose. I never knowingly took actions that would cause my projects to fail. And just like most PMs out there, some of the failures were due to things that were beyond my control.
So, let’s consider what the risky things we can bring to our projects might be. Some may be oversights, some may be intentional omissions that you didn’t think would be a big deal, and others just couldn’t be helped. Four key ones come to mind…
Let’s look at each of these a little deeper…
Negotiating too much along the way. Many projects involve at least some negotiation. Things come up, resources need to be moved around, phases need to be moved around, and requirements change. All of these can cause the forward progress of an otherwise successful project to stall. What do we do? We negotiate. Can phase three happen before phase two so we can keep moving forward? Can this resource onboard a month early because I’m losing this other resource? We seek to make things right – or at least make them work “well enough” to get by – when faced with a crisis. But too much negotiation can sometimes cheapen the outcome. Moving phase three ahead of phase two may leave you with an end solution that lacks some necessary functionality. We may not want to miss deadlines, but we never want to deploy a less than fully functional solution to our end user. Over budget and over time projects may be considered partial failures, but the project that is deployed when it isn’t fully functional will go down in history with our name on it. Be careful.
Speaking, but not listening. I always say that communication is Job One for the project manager. But communication is more than just sending out emails, making sure everyone is up to speed at all times, and relaying project status and schedule updates. It also involves listening. Listening to the team as they relay info and questions about tasks and customer interactions. Listening to the customer about needs and requirements tweaks. And listening to senior management about resource and funding issues. This list could go on and on. The bottom line is, if we fail to fully listen, we’re only doing half our job right.
Failing to plan well for testing. Testing is critical. On every project…technical or otherwise. Granted, most of what I have managed has involved technical solutions. And deploying a properly tested, high quality solution is tantamount to success. Without it you will end up with a customer who has end users suffering through a solution that does not – and cannot - produce the results they require. It cannot perform the work they need. And that goes for performance testing as well. The solution may work, but it if it doesn’t work within the performance guidelines laid out by the customer, then it is still a failure. Suggestion: using a powerful app performance testing platform ensuring you deliver the performance your customer expects. Leave enough time in the schedule – in the project – for proper testing. Think quality from beginning to end.
Trying too hard to please the project client. Finally, pleasing the customer is critical. But trying to hard – at too much of a cost – can be very risky and very costly to the project. If we focus too much on the customer, we can lose sight of the goals of the project, of the scope/requirements that we have finalized with the client, and of the budget and timeline we are managing to get to that final deployed solution. So, focus on the customer, yes…but not too much. Their wants and needs are important, but once the project is underway and the scope has been set, their wants and needs are only part of the equation.
Summary
You can’t be perfect all the time. But what we try to do is not be a burden to the project. As project managers, we never want to create a liability. So, stick to best practices, communicate well, test enough to know you’re deploying the best possible solution, and don’t try so hard to please your customer. If you do most things right, the satisfaction piece will take care of itself.
How about our readers? What acts or omissions do you see as liabilities to the project? What have you created (or failed to create) along the way that ended up derailing your project – either completely or at least partially?
So, let’s consider what the risky things we can bring to our projects might be. Some may be oversights, some may be intentional omissions that you didn’t think would be a big deal, and others just couldn’t be helped. Four key ones come to mind…
- Negotiating too much along the way
- Speaking, but not listening
- Failing to plan well for testing
- Trying too hard to please your project client
Let’s look at each of these a little deeper…
Negotiating too much along the way. Many projects involve at least some negotiation. Things come up, resources need to be moved around, phases need to be moved around, and requirements change. All of these can cause the forward progress of an otherwise successful project to stall. What do we do? We negotiate. Can phase three happen before phase two so we can keep moving forward? Can this resource onboard a month early because I’m losing this other resource? We seek to make things right – or at least make them work “well enough” to get by – when faced with a crisis. But too much negotiation can sometimes cheapen the outcome. Moving phase three ahead of phase two may leave you with an end solution that lacks some necessary functionality. We may not want to miss deadlines, but we never want to deploy a less than fully functional solution to our end user. Over budget and over time projects may be considered partial failures, but the project that is deployed when it isn’t fully functional will go down in history with our name on it. Be careful.
Speaking, but not listening. I always say that communication is Job One for the project manager. But communication is more than just sending out emails, making sure everyone is up to speed at all times, and relaying project status and schedule updates. It also involves listening. Listening to the team as they relay info and questions about tasks and customer interactions. Listening to the customer about needs and requirements tweaks. And listening to senior management about resource and funding issues. This list could go on and on. The bottom line is, if we fail to fully listen, we’re only doing half our job right.
Failing to plan well for testing. Testing is critical. On every project…technical or otherwise. Granted, most of what I have managed has involved technical solutions. And deploying a properly tested, high quality solution is tantamount to success. Without it you will end up with a customer who has end users suffering through a solution that does not – and cannot - produce the results they require. It cannot perform the work they need. And that goes for performance testing as well. The solution may work, but it if it doesn’t work within the performance guidelines laid out by the customer, then it is still a failure. Suggestion: using a powerful app performance testing platform ensuring you deliver the performance your customer expects. Leave enough time in the schedule – in the project – for proper testing. Think quality from beginning to end.
Trying too hard to please the project client. Finally, pleasing the customer is critical. But trying to hard – at too much of a cost – can be very risky and very costly to the project. If we focus too much on the customer, we can lose sight of the goals of the project, of the scope/requirements that we have finalized with the client, and of the budget and timeline we are managing to get to that final deployed solution. So, focus on the customer, yes…but not too much. Their wants and needs are important, but once the project is underway and the scope has been set, their wants and needs are only part of the equation.
Summary
You can’t be perfect all the time. But what we try to do is not be a burden to the project. As project managers, we never want to create a liability. So, stick to best practices, communicate well, test enough to know you’re deploying the best possible solution, and don’t try so hard to please your customer. If you do most things right, the satisfaction piece will take care of itself.
How about our readers? What acts or omissions do you see as liabilities to the project? What have you created (or failed to create) along the way that ended up derailing your project – either completely or at least partially?
RSS Feed
