Everything is under control. That's what you think. Your project is running smoothly...you are in charge. The customer is happy. Suddenly, the wheels start to fall off. If you haven’t been there…that’s great. If you have, then you know what I mean.
Not everything is within the project manager’s control when running an engagement. The PM has their hand in most everything and can speak up to affect the outcome on most things not directly within their control, but as far as having total control over everything…not possible. However, they are still responsible.
So here I would like to discuss five factors that I’ve singled out as issues that are not directly within a PM’s control, but they can watch for them and hopefully take evasive action in time to save their project should these things begin to occur. In this first part of a two-part article, we will look at the first two on my list. Be considering your own list, or what you think about the list I'm presenting...
Revolving Resources. This is a scary situation to be in because it can be so damaging to both your reputation as the PM and to the reputation of the delivery organization. And it doesn’t really matter which side has the revolving resources. If it’s your team, then you’re constantly losing experience with the customer and this particular implementation…and that’s bad. If it’s the customer’s team, then you’re constantly losing your allies and having to start over with individuals on where things stand and bringing them up to speed. It’s a frustrating place to be in and that’s why it’s critical to run through the project team functions – on both sides – during kickoff and ensure that you have buy-in from the powers that be that there is the proper commitment to keep the key resources engaged throughout the project.
Starting too Soon. Ok, you have the statement of work (SOW) in hand and that's a great start...not every project provides you the luxury of having an actual SOW. You have the schedule drafted and the project is kicking off. What may start to become apparent is that either there are not enough requirements in place, or well enough defined, to really start the project, or the customer doesn’t yet fully understand the solution and how they will use it. The requirements issue may jump out at you quickly – especially during kickoff discussions. The understanding of the solution and how to use it – that one is going to take some discernment and help from your delivery team to recognize.
Watch for the signs because the deeper you get into the engagement the more apparent this is going to be and when you go to implement that final working solution, the customer is going to think you’re talking a different language if the gap in understanding has continued to widen throughout the implementation.
If you recognize it early, push to shelve the project until the customer has had more training, or reviewed requirements further, or discussed the intended solution at greater depths with their end users and business process SMEs. It’s a tough sell, but it will make everyone happier in the long run.
Summary / call for input
That's the first two in my list of five I want to share this go around. My list is long and I'm sure yours is, too. As you read through mine, please consider what you think about these and what other experiences you've had in project issues and failure points that you could share and discuss. In Part 2, we will consider three more on my personal list.