One challenge in a franchise IT environment is “requirements bloat.” Similar to a bill traveling through Congress, to garner support from different functional areas and franchisees, IT project requirements keep piling up as more people weigh in.
The next phase of this process is typically a debate over which requirements should be included and which should be trimmed. The impact of which requirements are used is significant. I have seen a single requirement from a single franchisee raise the cost of a chain-wide IT project by more than 25 percent.
What often happens is a sort of gridlock, where a project stalls under its own weight. Typically, the debate divides over party lines. Conservatives (those who believe that IT is simply a cost-suck) and Progressives (those who believe that IT drives business value) generally are split over the “smallest/cheapest/simplest technology” and the “ring every possible ounce of value out of it” divide.
Nobody can agree on what is important, and there is very little movement toward compromise. Although the brand will—in most cases--ultimately decide the final direction, the hope is to do so with as much franchisee support as possible. Sometimes the greatest support for a given project design might be only 30 percent. How do you battle against this type of gridlock? Start saying “No” right up front.
When you are in a highly political role, such as that of a franchise CIO, one of the last things you want to do is start telling a lot of people “No,” right? It’s bad for business, because it upsets people. And if you upset the people you support, then you will be run out of town. It seems pretty straightforward: “Keep the people happy, and keep your approval rating high.”
If you believe this statement, you might as well start looking for a new job, because your current one isn’t going to work out. I personally believe the ability to look a franchisee straight in the eye and say “No” is the single biggest key to success in franchise IT.
I’m not saying that franchise CIOs should be very negative and turn down every new idea or new requirement request. What I am saying is that there are more CIOs ousted for failing to deliver results (because of stalled projects) then there are for taking a firm line on requirements. As Harvey Dent said in The Dark Night, “You either die a hero or you live long enough to see yourself become the villain.”
My suggestion is to work with the chain’s leadership to define a crystal-clear vision and highly specific goals for any IT project. Then you need to communicate, communicate, communicate with your franchisees about that vision and its goals. Make sure that as you build your requirements, each one supports the project vision and goals. If you cannot tie a requirement to a specific goal, or if a requirement goes against one of the stated goals, politely tell the person making the request that you are unable to meet that specific need.
It is much easier to write that directive than it is to actually follow it. As an example, let’s say that you have an IT project and that one of the goals is to provide the basic services as easily and inexpensively as possible. (This goal is not as specific as you would want in a real-life project, but it helps to illustrate the point).
So, after gathering requirements, you identify a few different vendors that will meet the need. Remember that the IT vendors you work with aren’t always aligned with supporting your goals. Suppose one of those vendors offers you an add-on component (one that many franchisees are excited about), which will increase your discount on the entire package. The initial thinking might be, “This is great! I can provide more functionality that franchisees want while reducing the costs of the rest of the technology. Score!”
But wait. If you decide to go down this path, you are headed toward failure. It goes directly against your goal: You would be purchasing more than the basic services. Plus, additional functionality often decreases ease-of-use and, while you have gotten a greater discount, you have also increased the overall costs. I have seen situations just like this derail more than a few IT projects, and I admit that I was a part of letting it happen. It was only learning through such experiences that I now understand what a slippery slope requirements can be.
One of the biggest things that you can do to protect against requirements bloat is to set a date when requirements gathering will close. Structure a formal requirements gathering process that calls out business, functional and technical requirements. Work hard to provide department heads and franchisees with the ability to ask questions and provide requirements during that time. Create a clear framework that communicates the requirements back to the stakeholders. Make sure that you provide ample opportunity for requirements to be provided. But when that date comes, STOP.
In my experience, most requirements bloat comes from later stages of a project, after you have already started to develop or configure the technology. People who weren’t involved in the initial requirements process get involved and want to offer input. New features or functionality will be discovered. New vendors with better/cheaper technologies will be found (after the vendor selection process is completed).
Obviously, not all of these issues can be avoided. But I strongly recommend that you resist these things and keep the project on its initial track. Explain to people that although such things might be considered in later phases of the project, you believe it is important to continue to deliver the currently agreed upon project in the timeframe and budget allocated. It’s best to create a separate and formal phase of the project called “Enhancements” to house new requests.
In the end, it is very important to be respectful of franchisees’ needs and wants. But it’s more important to be firm in your resolve to deliver a quality project on time.
What do you think? Love it or hate it, I’d love to gain some additional perspectives. Leave a comment or E-mail me at [email protected].