Project Management Strategies for Handling Skittish Clients

Marianne Hang, Senior Project Manager

March 25, 2019

The recent economic slump has transformed many once-confident clients into clients who are now unsure of their requirements, slow to move forward with projects, and prone to delays even once a project is active.  I call these clients “skittish” because while they have the best intentions, you can never be sure what they’re going to do with their projects.  Their plans can change at any stage of the project lifecycle, they can take months to move projects out of visioning and into active status, resources may come and go with little warning, and projects well underway may even be cancelled as other priorities arise or corporate directions change.  So what’s a Project Manager to do with a project and client that are moving targets, experiencing regular delays, and frustrating the Project Team?  Project management is a role that champions clarity and strong planning, where success is measured by delivering on time, on budget, and within scope.  How do you have any hope of being successful and keeping your Team motivated if KPIs are non-existent, unclear, or constantly changing because the client doesn’t provide any level of confidence about moving forward?  Worse, they may seem to have lost interest and appear ready to give up.  In this article, we consider project management strategies to cope with the skittish client situation, and how to move not only yourself but also your Project Team and the client into a place of project confidence.  How do you manage the situation when everything you’ve tried to increase project confidence simply hasn’t worked because the skittishness factor has taken over, the writing is on the wall, and you just can’t continue to throw good money, good resources, and good time after an initiative that is clearly going nowhere?  This is part of strategizing to deal with skittish clients.   

A Solid Foundation Builds Confidence

The more leadership, preparation, and professional presentation the Project Manager and IT Architect provide to the client – especially at the executive level – the more confidence the client has in the project’s ability to be successful.  And the more confidence the client has in the project’s chances for success, the more likely they are to back it up in its early stages and support it throughout the project lifecycle.  When organizational priorities are in flux and clarity is nowhere to be found, people naturally want to align with initiatives that provide a sense of stability.  When everything feels dark, engaging an experienced Project Manager and IT Architect to spearhead a well thought out project can provide the light the client is searching for.  This may enable the project to move forward on the goodwill generated by the professionalism and preparedness of the Project Team.  While it’s not a guarantee, that well-deserved goodwill can push you up the priority list toward a go forward decision in a corporate environment where tough choices are made.  You can bet that the first cuts off the list of priorities will be the easy ones – the initiatives that clearly aren’t well planned, show lack of leadership, have no goodwill in place with stakeholders, and haven’t been presented in a professional manner.  A project built on a solid foundation of best practices will be harder and take longer for decision makers to validate whether it should be delayed or cancelled.  That gives you time to continue to build your solid foundation and goodwill, and provide deliverables that shore up your business case for continuity.  It’s still not a guarantee, but time provides options.  Lack of time means options are gone – game over. 

If you’ve been following my articles on the IT Architects blog, you understand the importance of building and maintaining goodwill and operating in a professional manner that follows best practices.  But what about demonstrating leadership, especially if you feel like you’re on quicksand in terms of project deliverables, you’re experiencing repeated delays and lack of decision making, and communication with your client is becoming rare?  The question is how to lead when you don’t know what you’re leading or where you’re leading to.  I recommend you first sit down with your trusted IT Architect and build a simple gap analysis to identify what you know and what you need to know.  If most of the gap analysis is based on uncertain information, call that out as “assumptions”.  Assumptions are valid and help feed risk analysis, as well as process mapping of various scenarios to save the project.  The high-level gap analysis also paves a direction forward by calling out what information you need to go after.  It can then be included in the framework Project Plan.  You and your IT Architect will also be able to fall back on your expertise and experience in order to make some go-forward recommendations.  Now you’ve got the basics for a list of Assumptions, a Risk Analysis, a Project Plan, a Process Map or two, and Go Forward Recommendations to achieve Deliverables.  Even at the highest level of detail, with gaps in knowledge and assumptions, presenting these artifacts to executives shows that the Project Leadership Team is thinking ahead, planning, demonstrating their in-depth knowledge of best practices, and moving the Project forward using the strategic level of expertise for which they were brought on board.  Taken together and presented professionally, this demonstrates leadership.  Leadership doesn’t mean you have all the answers.  It does mean that in the absence of information and communication, you have the ability to make coherent decisions with the information you have.  It means being able to identify what’s known and what isn’t, and build a high-level plan where you turn even the gaps into building blocks.  It means you don’t wait for all your questions to be answered before you begin building a framework.  Rather than looking to the client for a solid framework that they can’t provide, you and your IT Architect look to your combined expertise – that is where the solid framework starts.  Leadership is the ability to create and communicate something solid out of instability.  This builds the type of confidence with the client that may be the defining factor in moving the project forward.      

