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.
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.
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
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.
[...] [...]