Skip to content Skip to navigation

Plan the Work, then Work the Process

August 19, 2014
by Fran Turisco, Director, Aspen Advisors
| Reprints
‘Operationalizing processes’ are an essential part of an IT strategic planning project
Fran Turisco

Today, an IT plan without the rigor of the associated processes to implement the recommendations leaves organizations holding the thick book of projects and a high-level roadmap, asking, “Now what do we do?”

While an approach without established processes worked fine years ago when we were eagerly moving from paper to electronic transactions, the approval of the IT plan is no longer the endpoint for the planning effort, due to the complexities of technologies, dependencies and external data sharing and communications.

There has never been a more pressing time when an organization needs to have clear, consistently followed processes, effective checkpoints, and leadership support to manage the IT plan and monitor its progress and value. The volume of IT requests has skyrocketed in recent years, yet resources are scarce and options and dependencies are many, which requires numerous shifts and project trade-offs.  New requests come into Information Services (IS) almost instantaneously with the approval of the IT plan. Without clearly defined processes and standards for requests and changes, it is natural to fall back on a “business as usual” mindset which in many cases means a LIFO (Last In First Out) method for new requests. 

The processes can no longer be conveyed in PowerPoint diagrams. Rather, workflows, procedures, new tools, and education are requirements to make sure the most critical, highest priority needs are addressed first, and approved projects are continually tracked and successfully implemented.  The following are some of the exemplary practices that innovative organizations have used to manage the transition from planning to doing while keeping the momentum going.

1. Involve the PMO Early in the Planning Process 

The Project Management Office (PMO) is an integral part of executing the IT plan, so get them involved early on to make sure the tools, data, and processes are in place once the plan is approved.  Some important work done by the PMO during the planning engagement includes:

  • Building/refining the IT request form, standard status report format, issue log, and project monitoring dashboards;
  • Building workflows and associated procedures from the high-level IT request process diagram in the plan; and
  • Setting standards for what defines a project, the level of detail for costs, and value realization analysis for an IT request.

2. Marry the IT Request Process with the Capital Budgeting Process

While not part of the IT planning initiative, processing new requests is an important aspect of managing and adjusting the plan to fit the needs of the organization. When the planning project is underway, it is also the time to build the process for streamlining the IT and capital budgeting process, and here is why. It is not uncommon for organizations to have the capital request process separate from the IT request process. In this instance, the requestor needs to enter much of the same information, such as scope, benefits, costs, resources, and total cost of ownership (TCO) into two different systems. This approach is very confusing to the requestor if, for example, the capital budget request is approved, but the IT request is denied.

Organizations need to combine the two processes with the understanding that any capital request that uses technology and needs IS resources must go through the IT request process first. Once approved, then it should be sent onto the capital budgeting committee. Luckily, the IT request approval committee and the finance committee have many of the same members, so if a project gets through the IT process, the capital will most likely be made available.

Marrying the two also improves the adoption to the new IT request and process as users are familiar with capital budgeting process and won’t need to do double duty for requesting the technology too.

3. Make Business Sponsors Accountable

IT projects identify a business or executive sponsor to show approval for the project and its value to the organization. However, beyond the signature, the business sponsor is often not held responsible for the outcome or involved in the project to address issues and barriers.  Important characteristics for a sponsor include: