I hate that question. I never ask a candidate that and I assume they know about what the position is paying or should pay. If I end up offering it to them and they turn it down due to the salary offer then if I want that candidate bad enough I can offer more. Otherwise I can go to candidate #2 or 3. It’s just a bad question and should not be asked.
Much has been written about political polarization in the U.S. and how a heated political climate has drawn a line in the sand between voters.
But heading into the 2020 presidential election, self-censorship also is on the rise – including at the workplace, where some people fear sharing their political views. Nearly a third of employed Americans worry they could lose their jobs or be passed over for career advancements if their political opinions become known, according to a Cato Institute survey.
For business leaders trying to build a strong culture, knowing how to manage political expression and discussions in the workplace is critical, says Joel Patterson (www.JoelPatterson.com), a workplace culture expert, founder of The Vested Group and ForbesBooks author of The Big Commitment: Solving The Mysteries Of Your ERP Implementation.
“Unfortunately, things have gotten so divisive that even if somebody just wears a shirt or makes an innocuous comment, somebody is going to get upset,” Patterson says. “When people at work are afraid to say anything political, that fearfulness isn’t conducive to a cohesive work environment. Rather than ignore it or futilely try to shutter it, business owners and managers are better off having a plan to deal with the political dynamic so it won’t disrupt their business and drive their employees apart.”
Patterson offers tips to help business leaders manage political discussions and tensions, and keep politics in proper perspective, in the workplace:
“Handling political talk isn’t something business owners and managers should be afraid of,” Patterson says. “It’s an opportunity to ease the tension their employees feel and remind them that no matter their differences, they can remain strong together.”
The customer’s perspective
You know the story – a customer comes to you with a project and they have it all mapped out. They know what they want. They know how they want it. They know the technology they want to utilize for the solution. They may even know how much it’s going to cost and how long it’s going to take.
The project manager’s perspective
Now let’s look at your situation. You’re a busy project manager and your plate is full. You’re juggling six projects already with six different project teams and six different customers. That means you’re already babysitting a lot of people and making a lot of things happen. This new project comes to you with everything planned out in advance by the customer. Talk about easy street. And after all, it is the customer’s money that’s being spent so they must know what they want. Who are you to tell them what they should be spending their money on? And if it all goes up in flames, it’s their fault anyway because this is what they asked for.
STOP! It’s sounds wonderful, but do not go down that road. It’s incredibly tempting to take the easy road and just do what the customer wants. At the end of the day, it’s their request you’re implementing so if things go south, you can blame it all on them. WRONG! When the dust clears at the end of the project and your customer is left with a bunch of frustrated end users because you rolled out a solution that they asked for, but not one they needed, then it will be your head on the chopping block. Remember, it’s always the project manager who has the target on their head. Don’t kid yourself that an unhappy customer will accept the blame. No, it’s your job to look at their issues and ask the right questions to find out what they really need. It’s not your job to just placate the customer.
Here are four steps that the project manager can go through to basically morph the project from the customer’s wish list into a real solution. There are variations to this and what works best may depend on the customer and what your organization’s processes mandate, but to some extent this is basically what needs to happen. It may be easy, but sometimes it isn’t because the customer may have to hear some tough news – like their ‘real’ solution is going to cost five times what they were originally expecting.
Hear the customer out
Obviously, the first thing your project team must do is ride it out with the customer. Sit down and go through the package you’ve been given. Accept their requirements, their wide-eyed ideas of how things are and how things should be, and generally be all ears. Ask questions, but don’t be combative. Don’t deflate the customer’s enthusiasm at this point because they may really know what they need. At this point it’s your job to review the requirements they’ve documented for you and try to get some more detail attached to them. You really don’t know their business yet.
Interview the real users
As the project manager, it’s critical that you’ve built the proper amount of planning time into the schedule. Even if it seems like it’s all planned out and the customer has everything under control, you have to assume that’s not the case. So, now it’s on to the next phase of the planning process. Ask you customer to gather subject matter experts (SMEs) and end users (they may be one in the same) so that you can interview them. After all, you need all sides of the story, right?
Before you show these individuals what you and your customer have compiled so far, find out where things stand from their perspective. Discuss the goals of the project and see if they line up with what they need to really do their job well. Once you’ve done that, then you can bring out what you’ve documented so far. Show them the requirements, the potential solution, and get an understanding of the ‘gaps’ that still remain between what the customer thinks they need and what their end users really need.
Revamp the quote
Assuming you found more than just a little ‘gap’, you must now go back and rework the project schedule, the estimate, the timeframe, the resource plan …. basically everything. Make it as strong a case as possible because if you’ve found a significant gap, it’s going to take solid numbers and documentation to back it up if you’re going to convince the customer that they were way off in their original perception of the problem and the solution.
Break the news
Now it’s time to regroup with your project sponsor or customer project team. It’s time to present your latest findings to them and go through what you believe to be the ‘real world’ vision of the project schedule and cost. Remember, you can’t toss everything out from your original work. There’s that outside possibility that the customer won’t signoff on your version of the ‘real’ task at hand and will instead require you to move forward with their plans.
If that is the case, then you have a tough decision to make … or your company leadership has a tough decision to make. Do you go down the customer’s path with them knowing you may be delivering the wrong solution and laugh all the way to the bank? Or do you end the project right there knowing you’ll never make them happy? My preference is somewhere in between because I believe that in most cases, with the proper presentation you can sway the customer over to the right solution. But this is not always going to be the case and there are times when you have to cut your loses and say goodbye. Ending the relationship at that impasse rather than risking permanent damage to your reputation is usually the best path to take.
It’s not always easy to take the steps necessary for the PM and team to get from the initial project request, through to the real problem, define the requirements and provide a satisfying solution to the customer. You want to trust that the customer understands the issues and can figure out what is best for them, but that is not necessarily the case – that’s why they brought in the experts in the first place. You just have to make them realize that sometimes. Just remember that there's almost always more to the underlying issue that necessitated the project than what originally meets the eye. And if all you do is provide a solution to what they originally request without going deeper, you can easily end up with a dissatisfied customer and frustrated end users at the end of the project.
Never forget that when the project gets to the 11th hour and the SMEs or end users are testing it out and are telling their superiors that this solution doesn't do the trick, the customer will come back to the PM looking for blood. It doesn't matter how much they said they knew what they wanted ... the bottom line is the PM didn't deliver and that is what the customer will take away with them.
There’s no question that we are in the IT consulting business to make money, right? We can’t feed our family on fun and professional growth. The dollars must keep coming in – otherwise we have to start looking for something else to do.
Given that, the thought of turning down business is a hard thing to fathom – especially in this economic climate. Recovery?? We’re truly not there yet. It could be years...who knows? So, in the mean time we all struggle to remain viable while trying to pick and choose our projects and our clients – if we have that luxury – to the best of our ability. We try to only take on customers who seem reasonable, ethical, and won’t drive us insane. Does this sound familiar to you?
Hooking up with the client
Through whatever process you choose, you’ve hooked up with a potential client. It may be a situation where they found you from a professional article or professional posting or possibly you found them when you contacted their organization offering your services. Or even better, maybe they found you through a referenceable customer of yours. However it happened, it happened. And now you’re face-to-face with this potential client discussing their needs, high-level requirements and business processes and trying to determine three things: 1) is this work I can do, 2) is this a project I want to take on, and 3) is this a client I want to work with. #1 is should be fairly easy for you to answer after a brief discussion with the potential client. The harder questions to answer are #2 and #3. You don’t know much about their business and their employees yet and you don’t know much about your direct customer contact. You have no idea if they are going to be easy to work with or difficult to manage. And you can’t determine really at this point if they are ethical or unethical.
I will say this – if you have a gut feeling early on that they may be unethical or you feel uncomfortable with them…don’t move forward. I can attest to the fact that, without exception, every time I’ve had a discomfort level with a client or even a direct employer and then moved forward with them anyway, I’ve been sorry.
You’ve made the wrong choice
There will be times when you determine that you’ve made the wrong choice. You’ve decided to move forward with a client who is or is going to cause you lots of headaches. They may be unethical. They may refuse to pay for services rendered even though you’ve delivered good work. They may continually try to push scope but balk at paying more. They may call you at all hours of the day and night. Whatever the problem or frustration, you’ve realized you made a poor decision to work with them.
I had one client who I had misgivings about early on. The reason why I decided to move forward with the work is mostly due to the fact that I had maintained a relationship with this potential customer for six months trying to get to the point where they needed my consulting. When it finally happened, I ignored all of my misgivings and moved ahead. Bad call. They brought in clients and lied to them. They took them out partying and then discussed the lurid details during face-to-face client sessions with them. Too much Las Vegas fun, not enough professional work – and that’s not my style. And in the end, they abruptly ended the consulting engagement owing me over $2,000 in consulting fees. Unethical? Yes. Stupid decision on my part? Yes….I take full responsibility.
The exit strategy
So, if you find yourself in a bad client situation, what do you do? My recommendation, in order to not start bad word of mouth about your services, is to not end anything abruptly. Look for an out – possibly a key deliverable coming up or the end of a phase or milestone in the schedule. At that point, make sure you’re paid up to date, and then break it to the customer that you have another pressing engagement and you can’t move forward any further on the project.
Of course, you must first ensure that you’re not breaking something in the contract that may leave you facing legal action. If that’s the case you’ll have no choice but to continue with the project. But if you can find and out, take it. And to leave things on the best grounds possible, suggest another consulting contact as a possible replacement – even if they may be remotely located in another part of the country. At least you’ll go out offering a solution.
Also known as “How to Win Friends and Influence People.”
Rewind to 1998 – my first consulting gig as a project manager. I had previously been content to tirelessly toil for my company that I had worked at in a W2 position since graduating from college. Feeling underappreciated and underpaid, I started to check out other opportunities and even got hooked up with a recruiter. When I landed a 1099 situation at a major engineering and aviation firm at an hourly rate that doubled my take home pay, my first request was to go onsite prior to my start date and meet the team that I would be working with. That took the hiring manager by surprise, but I think he was impressed that I wanted to come in on my own time and talk to the team before actually working with them.
That first gig – intended to be a six month stopover – lasted three years. Another consulting situation, where I was asked to come in and rescue three miserable implementations, was intended to be a 4-5 week quick fix. I ended up staying there for nearly a year and I’ve had repeat engagements with them. There are others as well.
The message I’m trying to get across is that, as the IT consultant coming in from the outside, you’re often looked at as a guru … an untouchable … or an alien. It kind of depends on the makeup of the organization you’re heading in to. But if you come in as a real person – albeit with considerable expertise and sometimes even the reverence of those in the organization – and infiltrate the organization in ways they aren’t expecting, you can often find yourself so needed they can’t and won’t let you go.
There are three ways that I generally go about doing this:
#1 – Meet with everyone you can and find out what they do
If you’re consulting with a small company, get to know everyone and find out what they do and what’s important to them. It’s fairly easy to do this through even casual conversation. If you’re consulting with a larger organization, get to know as many people in your department or division in the same way. One – you’ll become a friend that they can’t imagine working without. And Two – you’ll both find out more about each other. You’ll know what their job needs are and be able to offer advice that may end up adding work to your current assignment thus extending your contract. And they’ll know more about your expertise which can also lead to additional needs and an extended stay.
#2 – Be a good listener and pickup on opportunities
If you’re working fairly closely to those around you, you’re going to hear things about projects, frustrations, etc. Don’t be afraid to jump in with work experiences and advice. Telling them you’ve been through it before and did ‘x’ to make it work will likely land you right in the middle of what they’re doing. That process has worked well for me to add additional projects to the existing projects I’ve run for clients I’ve consulted for and it’s always extended my contract and led to repeat engagements with the companies.
#3 – Know the CEO
Especially in a smaller organization, you can become the right hand man for the CEO. Consider the situation with the organization mentioned above where I saved three failed implementations – I had only been on board for about a month before the CEO started to talk to me about heading up a separate portion of the organization and running an offshore development team for them. His plans were a little too big at the time, but you get the picture. I made myself indispensable to the company and to that CEO and it led to a much longer engagement with them and repeat business.
As consultants, we always need to be looking for the next gig. But sometimes that gig is right there were we currently are. You just have to see it … or hear it or look a little harder for it. It’s always easier to find more work right where you are than to leave and find a new place. You just have to be proactive and be ready to offer unsolicited advice. It can definitely pay off in the end.
Most tech books are what they are: a boring logical take on a topic we've all covered a few times already. Disappointment at the hours you can't get back for the time you just spent reading a book that didn't really offer you anything new.
And then there are others that cover a timely topic and manage to both keep it cutting edge and interesting. My latest find falls into that category, thankfully. The title is “Digital Project Practice - Managing Innovation and Change" and it is a collaboration of work from 13 top authors and experts in related fields...
What is actually meant by Digital Project Practice?
What does Digital Project Practice mean? You could define it like this: Digital Project Practice is the (applied) art and science of managing technology related projects from concept to completion, within budget and using a certain amount of resources. It involves planning, delegating, tracking, reviewing, and measuring results — often done using project management software. The goal of every project is different, but the overarching objective is to grow business and see valuable ROI from the project. Types of projects can range from online projects to streamlining complex enterprise processes.
This book dedicates a good 25+ pages right out of the gate on a pet peeve of mine on the topic of failed projects, what the perceptions are of project success and failure and is it really failure. I won't give any of it away, but it is great material and great thoughts on the subject. If you're a seasoned PM professional you'll know the frustration surrounding the notion of project failures and successes...
If there’s one thing I’ve learned through the popularity of some of my own articles is this – focusing on PM problems and challenges and trying to address how we meet those problems and challenges is something that really resonates with the readers. This book definitely does a great job of presenting this type of material surrounding digital projects and you'll be left in a better position to deal with challenges of project change. I’m not saying that misery loves company – but I am saying that we all face these challenges as project managers just about every single day and any material like this is something an experienced PM looking to manage their next project better can devour and use to extract good, practical and helpful strategic info. You’ll enjoy these pages… trust me.
Great quote from later in the book when discussing some essential reading on managing diverse teams. “Project management is not a profession but an essential skill in achieving career success.” Nailed it – perfectly sums up how PM is really much more than a profession – it's more like a way of life and a way to manage your career over the long term. Great read.
The pros for me in this book are personal and professional preferences. It does a nice job out of the gate coming from a personal perspective from each author using experiences they've had along the way. That allows you to immediately connect with the authors and that's how I've always liked to connect with my readers over the years.
Also, all concepts about Digital Project Practice are discussed mostly in a team concept which I find to be a necessary project management view. Project Managers are essential - in my opinion - but the success, failure, communication and progress is a team function... not an individual. Good job.
The pros list could be much longer – and it is – but this review isn't meant to be the size of a book itself, so I will stick to three. You'll leave with a good understanding of how Digital Project Practice fits into to today's PM world and where it's going tomorrow. I consider that essential to really being useful as we are growing and learning and working to be more successful project managers.
There really aren't any in this book. The only one possibly being that it is a more technical rather than casual read for the average reader of this type of material. Don't get me wrong it is still a personal and experience-based presentation from each other. But that's likely just me as I've been writing more casual and from the hip type articles and ebooks for a dozen years – rarely more third person type content other than a few white papers here and there. It's more my style and that's just me. What it lacks in casual reading it makes up for in content, detail and useful insight.
This book is applicable to any level of experience for the project manager. New, very experienced, interested in PM – all levels will enjoy it and find their own information to take forward and use today and beyond... and keep referring back to this work for helpful information and insight for future successes. It's an excellent and relevant collection of thoughts from several experts in the field all in one place. Win. I highly recommend this book and you'll find yourself going back to it often.
There are probably a million possibilities for subtitles for this article. “If so, where can I stuff the body?” comes to mind. So does, “Surely there’s a mental institution somewhere that’s missing a patient.” But seriously, have you ever been in a situation where you were reporting to a PMO director and you wonder what value this person brings to the table? You romanticize about how much more productive you would be if you didn’t have to jump through his hoops. Better yet, you consider how much better off you – and all the other PMs - would be if you were running the show. Or at least if you got to handpick his successor. Am I striking a chord here? Of course I am.
I’m going to state what I think a good PMO director needs to bring to the dance. I’m hoping on the couple of occasions so far where I’ve run the show that I did bring these things to the dance. At least I know I tried. And I will say that sometimes the organizational chemistry and process flow doesn’t always allow for the utopia that I’m going to describe. But getting somewhere close would be nice.
#1 – Manage the PMO, not a bunch of projects
The PMO director really needs to be a leader of people, not projects. I’m so tired of seeing PM’s who are spending most of their time leading the big projects also acting in the role of PMO director. It’s just not right. The PMO director needs to establish processes, identify training needs, knock down barriers, make connections, and fight for the PMO’s presence in the organization. It’s how the viability of the PM processes is maintained. You can’t rely on the CEO to suddenly think what you’re doing matters. Not when so many projects fail or have major issues. No, someone must be championing the organization. That’s the director. If he’s leading five projects of his own, he can’t do that. No one can.
#2 – Know your organization
The PMO director must know the organization. He must know how get information, favors, resources, and support. Unless it’s a startup situation, it’s very difficult to bring in an outsider as the director and have them be immediately useful. It’s better to bring outsiders in as PMs and promote a good leader to this role.
#3 – Care about the PM’s, not the politics
The PMO director must be ready to fight for the project managers in the PMO like the PMs fight for their customers. I’m sorry, but if I’m being pulled two ways – one way by senior management and one way by the customer – it’s usually going to be the customer’s concerns that I react to first. Likewise, the PMO director should be more concerned about his organization and fighting for it rather than playing a lot of politically games for senior management – unless that is in the best interests of the PMO itself. So many PMOs fail, they need a strong leader fighting to keep it viable.
#4 – Communicate well
Above all else – just like with any project manager – the PMO director must be a great communicator. Company policies, processes, planning, etc. must all come from this individual. And he must be a good listener because there are lots of project issues that arise that PMs need help with. Their success must be his utmost concern.
So, can I fire my PMO director? Well, sort of. If the needs of the project managers are not being met and if the PMO is faltering because of a lack of organized, efficient, and effective leadership, then waiting will only mean projects will fail. Customers will be lost. The company bottom line will take a huge hit. And so will careers. Staying quiet is not in anyone’s best interest. If it’s a common feeling (and not just your own grudge) that the PMO leadership is ineffective, it must be taken up the chain of command. And yes, then you can fire your PMO director. It would be your duty to do so.
Remember the old MacGyver series? Angus MacGyver, played by Richard Dean Anderson, could get himself out of just about any jam using anything from silly putty to paper clips to a piece of string. He could even make a gun out of a pen. Yes, those things are a bit beyond the normal project manager, but we all have our fallbacks – the things we rely on to get us out of some of the jams we get ourselves into – or our teams or customers get us into.
But is that the right way? Do we want to use whatever happens to be convenient at the moment to help us around an issue? MacGyver had to because he was almost always dealing with situation of clear and present danger that had to be resolved at that moment. He didn’t have the opportunity for advanced planning or risk management to get him through the messes he faced. As project managers who should be utilizing best practices, we do – or at least we should.
If we get in the habit of looking for the quick fix to our project management problems, then we’re never going to learn how to avoid them in the future. We’ll never learn from our mistakes and we’ll find ourselves always relying on luck to get out us out of messy project situation. Eventually our luck will run out and we’ll be exposed for who we really are….a talentless project manager who has skated by on the ability to avoid project catastrophes that should not have been potential catastrophes in the first place.
If we find we’re stuck in one of those ruts…too busy to focus on the right way to do things and just winging it till fires show up that need to be fought, what do we do? How do we un-stick ourselves, especially when we’re fighting fires on three, four or even five projects at the same time? When I find myself in this type of situation, I follow these two actions to help get myself and my projects back to where they should be….
Go back to the basics
If you’re floundering, then there’s no better time to regroup and get back to the basics. When I’m overwhelmed on multiple projects I like to step back and take stock on where things stand and how I’m running each project. I usually come to the realization that I’m shooting from the hip on one or more of the projects, falling into bad practices because I’m so busy and I’ve let the daily demands of the project management activities lead me into bad habits. At this point I stop, regroup with my team on each project – sort of a mid-project restart or refresh – and I revisit the plans from the kickoff phase of the project. Am I following the communication plan, are we holding regular status meetings and producing status reports according to the original schedule? Are we reviewing issues regularly? All the slow and steady stuff that keeps projects on track – am I doing all those things? I usually find that several pieces of the puzzle are missing and once I get back to the basics and on track to doing what I originally planned to do and managing each project how I promised to manage them, things tend to get back to normal.
Offload a project
No project manager ever likes to say they’re overloaded. Actually, no professional with a good-sized ego ever likes to admit this. It’s the guy equivalent to asking for directions. But sometimes – in order to be successful overall – it must be done. If you’re so swamped that you’re sinking on all projects, then meet with senior management and ask to offload one or more projects. Ideally, if you’re running multiples projects, they’re in different phases and not all hitting stride at the same time. On the rare occasion that they are, it’s ok to ask for someone to take over a project from you. You’re management wants you to succeed, too, and they’ll likely admire you more for recognizing the problem early on rather than after you’re already drowning and the project is already failing.
Angus MacGyver had something the average project manager doesn’t have - a nice group of writers and an avid fan base wanting him to survive to see another adventure next week. His success was guaranteed. We don’t have that luxury. We must rely on PM skills and best practices and we must rely on our teams and organization to help us meet those project challenges head-on. We need to be prepared for the problems we might encounter – meaning we must act proactively rather than reactively to issues on the project. Preparedness through planning, risk management, and PM best practices will find us experiencing more project management successes than failures in the long run. But don’t forget to assess how you’re managing things right now and adjust your practices back to where they should be. And ask for help if you need to – you’ll be more successful on your remaining projects because of that call for help.
No one seeks out to be part of a failing project. No project manager in their right mind says, “I hope this project tanks.” It’s just not part of our human nature. That said there are just times when a project is beyond saving or two sides simply aren’t going to get to a point of mutual agreement on the outstanding issues. It may become clear at that point that moving forward is in no one’s best interest. How we close down such a project is probably something to be discussed in another article. I will make not of that and address that soon. But right now I’d like to look at some of the signs that can be indicators that the project may need to be laid to rest. Or at least halted until more information is available, better requirements are defined, a business structure has changed making the project goals clearer, or personnel who are getting in the way of progress are turned over.
I’m interested in hearing from our readers on reasons that projects may need to be shelved. For me, I’ve identified what I feel are the four main reasons I’ve witnessed either in my projects or in my colleagues projects. These four are:
Scope creep is continuous
I’m not talking here about small disagreements in where the line in the sand needs to be drawn in terms of project scope. There are rare cases where the kickoff meeting happens and you move into planning with the customer and what you thought was a ‘defined’ project has turned into a mess. The customer expected ‘x’ and you planned to deliver ‘y.’ Sometimes it’s an issue that started during the sales process and wasn’t glaringly obvious until the skilled resources who truly understand the solution are sitting down with the customer and planning out the implementation. This is where the tire meets the road – often really for the first time – and the customer says, “wait, that’s not what I was told by Sales.” Or, “I was told I could have this for free and now you’re telling me that’s an 200 hour effort?” Sometimes these situations can be handled through negotiation and sometimes they can’t. When they can’t and it’s become obvious that you’re at a stalemate, it’s likely time to call the project off or place it on hold until clear and decisive plans can be made.
The project funding runs dry
When funding runs dry, the project manager has a serious problem. And without any documentation to support otherwise, the blame is usually going to fall to him. What can cause this situation? Well, if it’s just simply oversight or laziness on the side of the project manager, then that’s not grounds to cancel or shelve the project – but it certainly is grounds to remove the project manager for lack of performance. What I’m really referring to for the purpose of this article is more than just lack of budget oversight. My reference here is to situations where increasing demands are placed on individual project team members to perform outside of the planned tasks for the project. Perhaps it’s customer demands, perhaps it’s a need for many project personnel to go onsite for an extended period of time to work out project details, or perhaps it’s a customer’s wish to have one resource 100% dedicated to the project when that was not originally in the plan to do so. If change orders can be put in place – and if the customer has the money to move forward with them – then everything is fine. But if the customer refuses the change orders, thus refusing to pay more for the personnel demands, then you have an issue. Likewise, if the customer’s funding has run dry and the project is nowhere near complete, you also have an issue. Unless your organization is ready to go ‘pro-bono’ the rest of the way on the project, you may have no choice but to end or halt the project until more funding is available on the customer side.
Future project phases are being questioned
This one may not be cause to actually cancel the remainder of the project, but it is likely time to implement what you have, assuming you’ve got a workable solution through the phases already rolled out, and leave the rest of the project until the work is better defined. Customer priorities and infrastructure changes can cause future phases of a project to come into question. Are they still needed? Should the order of the phases be changed? It’s nearly impossible to keep your expensive project resources intact while the customer takes two months to decide so it’s usually a good stopping point to give the customer a chance to regroup and figure out how they want to spend the rest of their project dollars – and if they even want and need to.
Customer project personnel are constantly turning over
Have you ever had one of those projects where the customer team seems to be moving through a revolving door? Customer team members come and go, even the project lead on the customer side seems to change regularly. Team members often aren’t as critical as the actual project sponsor or leader – at least not for major decision-making. But if this turnover in customer personnel is causing schedule slippages, missed tasks, and budget overruns as your team scrambles with conflicting direction from the customer, then you have a major issue on your hands. Before the blame falls to the delivery project team and to you as the project manager, be sure to document the customer team changes well. Following that, if the situation is not improving and productivity has come to a standstill or major decisions are not being made, then it may be time to stop work on the project and force the customer to make some key ‘go’, ‘no-go’ decisions on the remaining work on the project.
The key here is knowing when to suggest to the client that it's not in the best interest of either party to move forward with the consulting engagement.
This discussion assumes one very big item that simply can’t be overlooked. That is that you can contractually cancel this project and that you would be in agreement with the client to do so. Be careful to not pull the plug on a project that would end up costing you millions in litigation if you cancel it. I would never suggest that – obviously. I’m simply looking at situations that arise that make it obvious – to at least one party if not both – that the project really needs to be put out of it’s misery.
Many studies have been conducted concerning failed projects and how many projects actually fail. Nearly all put the percent of failed projects in the majority – above 51%. Several recently conducted and well-regarded studies put the number somewhere between 62% and 75%. That’s saying that 62% - 75% of all projects fail. Ouch. But on the bright side – you’re not alone … it’s not just you. But that really doesn’t make it any easier or any better, does it?
So, going with the majority, let’s say your project has failed somehow. It may have finished over budget. It may have gone way off the timeline. It may have delivered a non-working solution for the end user. Or it may have been canceled altogether in midstream either by the customer or your own organization. At any rate, you have a project that failed to some degree and likely a frustrated customer, displeased senior management team, and a staff of project professionals that think they wasted the last 6 months to one year of their professional lives.
What do you do to rebound from that and to help others on your team rebound from that experience? And what do you do to help ensure that next time isn’t a repeat performance of this project? For one thing, we do not bury our heads in the sand or try to sweep it under the rug. That which does not kill us makes us stronger, right? Let’s learn from the past – learn from our failures and the failures of our projects so as not to repeat those same failures again and again.
Here are three key steps to take to help ensure that going forward we realize greater successes on our future projects:
#1 – Have open communication with your team on issues
Whether it’s your own budget concerns, morale issues, or rogue behaviors of a team member – make sure you discuss concerns. If appropriate, do it one on one, but for most project discussions, conduct them as a cohesive team. The more everyone is in the loop as a team the more everyone can help to rectify issues before they get out of hand.
This applies both during a project – especially a troubled one – and after the project to learn, as a team, what everyone considers to be the issues that negatively impacted the project. Consider it somewhat of a pre-lessons learned exercise. Take this information forward as you prepare to meet with your customer post-project to conduct lessons learned sessions.
#2 – Take issues to your customer early
Be sure to take any issues that arise to your customer as early as possible. If you need to discuss first with your team – as you should anyway for planning purposes – by all means do so. And if you need to discuss with your executive management to make sure they are aware and are backing you, then you should do that as well.
Always remember that the project is for your customer. They’re paying for it so they definitely have a stake in its success. They do not want you to fail – so get their buy-in and aid on issues and issue resolution. Put them to work. Build a two-sided cohesive team with the your team and the customer’s team and you’ll greatly increase your chances of project success.
#3 – Conduct lessons learned sessions
I’m in the middle of conducting the June PM survey on Managing the Project. One of the questions concerns how often do we conduct lessons learned sessions. It’s still early in the survey process, but sadly the results are not looking good. So far nearly half of the responders are stating that they conduct lesson learned sessions 0-10% of the time. Several have emphatically stated that they have never conducted lessons learned sessions.
What that tells me is that we are doing a poor job of figuring out what went wrong and brainstorming with our team and our customer as to how we can do it right next time. How can we ever fully get it right next time if we fail to figure out – or even want to figure out – what actually went wrong this time? If we don’t identify what went wrong then future successes may just be out of pure luck.
Conducting thorough lessons learned sessions with our team and our customer will help us rebound from our failed projects with new knowledge on how and why we failed and how to prevent that the next time around. After all, there are often some degrees of similarity in the projects we manage and learning valuable lessons about our failures can help us to succeed next time with flying colors.