Full disclosure. Complete transparency. Effective and efficient collaboration with team and customer throughout the project. That third one sounds about right. But what about the first two? Full disclosure on everything to the team and customer? Team… probably without a doubt. To the customer… yes, but sometimes in due time depending on the issue. Complete transparency to the customer? Good question…again… it may depend on the issue, but within due time… yes, complete transparency should probably happen. Can you think of situations where this would not be the case? Immediately? Over a couple of hours or a couple of days? Not at all in some cases? Think about it while I walk us through some thoughts on these topics.
Our customers have day jobs, but still need to know
Most of the time your project customer is a sponsor for the project because it is something that falls in the scope of his normal responsibilities at his organization. Yes, sometimes it’s all about everything he does and overseeing your project and your team is 100% of what he is doing. But usually that is not the case. Usually he has acquired the project because it was assigned to him or because it is important to him but he still has 90% of his time taken up by his normal tasks that he performs on a daily basis.
We like to think that this project customer individual is available to us 24/7 day and night at any time we need his input for information or a key decision…but that is often not the case. He cares, but he may just be a figurehead. The gatekeeper. You do the work, he signs off. So he wishes you understood that he has a lot of work to do that may not have much at all to do with the project you are running for him. If you sense that is the case, then try your best to keep your needs for him at a minimum and you’ll likely end up with a higher degree of customer satisfaction throughout the engagement.
Sometimes what our customers want is just enough information
You produce detailed status reports, filtered project schedule outputs, and nice color-coded project dashboards indicating project health on everything from resource management, to budget status, to schedule tracking. It’s all there and you proudly send it off to your project customer and they say, “I don’t want to see all that detail.” Ouch. What do you do? Has this happened to you? It has to me. Don’t get me wrong, many project customers want to see that level of detail. And many of the rest at least think they do or having it in their files makes them feel better about the job you and your team are doing, because if you’re producing that much detail then you must be feeling a high level of accountability so you’re not likely going to let them down without a fight. But there are those customers that recoil at the sight of that much detail. They want you to manage it, manage it well, and tell them what they need to be concerned about. Giving them this much detail almost implies that they should find the concerns and alerts themselves…or at least that’s how they feel.
What can you do? You can decrease what you give them to match what they want to see. Or you can assure them you’ll still keep them abreast of the details verbally during weekly status calls and continue to give them this level of detail. The key is this…you need to quickly get them back to their comfort zone.
Is complete customer transparency the way to go?
So we are back to this one – and it is a tough question and the answer can depend on the situation and other project and organizational factors on both sides. I always want to be honest and open with a client. When I’m in independent consulting mode, I can do that. When I’m running a client’s project and I’m working for another organization, then I am basically subject to their rules and disclosure. I am not trying to say that organizations are keeping information from project customers, but it does happen from time to time. It may be for good reasons, may be for security reasons, may be for “cover your own behind” reasons.
Three times immediate collaboration and disclosure may not be the way to go…
The original tech solution as a bad choice. You get deep into the project and you realize that the actual chosen technical solution on a very technical project is not a good fit. It may work, but it will be more costly than expected due to some implementation issues that did not come to light during the requirements phase. Or possibly you even realize that it won’t work at all. Alert the client immediately or work on a Plan B first? Definitely work with your team on a Plan B first. Don’t take long – I’m not talking about a week before notifying the client. I’m talking about 3-4 hours maximum. They need to know, but telling them in the same day is the best… when going to the client with bad news, always try to bring an alternate solution or two so that there is some light at the end of the tunnel. Give them some assurance that you are proactively working on next steps. Otherwise, they may be prone to pull the plug on the entire project prematurely – and point the finger straight at you.
Budget problems. This may be all on you. Budget issues can creep up and strangle a project quickly. Weekly oversight, forecasting and re-forecasting of the project budget is the project manager’s responsibility. A 10% overage is usually acceptable and correctible, if necessary. A 50% overage – which can happen quickly if the budget is not maintained and watch properly – is not acceptable and not likely correctible. And a 50% overage doesn’t happen overnight. So what do you do with the customer? If the budget is causing a potential project shutdown in your organization, then you need to spend a few days in your organization figuring out if there is any way to eat some of the extra costs and keep the project going. If you must go to the client for more funding – do so. When scope creep and incomplete requirements are involved the request is reasonable and easy. If it was clearly project mismanagement, then it will be far more difficult to justify. When you have some alternatives, go to the client. If you can gain funding internally and never need to even talk money with the client, that is the preferred best route.
Organization changes or focus changes. Leave this one to your management – it is their issue and you don’t need to be the guy with the news. In some cases, I realize, there may be no other choice – you may be the chosen one. But if you can get out of being the bad guy – especially for something you had nothing to do with – then get out of it. I once had to deliver news that our CEO was a fraud and had taken his own life the night before as the feds were raiding his house. Only three people at the very top of the organization were involved and knew of the corruption, but my vice president – who was also a friend of mine (and not involved in it) and was several states away so he couldn’t be present – asked me to deliver the bad news to my two client on the 8 projects total that I was currently running for the two of them. Of course I did it – no one else could – but it wasn’t easy. In less extreme cases, it would be better coming from your CEO or similar high level position – assuming they are, in fact, still alive. Mine were not.
Summary / call for input
It isn’t always as straightforward as we would like to think it is. Eventually, it all should come out in the wash. Maybe it’s immediate disclosure, maybe it’s delayed by a few hours or a few days while you work things out with team or organization to plan the disclosure and present alternative solutions to any issues that have come up. Or maybe it’s all internal matters and you must resolve them internally and do everything possible to shield the project client from any ill effects – both in time and money. In the end it’s mostly about client confidence and satisfaction, right?
Readers – your thoughts? What do you think about these items? Do you agree? What thoughts and experiences can you share?
