This article was written for the Know How Network by Brad Egeland.
In the project management world or the consulting world no one ever really wants to say, “I told you so.” Why?
Let’s consider you’re saying this to your project client. If you are uttering those words — even if you were right from the beginning — it means the client isn’t happy, the client just paid a lot of money for something that doesn’t fit their needs, or you may look smart, but they’ll still be upset with you because you haven’t delivered a workable solution ….no matter what you said from the outset. I told you so doesn’t help. I told you so won’t make things better for you. And I told you so certainly won’t make your customer feel comfortable.
What do you do to avoid all this from the outset? What can you do differently to make this right with your customer and put yourself as the project manager or consultant in the best possible professional light with your project client and everyone you’re working with on the project?
The key is to ask good questions from the start, plan well, look for answers beyond just what the customer is telling you, and certainly involve more than just the project sponsor during the planning phases of the project. Here’s what you need to do:
Come in without blinders on.
Always try to go into every new project without any pre-conceived ideas of what the solution should be, what the problem is or what technology should be involved in the solution. Basically, come in with a clean slate. No tunnel vision – no blinders.
Treat every project like the new project that it is – treat it as a new day in your life, a new trial to overcome, a new mountain to climb. Start fresh and develop and draft a new project schedule with fresh tasks for THIS project using a good project management tool to map out tasks, resources, and timeframes based on what you know right now.
Basically, you need to forget what you’ve done in the past and look at the new project for what it is: an entirely new project.
Question everything that doesn’t seem right and question some things that do.
Nearly every project customer comes into the engagement with a solution in mind. It’s human nature to try to come up with a solution before seeking help.
• They think they have the requirements in hand for what they need.
• They think they know what the real problem is.
• They think they know what is needed to fix their problem.
As the project manager you need to look past that and dig deeper.
• Assume they might only know a piece to the real puzzle.
• Ask questions.
• Meet with their end users and subject matter experts.
• Have them map out business processes that interact with the old and new solutions.
There’s often more to it, and if you don’t find it now, you’ll be doing re-work for an unhappy customer later.
Document, document, document.
Document everything. I can’t state that clearly enough.
Ok, it’s impossible to document everything, but you get the picture. You work on detailed requirements with your project customer as you try to fine tune the real problem and document, in detail, what is needed to meet the problem or issue, and develop a usable end solution. Obviously, your team needs to document
• those requirements,
• all assumptions made,
• all risks anticipated, and
• all issues encountered along the way in order to effectively and efficiently, and successfully develop the end solution.
But it’s not an easy process, and it’s not something everyone is very successful at completing. Force yourself and your team to do this well on your project — you will never regret it.
Always get official customer sign off/approval.
Next, be sure to always present documented requirements, and a documented statement of work, to the client once you think you’ve jointly come to agreement on the real issue and what it’s going to take to create a solution. And then get their formal approval and official sign off on the documented items. This creates the baseline from which you and your team will develop a solution. Any deviations from this baseline become change orders to the project.
Without well-documented requirements, it’s nearly impossible to make claims to any change orders, and you’ll find yourself doing lots of free work and losing complete control of the project budget and schedule.