Cementing a formal work initiation process for IT projects

I’ve written before on how the most important thing that a CTO/CIO deals with is the proper allocation of resources. I’ve discussed how doing proper resource allocation isn’t just a matter of deciding exactly what Sam or Mary will work on this week, but actually figuring out the whole project portfolio, including sustainment activity, and determining the general picture of what portion of resources will be dedicated to each chunk. That project portfolio management concept is a meta-level above, and arguably more important to focus on than, the nuts-and-bolts action of allocating the time and tasks for individuals.

Here’s another critical meta-layer to the overall issue of how to properly allocate resources: how is work spawned, initiated, defined, before it goes through the various approval steps involved in portfolio management? Where does the work stem from, and how does it enter the stream? Who decides that the suggested project is worth pursuing at all? Does simply anyone’s suggestion count as a way to spawn work? Lots of organizations don’t have a very clear path for this. The result is that lots of stuff ends up getting worked on informally, and resources get overcommitted and stretched, and both quality and timely delivery suffer greatly.

I’ve found over the years that it’s best to have a single, formalized conduit: yes, a dreaded form, collecting basic initial information about the intended project or need, and capturing important facts and assumptions about the approach, cost, sponsorship, and likely return on investment.

Otherwise, what you get is informal, chaotic, hydra-headed: various meetings happen, discussion ensues about a perceived need, people call up or email their closest contact in IT, and the work either starts just happening on its own, or it gets added, quasi-anonymously, to a list of “things to do.” That’s no way to run an IT organization, where the foremost challenge is always grappling with the beast of infinite demand and very finite resources. Rationalizing how work flows in is a necessary first step to taming that beast.

In short, define and mandate a formal work initiation process that must be followed in order for development to accept new tasks and projects.

• This process needs to become one of IT’s fundamental operating principles, and be viewed, internally and externally, as critical to its success.

• IT needs to spend its limited time on prioritized, approved projects. Otherwise, the risk is great that projects will launch with poor quality because of resources being stretched too thin, or because requirements were never clearly agreed to, or because resources needed to work chronically long hours to meet unrealistic expectations.

• In other words, the only new (non-sustainment) projects that IT should be working on are things that have been formally entered via the work initiation process, been prioritized by the project portfolio management process, have documented requirements, and have had resources reviewed and assigned by the project managers.

Nearly everyone in IT tends to get approached, and often, by internal customers, to discuss ways to meet important business needs. We tend to come up with plenty of such ideas all on our own, in fact. Here are the things to communicate both to internal staff and elsewhere throughout the company:

• IT should not (ever) stop talking to IT’s internal customers. It is incredibly important for IT to have a close relationship with its customers, in order to learn the business and be able to understand and anticipate business needs.

• Each IT member, and every executive and mid-manager across the company, needs to be aware of, and commit to supporting, the work initiation process as a way to get (ultimately) not only more done, but the right things done for the business.

• Every executive and mid-manager needs to know that there is a finite set (one that is published and widely available) of approved current projects that are getting actual resources allocated to them. Anything that is not on that list is (at best) in the preliminary investigation stage.

• No one should discuss design and implementation, start building, or ever commit to any dates, for anything that has not come through the work initiation process. Everyone should be aware of the very real danger of inadvertently setting expectations simply by participating in discussions.

• Every IT member needs to understand that when they find themselves in solution discussions, they need to let the internal customer know that IT cannot and does not begin work, or commit to deliverables or dates, until the request is put through the work initiation process. IT should of course be prepared to guide internal customers through that work initiation process.

IT will probably always be challenged with convincing its internal customers of the importance and value of the work initiation process. In the end, results (i.e., successful, launched projects) will be what matter most to the organization. But I’ve seen it many times before: IT departments that try to do everything, with no formal work initiation process, end up with delayed launches, disgruntled customers, and worn-out employees. Turn that around. And be prepared for needing to do a lot of ongoing evangelism about why.