From the Sponsor’s Desk – Dealing with Problem Project Staff

“It is our choices that show what we truly are, far more than our abilities.”
– J. K Rowling

Great people and great teams are the foundation for successful projects. Yet, all too often, greatness can be situational. That’s why a project manager’s most important responsibilities include helping individuals thrive and teams perform. One essential aspect of those responsibilities is to identify and deal with problem project staff expeditiously.

Greatness is dependent on a combination of factors, from skills and capabilities, attitudes, relationships, the environment – mother nature as well as the organizational kind – in addition to context and circumstances. Someone who was a great performer in one situation may struggle in another. Or, as sometimes happens, as in the following case, an individual who hasn’t managed to find their greatness opportunity and gets pushed from project to project will continue to struggle as they go.

Thanks to G.A. for the details on this case.

The Situation

Susan was assigned as the project manager to a process reengineering initiative for a midsize retail organization. The project had a budget of $1.8 million and a delivery target ten months out. The sponsor was knowledgeable, personable and committed. The organizations affected by the planned change appeared to be enthusiastic supporters, ready and willing to work with her team to deliver a new, streamlined, end-to-end process with a brand new and engaging technology solution. She also had three other unrelated projects on her plate.

The Goal

To deliver a reengineered process, the related applications and the supporting technology infrastructure, on budget and schedule with the required quality, ease of use, flexibility and performance. The project was targeted to deliver annual benefits of $1.1 million from productivity gains and cost reductions.

The Project

Susan proceeded to assemble her team. The IT organization had resource managers organized by broad skill set (software development, business analysis, technology infrastructure, etc.) who would look after filling resource requests. Susan discussed her project and her anticipated skill needs with each of the resource managers, asking initially for a senior staff member to help develop the plan and get more specific about additional needs. She also met with the managers of the business units affected by the project to get the required SME’s assigned and acquired a process designer from HR.

When her senior team was assembled, Susan led them through a number of planning sessions to get an actionable plan in place. As the plan took shape, it became clear that the timeframe of ten months would be tight. She reviewed the team’s concerns with the sponsor but he was adamant – do whatever they had to do to get the project delivered on time, including adding more staff and cutting function. The target date was the priority.

With her senior team and a solid plan in place, Susan again approached the resource managers and business managers to address her additional skill needs – two business analysts, six software developers, two infrastructure technicians, two testers and assorted part time staff from business SME’s and for data base work, process design and integration activities.

As the full team came together, Susan assigned the new staff to priority tasks and the work commenced. It wasn’t long before she noticed one of her new software developers, let’s call him Earl, had missed his target and was forecasting another two weeks to complete. Susan asked her software developer lead to check on Earl and find out what the problem was. When the lead reported back on Earl’s progress, the news wasn’t good – Earl’s grasp of the assignment was weak, the code that existed was poorly written and addressed only part of the functionality, Earl’s relationship with the business SME was not good and Earl was very defensive re the lead’s queries.

When Susan asked the lead to work with Earl and the business SME to get the task completed, the lead pointed out that that would impact his own work. Susan persisted and eventually the task was completed. What Susan didn’t know was the lead and business SME essentially had to shadow Earl every step of the way. Earl resented it. The business SME resented it. The lead resented it. And other tasks fell behind as a result.

Earl continued to struggle with tasks assigned to him. He alienated the other team members who had to work with him. He was a negative and disruptive influence in team meetings. His sick days started to accumulate. He often showed up late for work and departed early, mumbling some excuse about a family emergency.

About two months into the project, Susan had finally had enough of Earl, his excuses and his disruptive behaviour and asked his resource manager for a replacement. The resource manager asked Susan for a review of Earl’s performance to date and some specifics about Earl’s shortcomings. Susan suggested the resource manager talk to her software development lead for the details and demanded an immediate replacement. Then she went back to her other duties and her other projects, without a replacement. Of course, the resource manager didn’t act because he was waiting for a call from Susan’s software development lead. And the software development lead wasn’t aware that he was expected to call the resource manager. So Earl continued on the project, missing dates, producing poor quality code, alienating his teammates and being a drag on overall progress.

About four months in, exasperated with the lack of progress on the “Earl” problem, Susan called the resource manager again to ask for an immediate replacement. The resource manager restated his needs. So Susan called her contact in Human Resources and suggested they needed to terminate Earl immediately.

The Human Resource staff explained the company procedure for such situations and sent Susan a twenty page booklet for her to fill out and present to the IT resource manager.

Susan had a conniption! She didn’t have any more time to spend on this “loser”. So she decided to marginalize his negative impact as best she could by assigning him less critical tasks that didn’t require contact with the business. Of course, the tasks she did assign him were still required for the project to succeed and still required quality code that Earl didn’t have the capability to deliver. And so the project continued.

The Results

The project was delivered four months late and 40% over budget, largely due to quality and application performance issues and the extra costs incurred to resolve those challenges. A team satisfaction survey conducted as part of the post completion audit by the PMO yielded an overall rating of “Somewhat Dissatisfied” due, for the most part, to the negative influence of one software developer. A similar outcome resulted from the survey of the business leaders and staff involved with the project although their concerns were the missed date, excess costs and cut functionality. It was the “Earl Affect”! And Earl continued to work in IT, ready for another assignment.

How a Great Leader Could Have Delivered

