Making Theory Usable: Tips to Go Beyond the Lesson Learned and Really Change Behavior

  • Sometimes we reflectPMJournalCover
  • Sometimes we use metaphors
  • Sometimes we have constructive conversations
  • Sometimes we assess our impact

There is new research that suggests that if we are able to combine these modes of communication into one game like activity that’s fun and intuitive, we can help our teams communicate more effectively. Dr. Arthur Shelley is developing these ideas in his Reflective Performance Cycle (RPC) and wrote about it in the most recent PM Journal (December 2012).

Metaphor is defined as: A thing regarded as representative or symbolic of something else, esp. something abstract. Using metaphor helps to enable people to talk about behaviors in a way that separates the person from the problem.

M reflecting on how to adjust  to get desired outcomes from pesky civil servants.

M reflecting on how to adjust to get desired outcomes from pesky civil servants.

Reflection is something we already do in the lesson learned, where we think back and analyze what happened in the past.

Constructive conversation is when you use the conversation to achieve an outcome. In other words constructive conversation is a discussion of a subject upon which, at the end of the conversation there is a decision or an action in relationship to that subject.

Impact is something we touch on in the lesson learned sometimes, but this article suggests that we role play and pre-evaluate the potential impact of behavior, before we engage in that behavior.

An Aside

This makes me think about how I set up meetings, aka what-I’ve-learned-to-do-from-leading-crash-and-burn-meetings in the past. When I set up meetings, I always describe the behavior and the method of the meeting. So for example, I might say:

All,

This meeting is to discuss the most recent production push. Please think ahead about those things that worked and those things that didn’t.

We are going to:

1. Discuss what went well
2. Discuss what didn’t go well
3. Brainstorm ideas about how to shore up areas that didn’t go well
4. Decide which changes we can make right away

I think that most agile teams build this type of reflection in with a standard sprint retrospective. But what I’m talking about here is setting up the desired behavior that you want from the team, in advance. By sending a message like this before the meeting you are:

  1. Using a metaphor, brainstorm, to describing the way the team will interact.
  2. Describing the desired behavior from the team. We will think, we will describe, we will decide.
  3. Asking for reflection ahead of time: please think ahead about these things.
  4. Indicating that the conversation will have an outcome; therefore it will be constructive: decide which changes we can make right away.

This type of message engages the human brain in setting the stage. I’ve found this setup to be really useful in getting the desired outcome that I’d like.

But here’s the meat of the matter

The article provides even more delicious ways to engage your team by combining behavior, reflection, constructive conversations, and impact assessment.

One activity that I believe shows promise can be run with a team where “participants can pre-select which behaviors are the the most appropriate for achieving the desired outcomes of each

How to handle all those lions and tigers and bears????

How to handle all those lions and tigers and bears????

conversation, depending on the situation” (Shelley, PM Journal, December 2012, Page 89).

I could see an IT team using this to help smooth communications with their business stakeholders. This activity would be done without the business stakeholders.

In the activity, a deck of cards is used. Each card has a type of animal. Because of cultural conditioning, we all have ideas about animals and what they represent. The lion for example usually represents decisiveness and bravery. While a snake usually represents sneakiness.

Shelley describes this activity:

“The nine members of the group were asked to (Individually) use the cards to profile at least one of their stakeholders with a view to understanding them better.

They were instructed to consider how they should behave in order to secure their desired outcomes from the next interaction with the stakeholder.

Before engaging with the stakeholder, participants were encouraged to role play the planned interaction or at least discuss it with peers.

[Other] participants were asked to record and challenge their thoughts regarding the interaction with the stakeholder in a reflective impact diary template.” (Shelley, PM Journal, December 2012, Page 90).

Breaking it down, the activity goes like this:

Using a metaphor for behavior (the cards) describe the behavior of a stakeholder.

ex. “The project sponsor is a Pirana. Everytime I go to talk to them, its like a feeding frenzy, they jump all over me with everything that could go wrong.”

Think about the next interaction with that stakeholder and consider how the team member should adjust their behavior in order to get the desired outcome.

ex. “I could not jump in the proverbial water! Perhaps if I prep myself by considering the good and the bad that could happen ahead of time, and then approach them with a more complete analysis, I’ll pre-empt the strike.”

Role play the new behavior.

One team member plays the stakeholder. The team member would practice the new behavior while other team members record the interaction.

Reflect on the role play and assess the impact of the change in behavior.

The observing team members share their reflection of the interaction, and adjustments are made.

Like, how come there aren't many koala types in corporate America?

Like, how come there aren’t many koala types in corporate America?

Check out Dr. Shelley’s slideshare presentation to learn more:

Advertisements

Making Theory Usable: A Risk Register for the Rest of Us OR A Few More Reasons for Project Failure

Ahhhh, the LIM Man oh man did I have a great time at the PMI Leadership Information Meeting (LIM). The LIM occurs every year just prior to the PMI Global Congress and it’s a gathering of all the PMI leadership from the branch on up. I went as a leader in the Washington, DC Chapter’s Outreach committee.  First of all, the congress was held at the fabulous, beautiful, glorious Gaylord Palms. I can’t say much for the rest of Orlando because I never saw it. Staying at the Palms with its 7 story high glass enclosed atrium complete with gator ponds (don’t feed the gators), 3 pools and as many or more bars, lounges and restaurants, and an indoor type venetian strollway, was quite enough for me. It was like being on a cruise on one of the massive ships, and the food was fabulous..really wow!  I should ask the Gaylord to pay me for this.

The Gaylord Palms (sigh)  - Didn't want to leave

The Gaylord Palms (sigh) - Didn't want to leave

And there is nothing I love more than meeting people as I’m a bit of a an extroverted geek.  Like.. my team really couldn’t understand that I would actually be happy meeting advanced PM practitioners and talking all hours into the night about project management.  They thought I was going to head for the beach after sessions.  Not.  To me there’s nothing better than reaching across a table and saying “Hey, I’m Michiko from the DC Chapter” and they go “Hi/Hello I’m Ahmed/Karesh/Bea/Lyssa/Judy from the Arabian Gulf/Mumbai/Arkansas/South Africa/Tampa Bay” chapter.  And I miraculously kept meeting the right people.  Like the woman from the Tampa Bay chapter who I just happen to sit next to who is running an awards program like I am (her’s is way cooler so I told her already I’m copying her), or the woman who is starting her consultancy just as I am or..and this is the focus of this blog…someone who I had admired who turned me on to even more fantastic research for me to read.

