It’s everywhere I go. If there is more than one project or one department involved in project management, then Silo management is almost always in place. For those of you who haven’t heard this term before, this is a condition where multiple groups are working within the same organization. They share something in common. Sometimes it’s a project, sometimes it’s resources. Sometimes it’s both. These groups may share common goals but they don’t share much else. Silo management is where these groups strive to work in isolation, putting their own priorities ahead of those of the organization overall.
Now, I’m sure this isn’t the case where you work. No doubt you’ve been able to overcome this. However, if you should have the misfortune to run across this phenomena, here’s what you’re in for.
Silo management isn’t caused by employees who are looking to be destructive. It’s almost always starts with a management structure that includes people trying to do more with less. Under the pressure of producing results, some managers find they are penalized for being too forthcoming with their project information. It happens like this. A manager trying to be a good corporate citizen reveals that his project is ahead of schedule. He has managed to have his staff work so effectively that they are going to be able to coast this project to a completion.
Bad news.
Other managers, picking up on the good fortune of their colleague, start agitating for access to his resources. They’re under-tasked, they argue. Of course, in the background, they’re thinking that they must be more effective than their own resources because that project manager is ahead of schedule.
Take this and other such incidents and you can see why managers learn to keep their good news to themselves. Taken to its logical conclusion and you find multiple isolated organizations trying to compete for the same resources within an organization. You can easily imagine them as silos on a plain, similar, closely located but completely isolated one from the other. These structures are not unique to the IT industry. I’ve had the misfortune to run across them within public, private and even non-profit organizations.
The irony is that within such organizations it is almost universal to find a desire to have multi-project analysis and management. Everyone would like to share information and it is clear to all that the sharing of such information would make the organization as a whole more effective. The issue becomes who will share first. What each manager really means is that they’d like everyone else to share, upon which they’ll decide what information, if any, will be shared of their own. It’s a tough scenario and all too common in organizations of all different sizes. What compounds the difficulty is the universal pledge of all concerned that they are truly committed to share information without reservation.
In the project management software business, we usually see this phenomena when an organization is attempting to implement multi-project functionality. Management has decided that if they only had advanced project management tools which more fully supported multi-project functionality, then everything would be fine. Of course, anyone who has tried to deliver on such promise has found it difficult.
The problem isn’t with the multi-project functionality available in most project management tools, it’s in the culture into which we try to implement it.
If you are faced with silo management, then implementing multi-project functionality becomes an impossible task. The basic premise in implementing such systems is that all data that can be implemented will be implemented. There are some categories of software which are more difficult than others to find in an organization. These include the total resources utilization for each project. Logic would tell us that not everyone on a project is overtasked beyond their availability but that is the most common response from project managers to a request for resource utilization. Inter-project dependencies is another obvious category. Everyone recognizes that there are some, but ask someone to put up their hand to identify them. One of the most obvious questions for which we often have difficulty getting a response are the lines of accountability within an organization. “Exactly to whom does this employee answer?” we ask. The answer is often surprisingly tough to come by.
Unfortunately, all of these data elements are critical to implementing multi-project management. This doesn’t even touch on tougher issues like who will have the authority to resolve resource conflicts or who will be responsible for project prioritization.
Is it hopeless? Far from it. The first step to implementing a true multi-project structure in a silo organization is to bring the silo issue out of the closet. Start with identifying the most critical elements of multi-project data that you’d like to have shared, then work on opening that one category up for scrutiny. Trying to open everything up on the first day is almost certain to seem like an impossible task.
One of the areas in which we’ve had surprising success is to start implementing a multi-project structure from the end of the process rather than the beginning. We’ve implemented multi-project reporting from an electronic timesheet system, which has been deployed across the entire organization. The data of what people are actually doing with their time turns out to deliver much of the end-result analysis of where we can make people more effective. The result has been reorganizing where people spend their time and how it is prioritized. Once the allocation of time as it is actually occurring has been revealed, we can move backwards towards the beginning of the project management process, the planning aspect.
If you’re suffering in a silo organization, it may be an aspect you can now get support for changing. In today’s competitive economy, anything that makes an organization less effective has a chance of being changed.
