Even when an explicit IT governance model is not possible, some steps need to be taken to control what could quickly become chaos. Someone has to make decisions as to what can and can't be done and set a timeline. Benny Sisko provides an overview of his organization's efforts to maintain order while getting the important stuff done.
Let's do a quick poll. How many of you out there have staff people waiting next to their phones waiting for projects to come along? I'm willing to bet that no hands go up. More than likely, most of you probably have full project lists and people assigned for months out. Regardless of how much work is sitting before IT departments, there are constant streams of requests that need to be handled. Like most of you, my department and I face similar challenges.
- We continually get new requests that must be prioritized against existing ones.
- In an effort to jump start their own projects, individual business units sometimes attempt to budget for technology-related services on their own without involving the IT group.
- Equipment is sometimes purchased via grants that does not match up to organizational standards.
In my organization, we run an intentionally centralized IT organization for the purpose of coordinated strategy, prioritization and funding. Although I have attempted to impose a formal IT governance structure, those efforts were not supported by our CEO (he had good reasons that had nothing to do with my plans), so prioritization efforts fall to me to handle directly. Obviously, I work closely with others in the organization; I don't simply sit at my desk and make unilateral decisions. I also sit on the executive team, so I use that group to help as well. My staff and I also meet on a regular basis with other departments to help gauge priority.
Obviously, if we had unlimited resources in terms of both people and money, we'd simply commit to everything and do it all at once. However, the real world doesn't work like that, so we do have to pick and choose the projects we'll undertake and the equipment we'll support. Further, we've developed policies intended not to block other people's efforts, but to guide them in a sustainable, supportable direction.
- After consultation with the CFO, we've asked our purchasing office to send to us purchase requisitions that include technology equipment or services. As equipment is added to the organization, it needs to be supported and this policy lets us have some advance notice when things come along and gives us the opportunity to move non-standard purchases to things that we can support. No more surprises for IT and no more surprises for users when they find out that we're not able to support something weird.
- Working in concert with the rest of executive team, we've developed a draft policy that requires those seeking grant funds to purchase equipment typically supported by IT, when possible. Obviously, not all grants are the same and some will require different equipment. In these cases, the grant must take this into consideration. Again, the goal is not to block the grant. It's to make sure that the goal of the grant isn't stymied due to poor support.
- New projects are analyzed from beginning to end to make sure that they truly meet a business need and goal. Further, projects are analyzed against one another to determine "biggest bang for the buck" which is just another way to say that we work hard to prioritize. Although we rarely say "no" outright, we quite often push projects with lower priority out in favor of those with more immediate results.
- In rare cases where we do say no to a project or when we assign a completion date that isn't acceptable to the requesting department, we do sometimes get requests that we outsource the development or implementation. When considering new projects, we always do an insource vs. outsource analysis to begin with, so this becomes a moot point. Even outsourced projects require some kind of internal project management oversight, so IT staff time is still necessary and may not be available.
It might sound to some like we have strict controls in place. The steps that we have taken thus far are to help the organization as a whole and to prevent IT from being unwittingly over committed which would lead to us seriously under-delivering on our promises. By supporting specific equipment (our supported equipment list is pretty generous), we keep control over how many system images we need, which makes overall support much easier. In short, we make sure that the technology investments being made are appropriate.
Are our methods perfect? Nah. Loud, angry users are sometimes mollified just to get them off their soapbox and in cases where there might not be total communication between various parties, something might not get prioritized right. Fortunately, that's a pretty rare situation that is generally remedied quickly. In an ideal world, we'd have a formal IT governance structure but in the absence of that structure, we have what is generally a pretty good system.
But, sometimes it really does come down to just saying no. A project may not fit with anything the business really needs or a unit may want non-standard equipment for a reason that simply doesn't make sense. If I'm afraid to ever say no, all I have done is to create chaos.