PM Articles > Brian Irwin > Disarming a Project Landmine

Disarming a Project Landmine

by Brian Irwin

Question #1

"I work for a large technology company based on the West coast. I'm currently managing a complex project to deliver a new software technology for the telecommunications industry. For obvious reasons I cannot go into much more detail about the project.

At this point in time the project is fast-approaching a critical milestone. One of my project team members recently approached me about one of the packages I'd requested he provide to me prior to this milestone. He acted genuinely confused and had not prepared the package—which, by the way, is a software requirements document. We are now two days away from the milestone and it will be next to impossible to get the deliverable in the required timeframe. What can I do to ensure this never happens again?"

Sincerely,
Desperate for the Deliverable

Dear Desperate for the Deliverable,

First, realize that you can never be 100% certain something like this will not happen again. But, there are actions you can take, and behaviors you can model, to greatly lessen the probability of future occurrence. One behavior, in particular, you can practice immediately is to instill and enforce personal accountability.

Holding others accountable can be a difficult thing to do, but it doesn't need to be. Typically, as professionals we do not enjoy conflict. This is especially true when that conflict is with someone on our project team. The problem with this view is that it relies heavily upon the idea that accountability is performed on the back end and is strictly punitive. While this may be a last resort, my contention is that accountability is not punitive in nature.

My experience has proven to me that people generally want to do a good job and be part of a high-performing team. Of course, there are those who do not fit this description, but they are in the few, not the majority. After all, who actually enjoys being on the poor-performing team?

Accountability is not an after-the-fact behavior. Rather, I contend that accountability is determined on the front-end of an assignment, not the back. Holding others accountable begins by communicating very clear expectations and, perhaps, even getting written agreements. In your particular situation did you do everything that you could to ensure your team member was crystal clear about what was expected of him with respect to the requirements document? What were the actions you took prior to the deadline to ensure the deliverable would be completed on time?

Accountability starts with the individual who holds the expectations. You must be able to hold yourself accountable if you are to hold others accountable. When things go awry which were a result of your own doing—own it. A colleague of mine refers to performing a "you-ectomy." When things go right it's easy to see those scurrying to claim the credit, "I did that. It was my idea." However, when things do not go well, the opposite can also be witnessed, "I told them it would not work. My team had nothing to do with that." Great leaders will demonstrate ownership whether results are good, bad, or ugly and hold themselves accountable.

The responsibility for clearly communicating our expectations rests with us. I've witnessed several projects falter because of project managers not setting clear expectations. We often hear people speak of accountability without fully understanding what the word really means. Accountability is not about blame. It is not about finding scapegoats. Accountability is all about expectations and ownership. Be clear with those who you depend on and those whom depend on you. Be clear and you'll greatly reduce the number of vaporous deliverables in the future.

Similar to accountability, ownership is also demonstrated up front, not after the fact. As an example of this, consider how many meetings you've attended where an abundance of good ideas was being generated by team members, however nobody stepped up to own the responsibility of implementing any of the ideas. It sounds like this: "We should implement a knowledge management system to capture lessons learned," or, "It would be great if we'd create an initiative to allow project managers to provide performance feedback to the functional managers of our team members."

The prime defect with the preceding statements is the use of the word we. When you hear someone using we, they're really meaning you. This leads to lack of ownership and nothing gets done. When you hear these statements respond by saying, "That's a great idea. Who will own it?" Keep your focus on setting clear expectations for your team members and good behavior will be much more likely to follow.



Question #2

"Recently, I discovered a colleague of my sponsor was not a supporter of my project. It was made very evident when she spoke poorly of the project in a meeting with our steering committee to whom I was making a presentation. I'm running a business transformation project which has struggled from the beginning because of decreasing funding and short timelines. The dilemma I have is that my lead system engineer is the husband of my project's opponent. Do you have any ideas how I can neutralize the situation?"

Sincerely,
Out on a Limb

Dear Out on a Limb,

You are certainly in a precarious situation. If you fight the project opponent you risk isolating your lead system engineer. If you do nothing you risk having your project sabotaged. Based on the information you provided, you have a few options.

The first option is to do nothing. While this is the easiest option, it also carries the highest risk to all involved. Doing nothing is not really a valid option you should consider pursuing.

Your next option is to hold an in-person meeting with your sponsor's colleague and attempt to resolve the issues she has with your project.

You may also speak with your lead system engineer to smooth things out and see if he has any insight on his wife's views. This is not the option I would suggest. If he is not involved (or wants to stay out of it), you risk roping him into the situation, regardless of his position, and forcing him to pick sides. This would surely be bad for everyone.

I believe your best option would be to engage your sponsor and request he or she works with his colleague to better understand and alleviate what her concerns are. Your sponsor may also have further ideas of how to handle the detractor. In the meantime, stay alert to your lead system engineer's position and be careful that he's not working on his wife's behalf to sabotage your project or undermine your authority.

A situation such as this one is what makes project management anything but typical. Staying ahead of the game by paying particular attention to your surroundings will greatly enhance your chance of project success.


Related Items
Project Sponsor Roles and Responsibilities
An executive champion can be incredibly helpful, as long as everyone understands what's expected.

Software Requirements Specification
Kick-start your team's requirements deliverable with this outline.

Task Responsibility Matrix Formats
Make sure everyone understands and agrees who's responsible for what, and when.



Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

I am really interested to know how this situation is eventually resolved. There is sure to be a lesson to be learned from which we can all benefit. I agree with the advice, risk mitigation is through the Sponsor to whom you are answerable. Is the sponsor actually aware that the project is potentially being jeopardised (your duty to inform). Does the project opponent have any authority over aspects of the project? Can both the opponent and the System Engineer be neutralized by elimination? (ie move both out of the sphere of influence)


The comments to this entry are closed.




©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.