There’s no question Susan was left holding the bag. In my view the resource manager should have taken Earl off that project and taken responsibility for driving the improvement process through to its conclusion, absorbing whatever costs that entailed. However, the fact that that didn’t happen didn’t take Susan of the hook. She had the ultimate responsibility. She had a project to get done, she had resources assigned, a budget and a target date. It was the old “Pay me now or pay me later” dilemma. Here are some things Susan could have done differently.

1. Have a conversation – Actually, have a string of conversations. That can include a thirty second encounter in the elevator, a chat in the hallway, meetings with the team, one on one sessions. You want to know as much about your staff as they do about you – happenings with family and friends, turn ons and turn offs, goals and aspirations, expectations around work/life balance, job satisfaction, skills and capabilities, hobbies and avocations, etc. It builds camaraderie and it can yield insights that could help improve performance.
   At the core however are the expectations of the job, responsibilities to the team, the relationship with the larger organization, actual performance results and areas for improvement, growth and excellence. Be objective, friendly and supportive. But also be absolutely firm on the need for improvement. And be very clear that the responsibility lies with the individual. Susan was distant, uninvolved and uninterested.
2. Build a support alliance – You’ve no doubt heard the saying “It takes a village to raise a child”. Well, that’s also true for an individual practitioner. The culture and core values of an organization and a team can have an amplifying effect on an individual’s performance. Or a deleterious effect. When someone is experiencing a performance challenge, the overseeing manager needs to build an improvement alliance, the workplace “village” if you will..
   That alliance should include, at a minimum, the individual in question as well as the work manager, resource manager, someone from Human Resources with knowledge of the organization’s processes and practices and one or more senior subject matter experts as needed to review, teach, mentor and otherwise guide the individual on their improvement journey. The alliance exists to help the individual succeed. Its existence can also temper any accusations later on that the individual wasn’t given a chance. Susan was just looking to pass the buck, first to the resource manager, then to Human Resources. When she got no takers, she dumped the problem off her senior team members. In fact, I think the team would have done better if Susan had just put Earl on the bench and proceeded without his negative influence.
3. Plan the work – This is where the plan of action is developed to help the individual improve their performance, be it a question of skill level, attitude adjustment, cultural accommodation, whatever. The assignments should be real work, typical of the tasks assigned to others at a similar level and stage of development. As well, clearly specified acceptable completion criteria are a must.
   In the case of a software developer, the criteria can include time and cost to complete, degree of reliance on outside assistance, code that passes a defined unit or integration test, that performs to target, that follows department standards, that is maintainable, etc. If training is required, include testing of the retention and application of the skills taught. Include checkpoints to assess progress, or lack thereof, usually weekly or biweekly.
   The initial plan should cover a period that’s sufficient for the individual to demonstrate progress. In the case of a software developer, six to eight weeks should be ample. The individual should also be involved in its creation and agree to the final product. Unfortunately, neither Susan nor Earl had a plan.
4. Work the plan – In this phase, the individual takes on the assigned tasks and delivers the product for assessment. Keep track of the information necessary to assess the results in the next stage based on the agreed upon metrics. Don’t hesitate to drop by on an occasional basis and see how the individual is feeling about the assignment. If there’s need for assistance, go ahead and arrange for the necessary support but keep track of the external help needed. It should decline over time. Susan’s approach was to ignore the problem. When she was reminded by her senior technical lead that the individual was still struggling, she looked to others to solve her problem.
5. Appraise the results – The support alliance needs to meet on a weekly or biweekly basis to review results from the last work period and the cumulative trends. I prefer to have the individual whose work is being examined own this stage and lead the discussion because it reinforces their ownership of the performance improvement plan. In this case, there was no alliance, no alliance meetings and no formal assessment of progress or conclusions reached.
6. Act on the findings – Often work managers overlook the fact that staff who are struggling aren’t having a lot of fun. Look at the individual in this case – defensiveness, anger towards team member criticism, more sick time, arriving late for work, leaving early, negative and destructive behaviour in team meetings.
   It’s in everybody’s best interests to give staff every opportunity to succeed. Sometimes that doesn’t work out. It’s then in everybody’s best interests to help them find something that does give them satisfaction and fulfillment.
   If the results over the plan period are not acceptable, it’s time to start focusing on a career or job change. In many cases, the individual will acknowledge the need for a change. It’s then time to work through the organization’s human resource practices to realize the job change or termination.
   If the results are positive, the affect can be quite liberating, for the individual and the team. The challenge is then to sustain and build on that improvement. But please, don’t abandon the effort until a satisfactory resolution is achieved.

Unfortunately, all too often, as was the case here, managers don’t pursue performance problems to a satisfactory conclusion. Yes, it takes time, effort and energy away from the things they’d rather do. Yes, the effort can be contentious and confrontational. Yes, it’s often a difficult learning experience for everyone involved. Yes, the support and expertise that should be available from the Human Resources organization or the resource managers are often missing in action. And yes, there’s often the implied or real threat of legal action if the individual is terminated. Tough!

On the positive side, you’re giving the individual a chance to be successful, either within your organization or somewhere else. As well, you’re helping your organization avoid future costs of hundreds of thousands or millions of dollars by resolving an individual’s performance problems and alleviating the future drag on organizational, team and managerial performance. Dealing with problem project staff – that’s a win-win!

So, put these points on your checklist of things to consider if you are confronted by an individual with performance challenges. Then you too can be a Great Leader. Also remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and the Decision Framework (including resource management best practices) right up front so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation on this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your experiences. Thanks