March 19, 2012 | Author: PM Hut | Filed under: Lessons Learned
How to Tear Down the Organizational Silos That Block Project Success
By Richard L Grimes
Here are two methods for dealing with those organizational silos that can block successful project execution:
1. The Pre-project “Post Mortem”
Research conducted in 1989 found that prospective hindsight - imagining that an event has already occurred - increases the ability to identify reasons for future outcomes by 30%!
Using that as a foundation, we suggest you try leading your team’s pending project in assuming it has failed in a spectacular fashion - not just asking what could fail.
This assertion of what has happened instead of what could happen will help the team visualize the hypothetical disaster more clearly to avoid it in reality.
No, this is not another walk down the heavily-trafficked project preview road asking, “What could go wrong with our project?” It will be much more direct than that. Also, it’s not an exercise in risk analysis that assumes we’re going ahead ‘as is’ and asking “what is the risk if we do?”
The project’s manager and key members should meet before the project planning stage (if possible) and assume the project failed totally and completely.
Then, if the findings from that 1989 research are correct, use the best brains on the team to identify what led to its hypothetical demise. Once you know what led to it, steps can be taken to prevent that from happening.
Albert Einstein is credited with saying (paraphrased), “Insanity is doing things the way you always have and expecting different results!” This article helps you go upstream to identify what (hypothetically) went wrong to kill the project and change those things so they do not lead to the same disastrous outcome.
We suggest a brainstorming session to collect from the project’s key members reasons for the project’s (hypothetical) failure. Although there are many ways to do this, here is an easy way that has worked well for me in the past.
“Around the Table” is when everyone adds an idea while someone records them. If they do not have an idea, they just say “Pass.”;
No evaluations or opinions on ideas presented are allowed from members - just solicit their ideas. Keep going around the table until everyone has exhausted their ideas and has “passed”.
Additional Critical Questions
After you have collected your team’s speculations on the project’s “death”, ask these additional questions as a way to make sure you have considered as many contingencies as possible.
- What are our intended results and measures for this project overall?
Do they include specific measurements of quality, quantity, and time or are they ’soft” and focused more on intangibles such as a “satisfied client?” Using measurables, at what point is the client satisfied? Is it an either-or event (”satisfied -Y or N?”) or can there be degrees of satisfaction?
Do we have progress measurements for each functional group within the project so we can monitor their progress, too? Since the overall project outcome is the sum of the success of the functional parts, how will we know if things within the lower portions of the project are going well?
What challenges can we anticipate that may have not been identified earlier?
How well do we communicate with each other in the project? With our vendors?
Are there clear channels of authority and responsibility or is there a danger of ‘turf wars?’
What have we learned from previous projects like this?
Have any of our project members been on projects like this that can help us get an idea of what may happen?
Can we create lists of activities we should start, stop, or continue doing on this project that can act as a lesson learned from other projects?
How can we share the learning throughout our team?
What will make us successful this time based on what we have learned from the previous attempts? (The Albert Einstein ‘insanity’ definition again.)
Can we break the large project down into smaller chunks for easier analysis, measurement, and monitoring progress?
2. Writing the Project’s Obituary
Once the PM and any assisting key project members have a list of issues that theoretically killed the project, he or she can begin taking steps to remove the potential problem or develop a work-around that will diminish its impact.
For example, some potential reasons for failure could be:
- “We have functional silos keeping us apart. Marketing promises anything and engineering has to figure out how to deliver what those dreamers promised! It’s no wonder that we don’t get along!”
If you know those silos exist, what can you do before starting the project to reduce their potential for damage?
“The project champion left and momentum just died” - What would you do as a precaution against that?
“Our source for the critical component went bankrupt and delivery stopped.” Should you develop a ’safety net’ by having some backup in place?
“We never heeded the warning signs that the project was slipping beyond recovery.” What are the signs that could tell us this? How can we monitor them to make sure we don’t have this happen this time?
Some of the topics you receive may seem to be so farfetched that they defy reality while others may seem so obvious you wonder why someone took the time to write them down.
This process of collecting reasons the project died is about getting as many ideas as possible as early as possible. Save the judgment until later because you do not want to inadvertently discourage anyone from speaking up.
Please remember this: the most valuable idea may come from your least expected source.
Richard Grimes has used his 30+ years experience in training and operations management for private and public organizations as a foundation for his company, Outsource Training.biz LLC.