A related example of how providing a solid framework can save the day is my experience as a Sr. PM for a major oil and gas company.  I was the fifth of five Project Managers for an initiative that was near and dear to the Sponsor’s heart, but because the technology that the project was tasked to deliver was so new, the previous Project Managers and their Teams hadn’t been able to get results and the project was fast losing traction. Governance made it clear they would not allocate any more time, funding, or internal resources to this initiative unless something happened to turn things around dramatically and quickly.  I was brought in by the PMO as their last and best hope – no pressure there at all!  My first job was to quickly find out what was really going on within the project to cause stakeholders to be so skittish about moving forward.  My second job was to realign the Project Plan in a manner that realistically demonstrated what the Project Team’s next steps were, in close collaboration with the IT Architect who, as I found out, had never truly been engaged in the project by the previous PMs.  This caused complete lack of alignment in solutioning and also among resources.  By establishing a positive and inclusive working relationship with the IT Architect, we put forward a new Project Plan that was clear and aligned to specific deliverables.  Presenting this to our stakeholders together built the required confidence in the project governance to give us the go-ahead for the next project stage.  The new Project Plan also supported the Project Team to deliver what was needed in a realistic timeline, which gained their confidence and increased their motivation to deliver.  Due to a newly energized Project Team providing deliverables, and the IT Architect and PM working harmoniously together to provide project support and leadership, the project was given the green light to move forward to completion.  I am proud to say that we completed the project within the adjusted timeline and the company was among the first to implement that new technology!       

How to Manage a Graceful Exit When the Writing is On the Wall

A PM and IT Architect sometimes experience a client that is so skittish that remaining with an initiative comes into question.  I experienced this with a multinational organization during the initial stages of an economic downturn.  The Sponsor in this case was also the IT Architect and we had established a strong working relationship.  Although we’d put a solid project foundation into place, at that time the technology involved was not yet seen as an operational requirement.  With the downturn looming and tough choices to be made, project governance was prioritizing only those initiatives directly related to “keeping the lights on” – in other words, all initiatives that could be rationalized as having operational necessity.  All other initiatives were put on hold, pending further prioritization and funding availability.  While our project was security related and vital to operations, the critical nature of security initiatives was not as front and center in organizations, largely because they’d not yet experienced the hard lessons of not prioritizing security.  As a result, the project languished on the hold pile for a number of weeks while there were many discussions about how to rectify the situation.  The Sponsor met with governance repeatedly to advise them of the necessity of the initiative and the risk incurred of not proceeding.  Even though governance understood the importance of the project, a decision to move forward was continually delayed.  After a couple of months being on hold despite doing our very best to move forward with the initiative and obtain buy-in from governance to forge ahead, the Sponsor and I had a heart-to-heart talk and agreed that while the project might never actually be cancelled, the lengthy delay had impacted the viability of the technical solution.  It would require a reset to confirm the go forward plan and deliverables.  While we didn’t want to see the project cancelled, we also couldn’t continue to turn down other work for a project that was indefinitely on hold.  We both ensured that all project documentation was as complete and up-to-date as possible, archived appropriately, and we were in a position to accept other opportunities.  The project never did move forward and, had it done so, would have been delayed so long as to require a full technology review.  We were convinced that had we been given the green light to move the initiative forward on time, we had a solid foundation in place for success.  Although that project didn’t move forward, we moved forward as professionals in our careers, with the benefit of a career-long positive working relationship.        

There are times when no matter what you do and how well you do it, the Project is cancelled or moved into a holding pattern that shows no light at the end of the tunnel.  If you’ve followed my recommendations and the Project is still cancelled, don’t consider it, yourself, or your Team as failures.  The last and most important thing to do in this case is to rally the troops and speak to how everyone did exactly what they needed to do – had the Project gone forward, it would have been successful – but since it didn’t, it was successful to the point at which it ended.  That is still a success.  If the Project is caught in a never ending holding pattern, it’s worth having a heart-to-heart talk with your IT Architect about the value of continuing to wait for word that may never come versus making a clean break – knowing you’ve both done absolutely everything in your power to support the Project to move forward.  However, the final decision is out of your hands and that is not something that either of you can own.  In project management, it is as important to know when to stop a project as it is to know when to continue it.  In this case, coming to the realization that the project is effectively over is half the battle, and exiting gracefully and professionally is the other half of the battle.  Time may see both you and your IT Architect revisiting the project, but it will require a reset in that event and you will both need to make a decision as to whether you wish to rejoin the initiative or continue on another path.  Remember that success takes many forms and not all projects should go forward.  Once you’ve done your very best, taking note of the recommendations provided in this article, you and your IT Architect can be confident in the knowledge that whatever the outcome, you were both – along with your Project Team – successful for as long as the ride lasts.