Cause I’m a Geek – yea, yea, yeah Poor John Estrella, we were just chatting after a session; standard where are you from stuff, I mention I have a blog, he mentions he’s got a book and then I stop and say ‘what is your name? again (because he had told me but ya know, in one ear out the other) and he goes John Estrella and I’m like John ESTRELLA – OMG I so knowyou!Isatthroughyourfinancialservicessigswebinar and yourbooksoundsfascinating and I’msogoingtogogetit and the poor guy. I guess I don’t look like a geek anymore. I look kind of normal now so there are no indicators that I will go off on overly excited tangents about fantastic datasets and their application to the practice, so I think I sort of scared him.

Really?  Quantitative Data on Project Risk Factors?? So COOL!

Really? Quantitative Data on Project Risk Factors?? So COOL!

Anyhow – went and bought the book – yes, downloaded it and read it during off hours at the conference. I have earned my geek wings so this should be no surprise to you.  And the great thing about his book is that he has real data to back up him theory of what he believes are the key reasons for software failure.  I know, so exciting!   Sure there’s lots of theory out there, but his is quantitative data.

Oh Goodie!  A Growing Data Set! For his PhD, John also conducted a fairly definitive review of the literature and theory, approaches, methods and models in project failure analysis.  I mean, its all there.  Remember that it’s a PhD dissertation so the reading is a bit dry for the average reader but if you want to understand all the theory in project failure analysis and how models interface and interact with each other, Identifying Software Project Risks in the Canadian Financial Services Sector is the book to read.

Good Book

Good Book

So that part was cool.  But what’s really great about John’s research is that through this work, he is confirming trends that exist across countries and adding to the body of data which indicates that across cultures, sectors and countries, when it comes to preventing software project failures there are indeed a set of top risk factors that appear again and again.

Why is this valuable?  Well, it suggests that you, IT PM, can start off with that theoretical basis of understanding built right into your project, from the beginning.

Manage for these risks and you have statistically increased your chances for success. And this isn’t just theory anymore kids, its based on hundreds of interviews of real IT PMs like you.   I know, I know – get to the data already. BTW – John calls these ‘Project Risk Factors’ but for ease of understanding, I’m going to call them ‘Reasons for Project Failure’.   Here ’tis:

Top 16 Reasons for Project Failure(Canadian)

  • Misunderstanding of the requirements
  • Failure to manage end user expectations
  • Unclear/misunderstood scope/objectives
  • Scope creep
  • Lack of dedicated, full time project resources
  • Lack of frozen requirements
  • Bad estimation
  • Not managing change properly
  • Lack of top management commitment to the project
  • No planning or inadequate planning
  • Lack of available skilled personnel
  • Lack of effective project management skills
  • Improper Definition of roles and responsibilities
  • Failure to identify all stakeholders
  • Changing Scope/objectives
  • Poor Risk Management
  • Now these are the top factors for Canada, particularly the financial services sector.  John provides a chart where, using this same elicitation technique, researchers in Hong Kong, Nigeria, Finland and the USA, had similar risk factors but slightly different rankings, indicating that there are more prevalent reasons for project failure depending on the context.

    But what about the top 6 reasons for Project Failure advocated by the UK NAO that you talked about last week Michiko?  I knew you were going to ask that. Here is how I see the relationship.  I’ve taken the NAO’s top reasons for project failure and correlated them to Johh Estrealla’s top reasons for project failure.  Here’s what I think it looks like:

    UK NAO Reasons for Project Failure

    Canadian Data Set Reasons for Project Failures

    intent

    Unclear/misunderstood scope/objectives

    sponsor

    Lack of top management commitment to the project

    design/definition

    Misunderstanding of the requirements

    design/definition

    Bad estimation

    design/definition

    No planning or inadequate planning

    communications

    Failure to manage end user expectations

    supplier/vendor

    Lack of dedicated, full time project resources

    supplier/vendor

    Lack of available skilled personnel

    supplier/vendor

    Improper Definition of roles and responsibilities

    project discipline

    Scope creep

    project discipline

    Lack of frozen requirements

    project discipline

    Not managing change properly

    project discipline

    Lack of effective project management skills

    project discipline

    Failure to identify all stakeholders

    project discipline

    Changing Scope/objectives

    project discipline

    Poor Risk Management


    Conclusions and a Free Gift Three conclusions here:

    A good many of these reasons for project failure are in the hands of project managers.    This means that good application of PM methods has a real measurable impact to the success of a project.

    Alignment of theory suggests truth. The NAO UK grouping incorporates the Canadian samples project failure reasons even while the Canadian sample is more explicit about project failure reasons.  But there is an alignment here that a researcher should explore in more depth.

    Commonality across cultures/context suggests truth. Studies in Canada, Finland, Nigeria, the UK, the USA are suggesting similar reasons for project failures.  This suggests that there are reasons that should be considered standard things to mitigate against during a software build.

    This blog is all about making this useable. So I have created a sample risk register with key questions sourced from this theory.  This is a tool you can download and use right away on your project.

    Your Free Gift >> The Making Theory Usable Theory Based Risk Register

    Next Steps for the Outstanding PM Ask the questions of yourself and your projects.  Rank the impact and probability and then take action by thinking about a mitigation strategy for these risks.

    Making Theory Usable Recap: 6 Questions that Get at the Heart of Project Failure

    I realized today that I never wrapped up the Making Theory Usable series.  The idea for Making Theory Usable was to provide useful tips to mitigate for project failure in six key problematic project areas.  I wrote posts based on the top reasons for IT project failure summed up by the UK’s National Audit Office to elaborate how to fix project problems within those areas.  Note that I added my flavor based on my own experience.  To recap, the project failure areas are:

  • Intent Failure – Occurs when the project doesn’t bring enough added value or capability to beat down the obstacles inherent throughout the process.  This suggests the original intent of the project was flawed from the beginning.

    Don't think about it, just use it

  • Sponsor Failure – Occurs when the person heading up the project is not actively engaged and/or does not have the authority to make decisions critical to project success.
  • Design and Definition/Scope Failure – Occurs when the scope is not clearly defined, so the project team is unclear on deliverables.
  • Project Discipline Failure – Occurs when process/project methodology is allowed to lapse so that the mitigation factors inherent in the process are never used.
  • Supplier/Vendor Failure – Occurs when the structure of supplier /vendor relationships doesn’t allow for communication and adjustments.
  • Communications Failure – Occurs when communications are infrequent or honest discussion of project problems and issues are avoided.
  • I have some highly talented PMs on my team and my goal in all of this is to allow them to have the tools they need to quickly ascertain if they are on track for project failure or not.   I think that theory is most useable day-to-day when it can be quickly and easily applied.   To provide a metaphor from emergency medicine, it’s not the fact that you know what the ingredients are in Neosporin, or that a band-aid should be sterile.  Rather, it’s that you know to keep a supply of antiseptic wound  cleaner and  band-aids handy to use right away should the situation arise.  This is the true application that makes theory and science usable.

    In that spirit,  I’ve distilled a list of 6 key questions from the Making Theory Usable posts that help get the analytic juices flowing when trying to figure out where your project is hurting.  I won’t bore you with re-hashing everything in the posts, so if you want more details in each area, links are provided for you above.  Anyhoo, here is a list of questions that can enable you to quickly ascertain if your project is headed down the project failure chute:

    6 Project Failure Questions:

    1. Is the project bringing clear value add and capability?
    2. Is the project sponsor engaged?
    3. Is the project scope clear?
    4. Do the team members/suppliers understand what they are supposed to do?
    5. Are communications frequent and honest?
    6. Is project methodology enforced?

    This list isn’t perfect but if you can answer yes to all of them, I doubt that your project will fail.  If you can answer no to any of them, my suggestion would be to dig deep into that area and see where you can plug the leaks.  If you answer no to almost of all of them, I would say that your project is in deep trouble.

    One of my favorite movies is Crimson Tide, and not just because Denzel Washington is the most beautiful man who ever lived.   I really like that opening scene where the ship is diving into the sea.  It’s beautiful to watch the carefully coordinated sequence of actions and rapid fire communications pull off the very short term goal (mini project) of diving the boat.

    Run your Project like the Navy runs boats

    Run your Project like the Navy runs boats

    Ok – so the analogy is like this.  Think of your project like a Navy boat. There’s the Captain, he’s like the Project Sponsor.  There’s the whole reason you are out on the sea,  that would be the Intent of the project.  Then, there is what you are supposed to be doing on said sea; ie where you are going and what your mission is, that would be the Scope of the project.   The various sailors on the boat are the Suppliers/Vendors on the project.  And you, Project Manager, you are the Executive Officer, the XO (the Denzel), the person making it all happen.  You are manning the communications and ensuring that everyone knows what’s going on, you are following process and methodology.  You’ve got a guy on the lookout, constantly scanning the seas for risks like iceburgs and enemies and you are coordinating it all and communicating up and down the chain.  To the extent that you are disciplined and coordinate and enforce communications, is the extent that your ship is tight.

    Let’s break down this analogy into our project failure checklist areas.

    Intent failure – Is the project bringing added value and capability?  In our analogy, the national interest of the United States combined with achieving geo-political dominance and protection are probably good enough reasons to put some big boats on the water.   I’d say that intent is a good, clear one.

    Sponsor Failure – Is the project sponsor engaged? Well, hey, we’ve all seen the movies with whisy washy Navy captains, but I think that’s probably a bit rare.  Can you imagine if you went to the captain with an issue and he was like “Ya know..I’m just not sure…yeah, I didn’t even realize – where are we again?  Gulf of Mexico? I wasn’t paying attention.  Hmmmmm..maybe we should get a committee to talk about this.”  Not!  You need a clear decision  – and that is what a good sponsor does.

    Design and Definition/Scope Failure – Is the project scope clear?  Not to be confused with intent – this is more about the details of what the mission is.  So, in our analogy, the intent is to protect the United States – no argument there.  But does that mean patrolling lake Michigan against the Canadians?  Probably not .  And then there is even more specifics; ie coordinates, and how you reach those coordinates.   And what do you do when you reach those coordinates?  If you don’t know where you are going and why you are going there, then you’ve fallen victim to the scope failure.

    Project Discipline and Communications Failure – Is project methodology enforced?  Are communications frequent and honest? Well, on a Navy boat, discipline is part and parcel of the game.  So this is not an issue.  There’s someone looking ahead for risks at sea, there’s another capturing important readings and analyzing them, there’s another making sure all the communications equipment is fully functioning.  And they all report to the XO who is monitoring all of it.  The PM is like this.  On your project,  who is watching for your risks? Who is measuring your project variances?  Who is making sure that your communications are happening clearly and deliberately?  That’s most likely you, Project Manager.

    Supplier/Vendor failure – Do the team members understand what they are supposed to do?  On a Navy ship roles are clearly defined, the hierarchy is clearly defined, and when the time comes to act, everyone acts in unison as a team.  For us landlubbers, it’s not that easy, but the important point is that everyone knows their role and that everyone understands the mission.   Further, there’s got to be flexibility for changes from the bottom up as well as the top down.   Communication has to go both ways, if an ensign observes something that can affect the boat, the XO should listen and allow that ensign to adjust so that the mission is satisfied.

    Final Thought  I think there’s a lot to be gained by looking at the world around us using the lens of the 6 project failure questions.   You can ask these questions of sports teams or community organizations or political action committees…or YOUR projects.  If anything, they’ll help point you in the right direction if you get a funny feeling about your project, but don’t know where to start digging.

    12/17/2009 Update – TechRepublic created a video from the content of this post – check it out >>>>http://blogs.techrepublic.com.com/hiner/?p=3464

    Making Theory Usable: Communication Skills to Beat Down the Barriers

    The wrong way to the locker room

    The wrong way to the locker room

    The Importance of Communication

    Poor communications can be a project killer.  Frankly, all the documents you create, all the ways and means of project management theory boils down to two things; project discipline and communication.  Project Discipline provides the tools and methods needed to be able to communicate effectively. I see these as the two foundational underpinnings of project success.   They are the ying and yang of Project Management. Further, Project Management and communication is like Julia Childs and butter or Tiger Woods and a Golf Club or Babe Ruth and a Baseball bat…you get the idea.

    The Problem with Communication  Google analytics is so brilliant – I’m able to see what people are looking for, the words they enter into the search engine, when they hit my site.  At least 50% are looking for communication barriers.

    Google Keywords of People Searching for info on Barriers to Communication

    Google Keywords of People Searching for info on Barriers to Communication

    My Making Theory Usable series is about, well, making theory usable, which means that I find the theory and provide tips in what has worked for me out of the various theories.  So I thought it would be good to provide people with a list of ‘what to do if’ situations and briefly describe the theory and link to more detail about that theory, which I do below. Before that though, and the bottom line, ie the reason I believe bad communications are still successfully bringing down projects, project managers, organizations and careers are threefold:

    1. Good Communication is Really Really Hard. Its hard to a) really say what you mean  b) say it in a way that doesn’t piss anybody off and c) really understand and hear what others are saying.

    2. Good Communication Takes Practice. While the theory is out there and most people know it, without practice, you won’t know how to use it when the time comes. Good communication is more skill than knowledge.  As a skill you can learn it and improve it, but you have to practice it to be good at it.

    3. Good Communication Feels Uncomfortable at First. Good communication won’t be easy at first.  Something about it will feel uncomfortable to you; whether its keeping quiet while you actively listen, pulling judgment out of your language, or speaking without accusation, at first, its going to be hard.

    Because I have a master’s degree in Conflict Resolution and I’ve trained others in anger management and interpersonal communications, and conflict styles, I’ve had to practice the skills over and over again.  And it comes out when, for example, I find the common goal in the midst of conversations with my adversaries, or manage to restate problems even in the middle of arguments, without accusations.

    Before we get to the wealth of resources available in communications, I’d like to present what I believe should be a PMs basic skills in communication – the bottom line skills. These are the personal skills you bring to the table that will help you no matter which of the theories and tools below you choose to employ.

    1. Removing accusatory “YOU” from your vocabulary. Removing accusatory “You” from your vocab is when you describe your opinion to someone else without using the word ‘you’. The key here is the reaction people have to the word ‘you’. When used to indicate displeasure, as in “you failed to properly test this function”, the immediate response of most human beings is to protect themselves. The response will most likely be “No I didn’t.” So instead of “you failed to properly test this function” rephrase it to “this function wasn’t tested.” That way, the tester will get into the specifics, a fact finding mission to figure out if it was tested or not. What you won’t have with “this function wasn’t tested” is the heated argument with the tester about wheather or not they are doing their job, which is what “you failed to properly test this” implies.

    More on You Messaging: http://www.crinfo.org/CK_Essays/ck_iu_messages.jsp

    2. Active Listening. Active listening means to basically shut it and listen. When you don’t focus on your reaction to what people are saying and instead focus on listening to what they are saying, then you are actively listening. The point here is to stop your mind for a second, stop your opinion making for a second and really grasp what the other person is saying, even if you don’t agree. The best way to do this is to not say anything (I told you this was hard) while you listen. Active listening goes hand in hand with paraphrasing.

    More on Active Listening:http://www.mindtools.com/CommSkll/ActiveListening.htm

    3. Paraphrasing. So, if you have been actively listening, in theory you should be able to perfectly restate what the other person has said. This is the ‘so what I hear you saying’ piece you’ve probably heard before. The point here though, is to be sincere with it. Don’t just throw, ‘so what I hear you saying’ in front of every sentence. Instead, force yourself to accurately restate the other’s opinion almost as if it was your own. Ok…so.. this is very difficult. But I have done this with my ex-husband, in relation to what he thought of me. That was…interesting. But, so VERY POWERFUL, to move communications forward.

    More on Paraphrasing:http://www.directionservice.org/cadre/section4.cfm#Reflective Listening Skills

    http://www.videojug.com/player?id=4806dc69-7129-446d-9007-ff0008cb45db
    Communication Skills:
    Basic Listening Skills – Clarifying & Paraphrasing

    Communication and Barriers to Communication

    Communication is defined as  “the imparting or interchange of thoughts, opinions, or information by speech, writing, or signs” Wikipedia.  So when we say that there is a communication barrier, it doesn’t mean that communication is not happening.   Even in situations where people are actively arguing, communication is happening.  So that implies that when we are talking about ‘communication’ which by definition is quite broad, we are really referring to ‘good’ communication.

    Good Communication is harder to define.  That’s because good communication is actually how people communicate, not communication itself.  Good Communication is a set of characteristics that include the following:

  • Clear Understanding of the other
  • Allowance and acceptance of different ways of understanding
  • Allowance and acceptance of different ways of communication
  • Lack of judgment
  • Consistency and Frequency
  • Note that Good Communication is not always the absence of conflict. Good Communication will surface existing conflicts but the people in conflict will communicate their difference based on the characteristics described above. In other words, conflict will always exist, difference of opinions will always exist. But it’s the method, the characteristics, the way in which you communicate to each other about the differences that, well…makes the difference.

    I am a very direct person. Give me an elephant in the room and I will pick it up, throw it up in the air, juggle it and then insist that everyone deal with it. I have had legendary showdowns with my co technical lead and senior business analyst while the rest of the team members watch in either amusement or horror. We call it ‘fighting in front of the kids.’ But you know what? We always walk away with no harm, no foul because the bottom line is that we respect each other. We respect our differences, we appreciate each other’s domain knowledge, we aren’t afraid to admit being wrong because we don’t get attacked for it, and we relentlessly pursue truth. And this team of 20 developers and analysts are successfully managing 4 projects including an enterprise wide intranet rewrite, a sharepoint workflow app, and a .net web app. People are thriving, growing, learning and we are moving up the CMMI chain. I believe it’s all based on a solid framework of good, honest, deal-with-it communications.

    So, what is a communication barrier? Well, a communication barrier is, quite simply, something that prevents good communication as defined above from happening. The barrier could be from a person, or an interaction between two people, or from interactions between groups of people, or physical impediments.

    Scenarios and Links to Theory  I like to think of approaching communication barriers by thinking of my relationship to the barrier. This is because the tools I use will be shaped by where I sit in relationship to the communication barrier. Am I part of the group that is conflict, or am I outside the group that is in conflict? Or, and this is always great if you can recognize the benefit of newness, am I part of the group that is in conflict, but new to that group? These are the ‘what if’ scenarios I was referring to early.

    Scenario 1 – Part of It: What If I’m facing a communication barrier and I belong to the one of the groups in conflict.  If you are part of a group that is causing the communication barrier, you face a loss of credibility from the opposing group. They probably won’t trust your good honest efforts..at first.  In this scenario you can use the following tools:

    Scenarios 2- New but Part of It: What if I’m facing a communication barrier and I belong to one of the groups in conflict, but I’m new to that group.  If you are part of a group that is causing the communication barrier, you face a loss of credibility from the opposing group. But you have an advantage. Because you have no history with the party your group is in conflict with, in the beginning, you can be peacemaker without as much lack of trust from the other party. In this scenario you can use the following tools:

    Scenario 3 – Not Part of It: What if I’m not part of either group causing the communication barrier.  In this scenario, you are external to the conflict. The benefit is that there is no ill will towards you, the problem may be that you may have difficulty getting parties to the table. In this scenario you can use the following tools:

    Final Thought  I’m only touching the surface of all the resources available to you on the web for free. The links I’ve given you link to other sites and suggest books, articles and videos. Bottom line – conflict, communication barriers and poor communications are a threat to every project. Don’t be afraid of it – rather, expect it and prepare yourself for it through practice practice practice.

    Making Theory Usable: Intent Failure or Why the Heck are we Doing this Project?

    Ever been on a project that seemed like a complete waste of time and space? The kind of project where you shake your head going “why are we doing this?” Sometimes the project is bad because it started out good but fell apart in the middle.  But sometimes the project is bad because it never should have been done in the first place.

    That kind of project, the one that had issues from the start and what to do about it, is the subject of this fifth post in the series Making Theory Usable.   ‘Intent Failure’ is the ‘this probably wasn’t a good idea in the first place’ reason for project failure.

    Find your Gladys

    Talk to Gladys. She knows EVERYTHING.

    Talk to Gladys. She knows EVERYTHING.

    Sometimes you don’t have to automate everything. I call this the Gladys in Accounting principle. There’s a Gladys in every company. She’s been there 20 years, seen systems come and go and knows the motivations and aspirations of everyone from the CEO to the Janitor. She is the smartest person in the company but nobody knows it because she usually has an administrative position doing the paper pushing nobody else wants to do.

    I think that every CIO should find Gladys and ask her if that new CRM or ERP project will make sense. If you do, Gladys will give you and earful about how you’ll spend money on a project that everyone will pretend to use and actually never will. This is what happened to VAs eCMS project. The project was supposed to give the VA the capability to get a clear view into all its procurement activities. This meant two things; integrating data on the backend and providing a user friendly front end.  The VA canned this project because it didn’t achieve integration of data, user feedback was horrible and thus users refused to use it. The system failed to integrate and the users failed to use it.  I gather from the report that integration was an obstacle and so user refusal may have been there from the beginning of the project.

    “ eCMS is very cumbersome and not very intuitive, frequently frustrating. What I use to do in one day takes a week.” from the VA Audit Report

    Ultimately, I don’t think this project made it past the silos.   System integration is intimately intertwined with silos.    I think that a pre eCMS conversation with Gladys would have sounded like this.

    CIO: “So Gladys we’re thinking of integrating system a and system b.”

    Gladys: “Hmpf. I told them 10 years ago system b and c should never have been built. But what do I know. I’m busy need anything else?”

    CIO: “Well, do you think it will work?”

    Gladys: “Work? Are you kidding? Manager b and manager c haven’t talked in years. They can’t even be in a room together. And you want to connect their software? Plus, I don’t care if you’re a nuclear engineer, you’re not going to be able to put process b into a computer. It just won’t work. It doesn’t work now! That’s why they never use system b. You gotta have a human being do that work.”

    Never Underestimate the Power of the Silo.

    What Gladys is hinting at is a lack of will due to silos, politics and turf wars that impact systems and that IT PMs have got to get a better handle on.

    Scary silos should not be ignored.

    Scary silos should not be ignored.

    Silos are groups of people in organizations that have their own business process and/or systems. Between silos there can be turf wars where groups vie for budget, resources and influence. Lots IT projects that seek to merge the silos, so that executives can have better intelligence on their operations. But the system that merges, also takes away a certain amount of independence from the silo. Further, taking away an older system/process can be perceived as a threat to power and influence. That’s why there can be significant resistance to new systems.

    The one thing that new systems have going for them is a reduction of pain in the current process. If the silo’s process is painful and difficult, then there should be greater will to adopt a new system, even if it means a loss of power. But if the pain of current process is not significant, then that’s two strikes against anything new; the perceived loss of power, and the perceived pain of switching to a new system.

    Back to the eCMS project.  The project should probably have focused on integration while incorporating current process as much as possible.  Had the project taken change in small chunks and worked more on backend integration first, it may have bypassed and mitigated for turf wars.  Instead, it built the user front end before the back end integration was done.  So it forced change on the users but couldn’t give them enough benefit for doing so; ie reduce thier pain.

    More great eCMS user feedback:  “Not sure what other agencies use but I’m sure it isn’t eCMS. If another vendor comes into play, please ensure that they have tested every aspect from the contracting officer’s point of view and not force the VA to use a program that is impossible to use and now we’re stuck with a program that is totally useless, difficult and not user-friendly.” from the VA Audit Report

    I’ve heard IT PMS brush that good info about silos under the rug , assume that users don’t know what they want, or take a ‘dumb user’ approach to silo’d lack of will. But I’ve seen projects drag on way past deadlines because of turf wars. I’ve seen good projects killed at the last minute because certain groups refused to use them. I’ve seen very good senior people let go because of new system induced political battles. Change is hard and change is near impossible if people are unwilling. If you don’t consider that in your project planning, then you invite the inevitable slowdowns and failures that will occur.

    If it ain’t broke enough, don’t fix it

    Gladys is also hinting at the ‘don’t mess with the current process’ idea. Meaning, sometimes the seemingly antiquated way of doing things is that way for very good reason. And the day-to-day operation you’re seeing on the surface is the tip of an iceburg of years of reasons as to why the process is not automated. As an IT PM, you need to find out what those reasons are.

    I was on a project where the users admitted that their current process was painful. They needed 40 people to process paper and to make decisions. They actually wanted to reduce the pain, but the vendor doing the work completely underestimated the level of complication of the process. Business users kept trying to tell the IT PM that they didn’t get it and it wasn’t until development started that it became clear that the purchased system could not handle the details those 40 people were handling. Eventually, the project was killed because of this.

    I’ve been intuiting this on my projects and making adjustments or recommendations based on these two beliefs, that sometimes the silo is too powerful and sometimes the existing process works well enough.

    So I’m quite pleased to see that there is good theory out there that says this same thing. ISACA’s ValIT framework incorporates this thinking into its model. In their guidance for avoiding pitfalls of typical IT projects, they suggest steps that IT planners can take to mitigate silos and understand existing processes.

    IASCA Val IT Suggestions for Overcoming Issues

    IASCA Val IT Suggestions for Overcoming Issues

    More importantly, and what appears to be new for me, is the inclusion of this thinking directly into the model. That is, if you use the ValIT model, you will be asked to consider the questions that come up around silos and existing processes. I’m not fully familiar with Prince2 or OPM3 and the guidance they give in IT planning or valuation, so I’m not sure if this idea is new; it could be out there already.

    But I do think it’s a bold positive move to include IASCA’s ‘keep what works’ and ‘understand the silos’ thinking into your own project planning.

    So, how do you make all this usable. Here’s what I’ve done that worked for me:

    Pre Project:

    1. Understand the Silos. At the beginning of the project, find your Gladys in Accounting. Understand the silos and politics and respect their power to prevent you from being successful. Sometimes you have to work around the silos, or not incorporate them at all. Use the ValIT guidance to mitigate for silos.

    2. Keep What Works. Understand that sometimes processes work find just the way they are. You have to think about the sweat and tears you’ll entail by changing the process and if that’s really worth the cost of a new system, or even if the new system can handle the process. Realize that there are some processes that only people should do.

    During the Project

    Of course, it’s easiest to consider these questions before the project and if you have some power to change the project. Most IT PMs who aren’t doing IT Governance don’t have the authority to make these decisions. So if you are stuck with a project where you clearly see it doesn’t make sense, I suggest writing up an Executive Brief and presenting it to senior sponsors. This should operate as your ‘time out’ conversation.

    The Time Out conversation

    1. State the facts – Briefly and without judgment state the facts. Instead of “This project makes no sense” say “This project is facing significant risk of failure.” Then list out the reasons why. You can reference ValIT framework to connect your ideas to published theory.

    2. Quantify in numbers – If you think that the current process works well and shouldn’t be replaced, try to get metrics. How long does the current process take from start to finish? Will the replacement process be faster or just automated? If you are facing significant slowdowns because of silos and turf wars, do an accurate estimate in your project schedule of how long socialization of change will take.

    3. Plan out the alternatives – Write down possible solutions. Maybe it’s better to only automate part of the process but let the rest stay. Or perhaps you could plan out leaving a whole department to itself, rather than trying to include them in the new system.

    I’ve done this type of brief on two projects; one was a CRM implementation where the level of business process complication was so deep and entrenched that it didn’t make sense to automate it. The other was a system to automate workflow when the business users weren’t really complaining about the current process. There really wasn’t any will around making the change and there were silos who would have to come together that didn’t really like each other. So in my brief I included an estimated 6 months of socialization and acceptance into the schedule.

    I wrote up the briefs and made the presentations. On the CRM project, the project actually came to a halt. The workflow project continued but the sponsors decided to go agile to force the silos of people to huddle every day.

    Final Thought

    IT PMs would do well to follow their instincts. I’ve talked to many friends who know these issues exist but don’t know how to broach them with management. I hope that the few tips I’ve offered here will help. In the end, even if things don’t go your way, the process of writing up the brief and making the presentation is very good CYA when things, as the are apt to do, fall apart.

    Making Theory Usable: Disciplined PMs Don't Fail

    This fourth post in the series Making Theory Usable focuses on the lack of Project Discipline as a core cause of project failure.

    What is Project Discipline?

    Discipline is defined as “The systematic instruction given to a disciple. To discipline thus means to instruct a person to follow a particular code of conduct

    Further, self-discipline is defined as “.. the training that one gives one’s self to accomplish a certain task or to adopt a particular pattern of behavior, even though one would really rather be doing something else

    The disciplined PM - Well prepared for all risks, changes and tests.

    The disciplined PM - Well prepared for all risks, changes and tests.

    If Project Management is a true discipline, and if you are a PMP you have signed a Code of Conduct, then you are disciple of project management, grasshopper.  ;>  I won’t go there, but my point here is that project failure does carry an interwoven thread of project discipline failure. The less disciplined the PM, the more likely the project is to fail.

    So what exactly is ‘discipline’ in Project Management? Well, to grossly oversimplify to make a point, the PMBOK boils down to the tools you need to think about project stuff, and the documentation of that project stuff.

  • There are the tools you use to determine risk…then the documentation of risk
  • There are the tools you use to figure out scope…then the documentation of scope
  • There are the tools you use to figure out stakeholders…then the documentation of stakeholders
  • You get the idea.

    I think that there are two aspects of PM discipline; physical and strategic.

    The rigorous and continued use of tools and documentation is the physical aspect of the discipline. This physical aspect of discipline in Project Management leverages the power of the written word.

    Roll up your sleeves - Project Management is physical job

    Roll up your sleeves - Project Management is physical job

    Note that it is the written word, not the spoken word, that changes things and makes things stick. Think about that. JK Rowling would still be an administrative assistant if she hadn’t written what was in her head. The spoken word is an ephemeral temporary thing; it morphs into something else moments after it occurs. The vibration of that soundwave travels and you no longer hear it, and so it’s gone. Writing down the temporary spoken word transforms it into permanency, it captures it and ensures longevity. It gives the temporary thing, the soundwave, long lasting and permanent power.

    But the real reason behind Project Management discipline, ie the end result of Project Management, is the discovery and elaboration of strategic direction and action to ensure success. In other words, the physical aspect of Project Management discipline results in knowing exactly what to do and when in order to reach your goal. It’s the strategic thought, the laying out of the plan, the decisive action that is the heart and soul of Project Management discipline.

    There’s a lot of What’s In It For Me (WIFFM) in PM Discipline. Discipline actually ensures your protection and success. This is because using the tools and documentation make you think. Thinking makes you do the right thing before something goes wrong. Then you take effective, strategic action that ensures your success. This is the strategic aspect of Project Management discipline.

    And isn’t that that what planning (as in scope plan, comm. Plan, QA plan, project plan) , and this profession in general, is really about?

    Key Discipline Areas to Mitigate Project Failure

    I admit that I don’t use all the tools in the PMBOK but caveat that to say that I’ve worked in large and very small businesses and I haven’t seen one organization or PM that religiously uses all of them. More worrisome, I’ve talked to PMs who believe that using the tools is a waste of time.

    I have observed that PMs who are more disciplined tend to have less project failure. They just don’t get into the same binds that non-disciplined PMs get into.

    They don’t get into the arguments about who said what. Their teams don’t break down into us-them silos They don’t miss requirements. Their product works. Their users like their product. Their projects don’t get shut down by angry sponsors.

    Always Works

    Always Works

    We don’t hear about the disciplined PMs too much. They just go about their day doing great things. I think about these PMs when I’m using Amazon, and it always works; or Google, and it always works; or ChevyChaseBank.com, and it always works. Behind the every day success of these every day apps lies a disciplined PM.

    I think that if all PMs regularly used the tools and documents in the following key areas, and took strategic action based on the use of these tools, we’d see a lot less project failure. These areas and the tips below represent areas where I have personally witnessed project failure. These are the areas that keep cropping up again and again in the project management literature.

    PMs would do well to be more disciplined as follows:

    Scope

  • Ask the right questions from the start.
  • Connect your project to key strategic drivers.
  • Actively seek answers to the triple constraint; know your sponsors priorities.
  • Build a work breakdown structure.
  • Determine success criteria, discuss and document your assumptions and constraints.
  • Document this in your project charter, project management plan and your scope management plan.
  • Build a schedule and keep it up to date.
  • Communications

  • Do a stakeholder analysis, stakeholder registry and stakeholder management strategy.
  • Establish the right project sponsor
  • Look at communications paths and methods.
  • Figure out where the weaknesses are. Create a communications plan.
  • Enforce recurring meetings and meet with the project sponsors at least once a month.
  • Don’t rely on paper status reports. Talk to people in person.
  • Document the communication immediately in agendas and meeting notes.
  • Use collaborative software to make all communications and decisions visible.
  • Risk Management

  • Identify risks before you begin the project.
  • Involve your stakeholders in mitigation strategies.
  • Build and actively maintain a risk register.
  • Make risks visible and constant in project meetings and communications.
  • Risks are always a standard discussion item.
  • Change Management

  • Create a change control board (CCB) from the start of your project.
  • Involve key stakeholders in the CCB.
  • Insist that all changes follow the change control process.
  • The change control process should have a visible record of requests and decisions, documented in either a system or on paper.
  • Quality Assurance (IT specific)

  • Create test scripts.
  • Test your product against your clearly defined initial scope and success criteria.
  • Test your product against your clearly defined changes.
  • Keep your scripts up to date.
  • Setup a unique test environment, as close as a mimic to production as you can.
  • Insist every change goes through the change control process.
  • Simulate production loads and threats as much as possible.
  • Final Thought

    I read a lot about project failure. And there are a lot of reasons why project fail but I do firmly believe that there is a continual thread that runs though all of them and that is project management discipline. It’s like the failure of project management discipline has many manifestations; in one project it manifests as scope failure, in another, it manifests as QA failure and in yet another, it manifests as risks that weren’t headed off at the pass.

    A Disciplined PM can Make all the Difference.

    I end with a thought from Sun Tzu: The consummate leader cultivates the moral law, and strictly adheres to method and discipline; thus it is in [thier] power to control success.

    Making Theory Usable: Ideas to Mitigate for Supplier Management Failures

    This third blog in the series “Making Theory Usable” focuses on the Supplier Management Failure, the third of 5 key indices of IT Project Failure described by the UK National Audit Office (NAO). By ‘Supplier Management Failure’ , the NAO is referring to failures sourced from procurement and communications issues between the IT supplier/vendors and the contracting company or agency.
    It’s clear that problems exist. Here is a fresh list of supplier management IT Project failures that have made the news:

    Pentagon kills the 6.3 billion KEI program
    The VA suspends 45 IT projects
    The UK government kills the Scope Program

    There are two sides to this Supplier Failure coin; the contracting company/agency and the IT supplier/vendor. I’ve been privileged to see this world from both the company and the supplier side. So I’ve assembled tips for IT PMs in both camps sourced from on-the-ground experiences and interactions.

    Specifically, I think that Supplier Management Failure occurs three ways:

  • Lack of Project Discipline – Project discipline is inconsistent in vendors resulting in very few indicators or early warnings of project failure. In addition, many smaller vendors don’t have the resources or expertise to properly manage projects along world class standards.
  • Diffusion of Scope – As the work is broken into smaller components, the original intent of the project is diffused. The returned business benefit is usually communicated at the initiation and planning stages but ceases to be communicated during execution. So it’s possible for builds to become increasingly off course from the original scope.
  • Inflexibility of Contracts for Change Management – Most contracts are tough to change and involve vetting through layers of approval. This process takes time and energy and can be so difficult that it won’t even be attempted. The result is that contracts cannot adjust to ideas for improvement or worse, should it be clear that the laid-in course is wrong, that course will continue because of contractual dictates.
  • Ideas to Mitigate for Lack of Project Discipline Many companies don’t have the resources to spend time on their own internal project discipline processes. The result is that process is hit or miss depending on the person running the project.

    It’s a matter of degree per company, but I’ve seen situations where schedules didn’t exist, or requirements documents were never written, or code is routinely pushed directly to production, bypassing any QA.

    That is why some vendor’s make their deliverables and most don’t. Take as evidence the VA’s recent attempt to enforce deadlines in IT suppliers. Unfortunately, 45 projects could not produce evidence that they could get their projects back on track, and were put on hold. For smaller shops, I’m sure this action is devastating. Here are suggestions to mitigate for lack of project discipline:

    Train the Vendor in PM Basics

    Contracting companies/agencies are never going to be able to fix all the project discipline failures in their suppliers.

    It’s not enough to insist on a set of deliverables on a project. The NHS project for example, is currently riding rough waters, but they did provide training to their vendors on project management process. So the documentation is there, but the deliverables are still lagging.

    I would argue that we have to go simpler. We can’t say to the vendor “here produce all this documentation” and assume that they are properly managing the project.

    Often, It’s the very basics of project management that are being missed – understanding how activities fit together and when to do what; ie proper activity identification and scheduling. Never assume that the vendor/supplier has the basics of project management under control. It’s better to assume that they are new to project schedules and scheduling software.

    Understand that the supplier may need training on how to generate project metrics and build in mandatory training for all vendor PMs into contracts. If you can, provide scheduling software to them and insist that they use it.

    Keep Metrics Simple

    Contracting companies/agencies should insist on metrics and milestones that provide a sort of early warning system on projects.

    The fact is that Earned Value Management (EVM) is not achievable in smaller vendors for either lack of project knowledge, lack of EVM knowledge or inability of systems to support cost analysis. So the metric should be simpler.

    Review the schedule with the vendor, baseline it and then help them understand milestone/delivery dates. Use a simple duration variance on milestone delivery dates. I like duration variance because it’s easily to grasp and understand even for the project management novice. More importantly, it provides early warning, which, if meetings are occurring frequently, can be caught and dealt with early on.

    Ideas to Mitigate for Diffusion of Scope This happens because vendors either didn’t understand what was supposed to be delivered from the beginning or they got off track and weren’t bought back to the vision because communication wasn’t occurring.

    Work to Ensure your Vendors Understand your Scope

    Once the project gets up and running, don’t turn over work to the vendor and then forget about them until the work is done. Rather, incorporate frequent visits into your quality management plan and or procurement management plan.

    During those visits, prepare a brief that explains the full project scope to vendor staff. Help them understand the problem that generated the project and how their work contributes to the solution. Weather its building a missing capability for a warfighter, or enabling an association to organize its members to meet its mission, the original intent of the project, the intended benefit, is what should be communicated, in addition to contractual deliverables.

    Finally, visually demonstrate, either through a work breakdown structure or organization chart, where the vendor fits into the whole project.  Rinse, lather, repeat -really!  Repeat your message often, don’t assume that one or two visits is enough.  Make it part of your process to discuss the project vision frequenently, to as many team members as possible.

    Communicate Frequently and Collaboratively

    In your communication management plan, build in weekly and monthly project reviews. The weekly review should be at the management level and should include a review of risk status, schedule status and deliverables status at a minimum. The monthly should be executive level and should review risk status, schedule status, resource status, budget status and deliverable status.

    These meetings should be vocal, that is, don’t just allow yourself to receive a project status report; talk face to face or phone to phone. Frequent communications are the best remedy for finding and fixing problems early in the project, and for making course corrections.

    Incorporate collaborative technology, such as wiki, or SharePoint and start discussions where staff from vendors and contracting companies/agencies can communicate frequently. Encourage honest and frank communication about project issues within the technology. As a PM you set the stage for the tone of communications, so if you are open about issues, your staff and the vendor staff will open up as well.

    Putting these discussions in collaborative spaces increases chances that you’ll see problems early on, before they become insurmountable. Even better, project staff may start to build a sense of team, instead of a low-level us-them mentality.

    Ideas to mitigate for Inflexibility of Contracts for Change Management – The paradox of projects where work is contracted out to vendors is that contracts put in place to ensure the work gets done, set up structures of bureaucracy that present barriers to achieving the project vision.

    The end result is that vendors would rather produce a deliverable they know is no longer relevant, rather than work to change the scope through a contract modification.

    This is a difficult problem and is so deeply entrenched that the government recognizes this problem and has set up a commission to figure out what to do about it. For the average vendor/supplier IT PM working on a government contract, you will hit this barrier.

    Don’t be Afraid to Talk About It

    This is such a tricky subject because there are so many conflicting motivations when it comes to contracting. Your company wants to keep the contract with the government, your COTR doesn’t want to go through the hassle of a contract modification, your government clients are probably facing down political battles to make any kind of change, and you want to deliver a successful project.

    I would suggest that you at least raise the issue and document that you’ve raised the issue. Bring up the need for change verbally and in writing. In most cases, you probably won’t be well received, and be prepared for that. Recognize that the probability is that nothing will happen, and that nobody will move.

    Understand that you are not alone in understanding how difficult it is to change. The commission on wartime contracting report says specifically, “These issues are well documented, but the dilemmas they represent are also deeply rooted and resistant to change.” This NASA video makes clear the types of reactions you can expect:

    So think of this action as a small push on a very large stone that may or may not send it rolling down the hill. Prepare for realizations to happen months or years down the line, and then produce your documentation then about the time and date you raised the issue. This will protect you and your company in the long run.

    The Vision Keeper

    In a previous post I describe the Work Breakdown Paradox in detail. I also advocate for a new type of position, the Vision Keeper:

    “These people would exist solely to:

    • Be the keeper of the intent and vision
    • Recognize when group dynamics are creating barriers to meeting the vision
    • Form the continual repeatable communication mechanisms to get the right parties at the table to discuss the Work Breakdown Paradox
    • Have the freedom to honestly state the issues without fear of repercussion

    These people of necessity need to be outside of the bureaucracy. They have to be able to challenge without fear; fear of losing a contract, fear of appearing out of line, fear of losing a job.”

    You can read more about the Vision Keeper idea here.

    Final Thought

    I think of the serenity prayer when it comes to Supplier Management Failure

    God grant me the serenity
    to accept the things I cannot change;
    courage to change the things I can;
    and wisdom to know the differenc
    e

    Change what you can, mitigate for the rest.