Managing projects is not an easy, straightforward task. There are playbooks, but do they really apply to any given project? No. Do they provide a basic framework to follow? Yes, in many cases. But show me an inflexible project manager and I will show you one that will fail more often than succeed. Show me a project manager who is too flexible, and I will show you one who is possibly going to be manipulated by his team or customer and end up with a project that comes in late or over budget and is not deemed a success. There has to be a middle ground. I consider myself to be easy to work with and flexible enough to meet the client’s wants or needs, but I also know when too much is too much and it may be a train wreck.
Which brings me to the title of this article… accepting what you can’t change, but also changing what you can’t accept. What does that really mean?
The customer wants what they want
This is the accepting what you can’t change part. I had a project customer on a very technical project where the customer lead was the head of human resources. He didn’t want to see a project schedule or Gantt Chart or anything like that. He didn’t want to see a detailed project status report. He wanted an issues list – that’s it. And he was stubborn about it. So that’s what I gave him. It’s not how I managed the overall project and the project team, but it is exactly what we used to drive every project meeting and he was elated. In the end, we had a very successful project and our project sponsor never felt overloaded with the PM tool pieces and reporting structure that he didn’t understand and didn’t want to understand.
Which brings me to the title of this article… accepting what you can’t change, but also changing what you can’t accept. What does that really mean?
The customer wants what they want
This is the accepting what you can’t change part. I had a project customer on a very technical project where the customer lead was the head of human resources. He didn’t want to see a project schedule or Gantt Chart or anything like that. He didn’t want to see a detailed project status report. He wanted an issues list – that’s it. And he was stubborn about it. So that’s what I gave him. It’s not how I managed the overall project and the project team, but it is exactly what we used to drive every project meeting and he was elated. In the end, we had a very successful project and our project sponsor never felt overloaded with the PM tool pieces and reporting structure that he didn’t understand and didn’t want to understand.
RSS Feed
