Top Cause Of Project Failure Noaudio


Published on

What's the ultimate cause of project failure? Papercut Project Monitoring takes a look at trust across the enterprise and its impact on project closure.

Published in: Business, Technology
1 Comment
  • Thank you, PaperCutPM, for this very enlightening presentation.

    Without trust there is nothing!
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I’m Geoff Crane, Owner and Chief Consultant at Papercut Project Monitoring. Today I’m going to talk about the ultimate cause of project failure, and the thing that causes breakdowns across all businesses everywhere.
  • I’m looking at this issue from a project perspective, so before I get into the cause, I want to refresh everyone on the goal of a project manager, and that’s to get to project closure. It doesn’t matter what else is happening, who’s doing what, where the work stands or what flowcharts you use…the goal is to get the job done.

    All other goals are secondary.
  • As such, it’s important to keep in mind what that means for a project manager. In a perfect world, there would be a recipe for everything, and you’d follow that recipe and the job would get done. Unfortunately, in the real world, the project manager needs to do whatever it takes.

    Whatever it takes. That could mean that you open your PMP manuals and follow best practices. Best practices are absolutely the right starting point for every project.

    However, as most seasoned project managers know, sometimes you also need to take those best practices and flush them down the toilet because nothing’s going according to plan.

    You do whatever it takes, even if that means putting on an Aquaman costume and standing on a street corner, if that’s what it takes to get the job done, that’s what you do.

    Those are great sideburns on Aquaman there.

    Personally I’ve never dressed up like that but my best story was trading chicken rice for 3Com network cards in a flea market in Shanghai without anybody around me speaking English, trying to fix broken presentation laptop nobody else had time to deal with. You really do do whatever it takes.
  • Doing whatever it takes is pretty easy when you’re by yourself.

    Well, it’s not always easy, but it’s a LOT easier than when you have to do it on a team.
  • What’s the problem?

  • Why is that? When we take a look at project best practices, there’s all kinds of advice on making sure things stay on track. The body of knowledge is chock full of recommendations including getting your stakeholders involved early and often.

    They suggest you use clear language, which is certainly important if you want everyone on your team to understand what’s going on.

    They recommend you delineate clear roles and responsibilities so everyone is clear on their job, and establish measurements so you get the behaviours you want during execution.
  • What they’re not so clear on are things like, how do you get people to work together when they have different working styles? Some folks need a sense of direction and hand holding, others want to be left alone. People with academic backgrounds are not going to understand business people and vice versa. Some people don’t really care about your processes and would rather you just let them do their jobs the way they know how.

    Both people and groups can come together with conflicting wants and needs, and sometimes competing agendas like when you put two vendors together on the same project.

    And then there’s the things nobody wants to admit to. Shame, fear, guilt, embarrassment, a sense of inadequacy or incompetence…these are things that we all feel as people, but wouldn’t dream of divulging for fear of the perception it would create.

    There’s lots of other things that happen when people interact that there aren’t many best practices for, and they all have one thing in common.

  • If you look it up in the dictionary, you’ll find that trust is defined as “the trait of believing in the honesty and reliability of others.”

    When you think about it, all business hinges on that one little word. Do you trust this person enough to hire him? Do you trust that person get work done? Do you trust him with your money? Do you trust them not to abuse your time?

    At all levels, in all companies, across all sectors, business is about trust. Depending on your profession, everyone has their own way of dealing with trust. Salespeople rely on it, marketers rely on it, and so do project managers.

    Project people have to contend with trust on multiple levels, because they generally have no authority to demand results. Project managers will have team members in other departments and in other companies. Because of that, they have to rely on influence and negotiation to get work done. And as team sizes increase, this becomes harder and harder to control.
  • Let’s take a look at how trust works between two people.

    If this pink guy here has to decide whether or not to trust someone (like the blue guy who could be a project manager), he’s got to go through a series of steps in his mind before he can communicate trust.

    There’s questions of competence. Can this guy do what he says he can do? Where’s he from? What’s he done before? How confident is he?

    Then there’s questions of character. Do I like this guy? Does he seem like a good person? Is he enthusiastic?

    Of course, eventually thoughts will turn to self-preservation and fear. Is this guy the boss of me? What happens if I screw up? Is he likely to put me in a bad position?

    There’s many other evaluations Mr. Pink has to make on Mr. Blue, but Mr. Pink’s still has to give a response.

    Responses are generally based on self-preservation. Can I tell the truth, he’ll think…he could say “yes I trust you” and not mean it, because he wants to avoid conflict with his colleagues or with Mr. Blue; or, if he doesn’t fear Mr. Blue, Mr. Pink could say “yes I trust you” dismissively in an attempt to get Mr. Blue out of his office.

    Or he could say “yes I trust you” and mean it, putting faith in Mr. Blue that he’ll look out for Mr. Pink’s interests.

    Trust is a very complicated process, that goes up and down with every interaction one person has with another. But it doesn’t stop there.
  • Now let’s take a look at the trust process between two groups. Here, we have 5 people, all of whom will go through the same trust process on their own.

    A leader will generally put the question out “can we trust them”, which will elicit responses from each of the team members.

    Before we can look at the trust response between separate groups, let's take a quick look at the trust response within a group. Most people have the experience of being out with their friends at a restaurant or a club and there’s a huge lineup to get in. Each person is naturally going to have their own opinion of whether they want to keep standing in the lineup or not, but until someone actually says something out loud, it’s very likely they will stay. This is because once trust has been established, as social animals we instinctively want to maintain that trust. If you’re in the lineup as a group, breaking the group without following certain protocols puts that trust at risk. If you just walk away from the lineup without saying anything, the friends with you will likely say “what’s his problem” and keep standing in the line. However, If you ask your friends, “do we want to keep standing here freezing our butts off,” you might get an enthusiastic group response “HELL NO”.

    So coming back to the group who’s deciding to trust another group, they must first follow certain protocols to arrive at a group decision. When the question goes out, some people may choose to say “yes” so as not to rock the boat, and other more daring people might offer up a different opinion. That opinion will result in a group decision that then gets communicated to the other group.

    This is typical of a vendor / client relationship where multiple people on the vendor side are serving multiple people on the client side. Individuals in a group have the ability to influence one group’s response to another.

    On a small to medium sized project, a project manager needs to be sensitive to this, and be aware of any potential diminishment of trust as soon as it happens.

    Valid or not, any negative response from one group to another immediately puts project closure in jeopardy. A negative response will result in finger pointing and blame, from one group to another, which will elicit a similar response from the other group in defense.

    Suddenly getting the project done has stopped being the priority for team members. The focus has shifted to their responses to the other group.

    Trust has been damaged, and your life has just gotten more complicated.
  • Now lets take a look at larger projects. This decade has seen the rise of enterprise applications. If you’re not familiar with them, they’re software platforms that allow for workflow and processing across a whole organization.

    They’re incredibly powerful applications because when a person in one department finishes a job, built in automation routes the job to the next person down the chain to pick it up and do more work to it.

    Ideally, these applications allow a company to save huge amounts of money, work more efficiently and become more profitable as they reduce their overhead. In practice however, these implementations and subsequent operations are fraught with problems.

    Looking at it from a trust perspective, each group on the platform is going to have their own job, their own way of doing things, and their own sets of measurements. That means that behaviours highly valued in one area might be discouraged in another.
  • Further, processes that cause changes to the platform for one group could potentially impact and undermine operations for another group.

    If communications isn’t managed very carefully from the onset of the implementation, people in some groups stand to have their work disrupted by changes made in another group. When someone takes action that negatively impacts others, they damage trust.

    It doesn’t take very many times for this to happen before you have an enterprise of normally nice, hardworking people turned into finger-pointing monsters. The worse this gets, the less collegial people behave, and the more they start to focus on their own problems rather than worrying about getting to end-of-job.

    Not only that, but to avoid further disruptions, groups may take steps to distance themselves from the project and go so far as to badmouth or otherwise sabotage it.

    At this point, not only is the end date of the project in jeopardy, but so is the funding for the project itself.
  • At this point, I want to recap the goal of the project manager. It’s to get to project closure.

    When trust breaks between individuals, groups, or multiple groups, project closure is threatened. This is because when trust breaks, the focus of the victim shifts to the breach rather than project completion. Therefore, for the PM, the job of managing timelines and schedules, writing up plans and reports…it’s very nice, but it’s SECONDARY.

    The first and foremost priority of the project manager is to get the job DONE, which means identifying breaches of trust, no matter how small, and resolving them absolutely as fast as they can.

    As the project increases in size, that’s a tall order. If those breaks aren’t coming to to the PM immediately, they may be too late to respond without creating a delay.
  • What you can do, though, is establish a climate of trust on your project from the very beginning. Make trust your core message. This is a practice-what-you-preach concept though, so it has to start with you before you can build it out around you.

    First, make an effort to get to know your team and your stakeholders. They’re people too, and it’s very likely you have things in common. People are much more receptive to building trust with others who are willing to expose part of themselves.

    Next, make a point of being trustworthy. This is something you have to do with every decision you make, every response you give. It’s a lot more work than it sounds, and we’ll talk more about that on the next slide.

    Lead by example. Let your team know how to behave by watching how you behave.

    When others see you as a trustworthy colleague, you’re in a much better position to provide a vehicle that encourages trust.

    Build a communications plan. Trust develops through repeated contact. Make sure that you, your team and your stakeholders know how, when and how often to have that contact. That puts you in the drivers seat of ensuring the people on your project are building those relationships.

    Set an open door policy. You want people to come to you with problems. I know that some days it’s the dead last thing you need is another complaint but if you push people away, the problems will fester on their own.

    Finally, encourage trustworthiness in your people. Don’t punish them for making mistakes or bringing you bad news. Openly discuss trustworthiness with them when you’re talking about their interaction with other team members.
  • How will people see that you’re trust worthy? Above all, if you say you’re going to do something, DO IT. It sounds so easy but it’s really not. I’ve seen a lot of people, and I’m sure you have too, who make a flip comment about being able to deliver something in a meeting, and later get overwhelmed. Think for a moment before you make any promises about whether or not you can deliver, or by when you could deliver. Make sure to follow through on all of those promises exactly the way you said you would. And if something happens and you can’t deliver? Let them know right away.

    If you need to withhold information until you’ve confirmed something, be up front about that. If you’re under a non-disclosure agreement, say so. If someone is asking something that’s really none of their business, like what colour your underwear is, be polite, but let them know you’re not prepared to discuss it.

    Be up front about problems or slowdown in your project schedule. Let people know so that they can make their own decisions about how to react. Even in the face of bad news, you’ll get a lot of respect from the people you’re working with if you just tell the truth.

    Above all, BE SINCERE. Nobody likes to feel patronized. Mean what you say. It’s just better.

    Things NOT to do. Don’t lie. Ever. Don’t tell half-truths, or little white lies, or try to spin the facts to make you look better. Those things are guaranteed to backfire and will cost you so much trust it will be very difficult to build it back up again.

    And if you do lie and get caught? Don’t cover it up with another lie. That will put the last nail in your coffin.

    I’m probably going to get shot for this but...

    Remember this guy? Think of all the trouble he could have saved himself if he’d just said, “yes, we had sex, she gave me a--” know the story. Relationships with interns notwithstanding, it was the lie that got him in the biggest trouble.

    So don’t do that.
  • Before I finish, I want to point out that I look at trust from the perspective of a project manager. But there’s some really smart people out there who also come at their work from a question of trust. Reading through their blogs, you can see how passionate they are for building trust in their businesses.

    Jo Ann Sweeney, (@commsabilities), like me, looks at trust and honest communication as the heart of successful projects. Very practical and down-to-earth, she offers great, constructive advice on keeping communication flowing.

    Dondi Scumaci (@dondiscumaci) writes of constructive and destructive behaviours that shape us as leaders. A very sensitive writer, she sends a message of being trustworthy and developing trustworthiness in others.

    Scott Stratten (@unmarketing)’s views on trust are implicit in all of his writings on interactions across social media. His position is very pointed at times, but always fun. Incidentally, Scott has a book coming out in 2010 which is sure to be an exciting read.

    You can find all of their writings on their sites linked from their Twitter homepages.
  • Incidentally, if you want to print off and use this presentation in your own meetings, feel free. I’ve deliberately kept my logo off all pages except this one.

    That’s it, once again I’m Geoff Crane, owner of Papercut Project Monitoring, and you can find me online at any of these networks. Feel free to join me and share your thoughts on trust.
  • Top Cause Of Project Failure Noaudio

    1. 1. Why I’d rather you go play in the traffic. or, what’s the ultimate cause of project failure? Image courtesy of lepiaf.geo on Flickr.
    2. 2. • The goal of the project manager is to get to project closure. • All other goals are secondary.
    3. 3. • Follow best practices • Flush best practices down the toilet • Put on an Aquaman costume and stand on a street corner Image courtesy of Otto Yamamoto on Flickr. Do whatever it takes
    4. 4. Doing whatever it takes... Easy when you’re alone. much Harder on a team.
    5. 5. The Problem? Other People! (curses!)
    6. 6. Best practices suggest... • engaging stakeholders early • using clear language in a charter • defining clear roles and responsibilities • establishing measurements Image courtesy of Inno’vision on Flickr.
    7. 7. Best practices leave out... • different working styles • apathy / disinterest • conflicting wants and needs • competing agendas • shame / fear / guilt / embarrassment TR UST • etc., etc., etc.
    8. 8. Trust ˈtrəst Function: noun The trait of believing in the honesty and reliability of others.
    9. 9. Questions of Competence Questions of Character Does he believe he Is he a good Does he really want Can he do it? can do it? person? to do it? Does he have the Do I like him? background for it? ? Will he screw me Does he have I need to remain over? authority over me? Can I tell the truth? professional Questions of Fear and Safety Formulation of Response Yeah, you’re super Thanks! trustworthy!
    10. 10. Yes. Can we trust Yes. them? ? Maybe. I’d rather drink battery acid. We have some concerns. Oh?
    11. 11. Human Retail Resources Finance and Distribution Accounting Information Executive Technology Management
    12. 12. Human Retail Resources Finance and Distribution Accounting Information Executive Technology Management
    13. 13. • The goal of the project manager is to get to project closure. • All other goals are secondary.
    14. 14. • Make an effort B uild • Be trustworthy T rust • Lead by example • Build a communications plan Ma nage • Set an open door policy T rust • Encourage trustworthiness
    15. 15. • Lie, tell half-truths, or spin D on’t • Cover up a lie with another lie • Do what you say Image courtesy of marcn • Be honest about secrets on Flickr. Do • Be forthcoming and open • Be sincere
    16. 16. Gr eat Min ds! @commsabilities @DondiScumaci @unmarketing
    17. 17. [Feel free to tear off this branded slide to use the file in your own presentation]