Spear Chucking - Managing The Incoming Interruptions ...

Today, we're going to take a look at disruptions within the Project Lifecycle.  Specifically, those interruptions that can wreak havoc across the teams, timelines, costs and delivery schedule.  Sooner or later we need to deal with reality and reality is usually messy.  I have yet to see any type of a project where something doesn't pop up that needs to be addressed by the Project Manager or the Project Team.

First let's identify some of the familiar players that could end up disrupting your projects:

1. You Can't Do This Project Without Me: This individual lies in wait through the project and will find ways to be disruptive.  In most instances, these are very knowledgeable people who are afraid of sharing too much information.  They like to be viewed as the solution.  So they will identify something early on in the process and then hold it close until they feel it is the right time to "bring up their concern" and then be the one with the solution.  Sometimes they will work their "magic" through others, quietly whispering along the edge of the project until someone brings up the issue for them and then they can move in and be recognized for their "expertise".
2. I Know What Is Needed - Why Are You Wasting My Time: These folks view themselves as technical experts and don't feel like they need to attend meetings, read the requirements or test their code.  It is beneath them and they view it as a personal insult when someone actually asks them to explain what it is they are doing or how they plan to test the code that they are writing.
3. I Don't Really Support The Project: This person will pay lip service to what is going on.  But behind the scenes they are working furiously to deep six the project.  They view the project as disruptive or threatening and don't buy in to the value placed on the project by the Project Sponsor.  In meetings they will support you, but out on the floor they will attempt to undermine every decision made in conjunction with the project.
4. I'm Here To Make This Project Difficult: These folks find a reason not to do anything.  They will disrupt meetings with negative comments against individuals, other teams that interact with the Project Team, outside resources, specific project requirements, test planning and/or implementation planning.  It is their mission to disrupt at every stage, every decision point.
5. I Don't Report To You, You Really Can't Make Me Do Anything: These individuals like to play the game that they are only here temporarily and that you really don't have any control over them.  They will actively find ways not to work on the tasks that they have been assigned and will have glorious excuses of how they needed to work some other issue instead of the work that you have assigned them.

This is tough enough to deal with when the individual exhibiting any of the above traits is within the Project Team you are managing.  But what happens when they are outside the Project Team?  Maybe it is a resource manager who is supply team members to the project.  Maybe it is a Manager within the Finance Team who isn't on the project but doesn't believe in the promised results.  Maybe it is a Subject Matter Expert within the organization who feels that they need to be involved in the project.  Maybe it is a Senior Leader within the organization that doesn't support the Project Sponsor.

So, let's get down to brass tacks, what are the specific symptoms that you'll see - this is not meant to be an exhaustive list:

1. Withheld Requirements: Someone decides to withhold key information about specific requirements or withhold requirements in whole until designs are complete and development is well underway.  This one is particularly nasty in that you have to backup whole parts of the train and redo work.  This has the potential to disrupt project timelines, costs and needed resources.  Something is most likely going to have to give in the project.
2. Work Slowdown: This one is insidious.  You will slowly begin to notice that specific tasks are not getting enough work done.  Jeopardizing the completion dates of the identified task, as well as future tasks and milestones.  It has a tendency to sneak up on you - you won't find it all at once in a meeting or as you're updating information within your project plan.  It will slowly begin to show itself to you over a period of time.
3. Unresolved Issues Drag On and On: You will find that you can't close issues or identify working mitigation plans because you circle back and fight battles that have previously been discussed.  Your Project Meetings or Stand-Up meetings become dysfunctional and the Project Team begins to dread attending.  Individual work tasks aren't seeing progress because decisions aren't being made.
4. Team Cohesion Disappears: When the project initiated, it seemed like you had a great team.  People appeared to communicate well, supported each other and had bough in to the goal.  However, over time small conflicts turned in to larger conflicts and now the team doesn't put their oars in the water at the same time.  The project can't gain momentum.
5. Forced Death March: The Team has given up - milestones are continually missed, even after the team recommits to new dates.  No matter what you try, progress seems to be impossible to measure, but you keep slogging forward.

Now, I'll be the first to admit that sometimes requirements, or pieces of requirements, get missed.  It happens, we are all human and we can't always be perfect.  But this should be the exception, not the rule.  You shouldn't consistently see missed requirements coming from the same person or team within the organization.  If you do, it's your job to report this to your manager, the project office and the Project Sponsor.

So, here's the million dollar question - what do you do?  As Project Manager, this is what you're paid to do - solve problems.  Here is where you need to put on the gloves and get down in the trenches.  Communication is key and you need to pull out every option you have in your playbook.

If the issue identified is a missing requirement, maybe there is time, and enough available resource, to include it in the current phase of the project.  Maybe as Project Manager you will need to make the executive decision to withhold support of the identified requirement until a future phase of the project.  Maybe, with the support of the Project Sponsor, you will be able to delay the target date or increase resources to accommodate the identified change or new requirement.

Missing requirements, are actually probably the easiest issue to deal with from a project perspective.  The requirement is truly really needed or it can wait.  To some degree it is one of the few straight forward decisions you can make as a Project Manager.  Just make sure that you keep the powers that be informed and that you've documented why you are, or are not, going to make the necessary changes.

Other issues are more slippery.  They usually involve team members or other actors throughout the organization that interact with the Project Team.  Start with a 1-on-1 conversations with the offending party or parties.  Find out what is driving their dissatisfaction.  You might get lucky and actually be able to make an adjustment that allows you to sell the individual on the goals of the project and reengage them.  However, if after your 1-on-1 discussion, you don't see immediate improvement, you need to be ready to escalate to the resource manager, your boss, the Project Office or the Project Sponsor.

You will use every bit of charm you've developed over the years in these 1-on-1 sessions.  When held with members of the Project Team, they are usually fairly straight forward as you have some appearance of authority in the overall chain of command as it relates to the project.  However, this becomes more difficult as you identify individuals outside of the Project Team.  If these are individuals that are considered peers, it's your responsibility as the Project Manager to initiate the conversation to see if you can solve the problem.  

It the individuals causing the issues are higher up the food chain, then you need to document what you believe the problem to be and escalate through your boss, the Project Office or the Project Sponsor.  This is not easy to do, but it must be done.  If they are actively engaged in activity that could cause the project to fail, increase the overall costs of the project, jeopardize the identified timeline or impact the resources working the project, you have a responsibility to identify it, document it and get it to the people that can solve the issue. 

You can not allow these individuals to continue to poison the team and the project.  What hopefully is a small issue when you first identify it, can not be allowed to grow in to a show stopper issue that has the potential to disrupt the entire project.  Remember, you've been placed on this project to see it through, not to sit on the sidelines and watch it fall apart.

How do you handle disruption within your projects?

Tags: SDLC, Project Management, Project, Management, Conflict, Resolution, Project Manager, Software Development Lifecycle,  Project Lifecycle

For more information on David L. Collison: LinkedIn Profile