Documenting and Accounting for IT Priorities: The Action Planning Process

---

The information that comes out of the alignment and prioritization process is fodder for the creation of an enterprise IT planning document. Like many of the tools presented in this volume, the IT action plan serves any number of purposes. ^[10] First and foremost, through creating an IT action plan, the IT team can systematically survey, categorize, and reflect annually on all commitments in its portfolio of projects and services. As part of this effort, your IT team can adjust the scope of particular projects and service level delivery standards to ensure a proper balance between available IT resources and team commitments. Second, the IT action plan affords the formal, documented alignment of IT work with enterprise goals and objectives. Third, it serves as a vehicle for assigning responsibility within the team for specific IT deliverables, including scope definitions, specific delivery timeframes, and the metrics for customer satisfaction. Finally, it will most certainly assist the IT leadership and the team's customer relationship executives (if CREs are in place) in communicating across the IT organization and with customers concerning those projects and services of interest to them.

The underlying construct of the IT action plan is simple, albeit labor intensive. Its objective is to bring together information concerning long-term or strategic goals, near-term tactical objectives, and more immediate action items of the IT organization. Furthermore, this content must be structured and conveyed in a manner that makes clear the relationships between goals and objectives and between objectives and action items. Think of these elements relating to one another like the levels of a pyramid: the higher you go, the more generalized and abstract the plan's view of IT activities. Yet, all levels are connected: the more detailed (action item) layers align with and support the more general (strategic objective) top layers. See Exhibit 4.

Exhibit 4: The Planning Pyramid

As Exhibit 4 illustrates, the IT organization's mission statement rides over the entire portfolio of commitments and must embrace all IT goals and objectives. Conversely, each strategy must align in some way with the IT mission statement, and individual objectives and action items must line up under each goal. As a result, a good IT action plan will comprehend all that the IT organization delivers.

The process of creating an IT action plan should be highly participatory. This ensures broad support for the actual implementation of the plan. Also, given the complexities and interdependencies of IT service and project delivery, by involving a cross section of the team in formulating the plan, IT leadership will more likely avoid unfortunate omissions and false assumptions. The three sources of information that will help shape the formal planning discussion include the business-unit IT project prioritization process, the internal economy model and budget for IT, and your team's organization chart or some other source of clearly defined IT roles and responsibilities. All three of these documents will factor into the plan's ultimate formulation.

Depending on how your organization prefers to share responsibility, there are several approaches to creating the plan. Larger organizations may have a planning officer, such as the PMO director, whose responsibilities include collecting input and compiling a draft planning document. Alternatively, a small working group, facilitated by PMO personnel, might be assigned the task, or the CIO could take it on himself or herself. Once a plan is drafted, the preparers should walk through the draft with a representative cross section of IT team managers, subject matter experts, and the unit's CREs. Following this initial presentation and discussion, ask each reviewer to take a set period, say one week, to come back with questions, suggestions, and issues. Their input will help shape the document into its penultimate form, preparing it for a more formal review by IT management, including all the responsible parties whose names appear next to plan deliverables. Remember that the final product must align with the business, define deliverables and the parties responsible, and clarify how results will be measured. This is a lot for the team to digest and accept. Take the time to build a solid consensus around the plan, and involve your PMO in working with the various IT teams contributing to the planning document.

In practice, the author has used the IT action plan to document overall IT team commitments and to communicate these inside and outside of IT. In addition, I have used the plan to reinforce with my IT team our focus on delivering value to the customer and other operating principles. Last but not least, I have leveraged the process to draw out from staff a list of critical success factors and to build agreement around how to measure success in serving the customer. All of this rolls together in the author's IT action plan document, that includes the following sections: ^[11]

• IT organization vision statement

• IT unit mission statement

• List of goals and objectives, with language that links these to the enterprise's goals and objectives

• Operating unit guiding principles

• Competitive profiling information

• Guiding principles

• Critical success factors

• Observations concerning funding

• Observations concerning metrics and satisfaction measures

• Goal-by-goal breakdown of key initiatives defined in terms of:

  • Responsible parties

  • Timeframes and resources

  • Performance metrics

  • Self-review (a listing of major deliverables)

  • Manager's review (a listing of issues, barriers to success, and the realization of major milestones)

• Glossary of key terms

Of course, not all planning documents must include all of these items. Some corporate cultures will value detailed information sharing, while others will just want to-do lists organized by business unit customer. Find the right balance in crafting your presentation. It is better to say too much than to leave either your own team or your customers making their own assumptions about IT commitments. Be explicit up front to avoid disappointment later. Let us consider each of the plan template components in turn. The reader may then decide what works best for his or her own organization and business context.

Vision and mission statements serve both external and internal audiences. Externally, these declarations communicate IT's place and value proposition to the greater enterprise. Within the IT organization, they provide a sense of common identification and purpose. Of the two, vision speaks to and aligns with the enterprise's own mission statement. For example, if the corporate vision calls for world-class customer support, then the IT vision might say, "to assist the enterprise to achieve world-class customer support through the innovative use of information technologies." The IT unit's mission statement must be brief, while focusing more inwardly on what IT itself should be. Here is an example:

To enable learning, teaching, research, and administrative services for the extended XYZ University community through the effective and efficient deployment and support of proven information technologies and the best IT business practices commensurate with the highest levels of customer satisfaction. ^[12]

Like all good mission statements, the example addresses the following in general terms:

• Primary business focus of the enterprise

• IT's customers in that context

• What IT commits to deliver

• How the results are to be measured

As such, it is a powerful, galvanizing statement for staff and customers alike. Although the vision and mission statements are brief, they are not to be taken lightly. The IT organization will hang its collective hat on these statements. They should resonate within the team and with IT's customers and partner providers. Spend time developing these statements and ensure that your team is fully behind them before you take IT's vision and mission public.

By their nature, mission statements — no matter how exciting — are broad expressions of intent. To give these global declarations depth, create complementary IT unit goals. If properly structured, four to six goal statements ought to comprehend all IT deliverables. Obviously, the text will vary with the particulars of your business. Here are a few general rules:

• Construct no more than one goal per line of business served; if you do the same things for several lines of business, consolidate them under one goal.

• Employ a single goal for all infrastructure-related projects, i.e., initiatives sponsored by IT itself that provide and maintain the enabling technologies for more customer-centric IT products and services.

• Devote a goal to IT organization process improvement and the pursuit of best practices, i.e., the running of IT as a business, including such activities as resource planning and budgeting, asset management, information security, customer relationship management, and the like.

• Create a goal that addresses the needs of the culture and people within the IT organization itself, e.g., staff recruitment and retention, staff training and development, performance management, team building, and so forth.

Each goal should identify in general language what is to be done, who is to be served, and how results are to be measured. Make a point of aligning each of your team's goals with the mission and goals of the enterprise. Simple but comprehensive goals are best. Again, try to keep the total number of goals within reason; employing too many goals will fragment and defuse the IT team's focus on deliverables. At the same time, ensure that your plan's goals, in total, encompass the sum of your team's commitments.

Drawing on these principles, a sample set of IT unit goals might include the following: ^[13]

• Goal 1 — to enable and support the University's learning, teaching, service, and research objectives, through the delivery of information technology products and services in keeping with available University resources. (This aligns with enterprise strategic goal x.)

• Goal 2 — to enable the administrative needs of XYZ students, faculty, and staff in an effective and efficient manner, through the delivery of information technology products and services, reflecting best higher education business practices. (This aligns with enterprise strategic goal y.)

• Goal 3 — to establish and maintain a robust, scalable, flexible, reliable, and cost effective information technology infrastructure that supports the current needs and that anticipates the future needs of the XYZ University community. (This aligns with enterprise strategic goals z and y.)

• Goal 4 — to establish and maintain IT division policies and practices that protect the University's investments in information technology, business systems, and enterprise data and that respect the rights and privileges of all community members. (This aligns with enterprise strategic goals a and y.)

• Goal 5 — to strengthen the performance of the IT division through the recruitment, retention, ongoing development, and tools enablement of the very best information technology professionals. (This aligns with enterprise strategic goal b.)

In this example drawn from higher education, the lines of business served are collapsed into two goals: one in support of academic delivery and one in support of administrative operations. Goal three encompasses all infrastructure work; goal four includes all process improvement activities, and the final goal speaks to IT staff issues and needs.

The next series of action plan elements is optional and may or may not fit into the culture of your organization. Although the author strongly recommends inclusion of these elements in your plan, you may need to adapt them for your use. The first of these is competitive benchmarking data. Often, IT management is asked to defend its choices and expenditures in light of what other IT organizations offer or spend. This is not an unreasonable request on the part of your business colleagues. No doubt they are being asked to benchmark their performance, as well. What matters here is the selection of appropriate comparisons. Industry analysis firms, like Gartner and META Group, regularly offer IT spending survey data. Your organization may or may not fit within one of their survey categories. Study the survey criteria with care before offering a comparative study to business management as an approach to benchmarking your operation.

Although they may be hard to come by, appropriate company-to-company comparisons will also prove useful. Just make sure that the same metrics are used by your team and those with which you compare. Typically, one finds such data offered through professional associations, trade consortia, and the like. If you do pursue benchmarking as part of your planning and management processes, be sure to vet this list with your business colleagues and get their approval up front. Set expectations about what you and they can reasonably derive from these data sets, and then maintain the agreed-on process for data collection, comparison, and analysis.

Next, consider the inclusion of IT team operating principles. These are behavior norms governing the ways you and your team interact with each other and with customers. Team operating principles may prove to be a critical element in building a high-performance, service-oriented IT organization, but only if they permeate your internal culture and your dealings with customers and partner providers. If you fail to acknowledge and reward those who exemplify adherence to these principles — and if you neglect to practice them yourself — they will fade into obscurity. On the other hand, if you continually reinforce their relevance to the success of the team and the health of the overall work environment, they will serve as a potent management tool. Here is sample list of IT operating principles:

• Prioritize for customer value

• Manage through consensus and deliver as a team

• Make and honor commitments, but make no commitments for others

• Go directly to the person or the problem to seek out the root cause(s) of problems and disputes

• Value collaboration and information sharing

• Respect each other and value difference

• Manage by fact, not by assumption, rumor, or personal agenda

• Take responsibility for the team's success

• Celebrate the journey and learn from the experience

Complement the use of IT operating principles, which are inwardly focused, with use of customer-oriented critical success factors (CSFs). CSFs focus on those business practices that ensure positive outcomes in interactions with customers and improve project and service delivery more generally. Like operating principles, CSFs address the soft, interpersonal side of transacting with your line-of-business colleagues. They also afford a framework for the operational maturation of the IT organization. CSFs should be concrete, focused on customer delivery, and leading to action, as these examples show:

• Communication

  • Clear, continuous communication, throughout the IT unit and with customers and external partners, that focuses on the clarification of roles, responsibilities, and deliverables

• Delivery management

  • Predictable delivery of products and services

  • Project and subcontractor requirements and IT architecture management that lead to timely and cost-efficient implementation and operation of the IT products and services

• Resource management

  • Resource flexibility, deployed and allocated to highest-value business requirements

  • Attraction and retention of top-performing staff who are aligned with business priorities

• Architected and managed solutions

  • Products and services, whether developed in-house or provided from external sources, that are well integrated with customer needs and XYZ's existing base of information technologies

  • Adherence to XYZ's IT architecture and engineering standards and the consistent use of quality assurance (QA) processes

  • Baselining and ongoing measurement of performance and regular reporting to the appropriate stakeholders

In employing CSFs, you are also reminding your IT colleagues that your business must remain focused on the needs of the customer and hence on service and project delivery.

If there are special financial considerations relevant to the IT Action Plan, you might include these as part of your planning document. For example, if your plan makes certain assumptions about capital funding, asset depreciation, or ongoing maintenance and support, clarify these in the document. Similarly, you might consider a brief explanation of the role that metrics will play in the management of the IT plan's implementation.

As the sample IT Action Plan shows, all of these plan components are covered in two pages. These pages provide a framework for performance. The remainder of the plan devotes itself to actual IT commitments. Here, the template is straightforward:

• IT initiatives are organized under the appropriate goal statements reproduced from page 1 of the template.

• Each initiative is an umbrella statement under which the team might position any number of more discrete IT activities.

• In total, the initiative statements should capture all IT team activity — service and project delivery.

• To the right of each initiative, indicate the primary and secondary parties responsible for actual delivery, mostly team leaders and subject matter experts, but also support personnel from the PMO.

• Next, identify key milestones and dates.

• Provide performance metrics for each deliverable. Note that these are results and not activity measures. You need to ask yourself, from the customer's point of view, what reflects satisfaction with the IT deliverable in question, measuring and reporting plan results based on these metrics.

• The remaining two columns are completed each time the plan is updated:

  • The self-review column affords a place for the capturing of specific accomplishments over the last quarter or year.

  • The manager's review column allows for executive-level comments concerning the nature of the accomplishment, barriers confronted and overcome, and next steps or changes in plan.

Taken together, this information provides a comprehensive yet concentrated view of IT commitments and accomplishments over a given period. The document clearly identifies who is responsible for each IT deliverable and how performance will be measured. Overall, it sends a powerful message to the team about customer-focused work priorities.

IT management will want to share this document widely within the organization and most probably with corporate sponsors (i.e., funding sources). Because some of the language employed in the plan may be obscure to those not involved in its creation, add a brief glossary of key terms at the end of the plan. Also, consider customized views of the plan for targeted enterprise audiences. Remember that through this document, IT strives to communicate more effectively the nature and extent of its commitments to the constituencies served, and to ensure the understanding of and agreement to these commitments among IT operating units and personnel. Typically, a plan will be reviewed and updated quarterly to capture service delivery and project accomplishments, as well as issues impacting future deliverables. Adjustments to the IT action plan may occur throughout the year. These changes may be driven by the dynamics of the marketplace, evolving business requirements, or emerging IT opportunities. ^[14]

The final section of this chapter focuses on the overall annual process for plan creation, leaving the consideration of off-cycle plan adjustments for Chapter 4 and Chapter 5. Your own organization's annual planning and budgeting processes may be rather complex, with numerous cycle events. For example, the business side of the house may have established procedures for strategic planning, capital allocation, staffing, project approval, and so forth. To achieve properly balanced decisions between project and service priorities with funding allocations, the IT planning process must integrate with these established activities.

To illustrate the dynamics of the situation, I have provided two process views. The first of these is a planning timetable spreadsheet, ^[15] which illustrates the timing and interrelationships between business and fiscal year cycles, strategic planning, performance management, ^[16] budgeting planning, capital planning, and so on. One cannot hope to manage what one does not comprehend. By mapping all of your organization's planning activities next to each other, you can identify more readily those that require input from the IT management team. Where there are gaps in the process, you can introduce changes, and where timing is critical, you can focus staff resources to deliver what is needed when it is needed. The planning timetable template also may serve as a useful educational tool to prepare your IT colleagues for the coordinated effort of developing plans, schedules, budgets, and investment estimates in line with the requirements of your line-of-business partners. This timetable would serve as a to-do list for those PMO personnel supporting the IT organization planning and alignment processes.

It is also helpful to create a flow chart of the internal IT process, with its iterative steps and key delivery dates. As modeled in Exhibit 5, a representative process is fed by many sources of information beyond those of the lines of business, including needs and opportunities identified by the IT staff and forces active in the external marketplace. All of this data is then filtered by IT management to terms of its impact on the following:

• Existing service level agreements (SLAs)

• Established and ongoing IT projects

• Embedded IT infrastructure of the enterprise

• Quality and size of the organization's IT work force

• Established IT funding levels

Exhibit 5: The Action Planning Process Workflow — Part 1

My model is iterative at this point because analysis may call for additional information gathering. PMO personnel will then bring together its documentation for reviews within the IT management team. Eventually, the content will be ready to share with appropriate members of enterprise management. See Exhibit 5.

As the larger organizational processes grind on, IT must prepare for action. Here, the workflow suggests two separate but interrelated streams of activity. On the one hand, IT management will continue to interact with business colleagues on plan refinement. On the other hand, the IT organization, through its PMO, must initiate SLA reviews and project plan development in anticipation of the initiatives scoped in the documents under review. Any changes to what was originally proposed must be sized and assessed against resource allocations. In a well coordinated process, the IT organization will be poised for action when the plans for the coming fiscal year are finalized. See Exhibit 6.

Exhibit 6: The Action Planning Process Workflow — Part 2

Although this sounds plausible, the author's model is somewhat optimistic. Even the best corporate planning processes do not always produce clear direction. For that matter, some fail to follow their own timetables, leaving the resolution among choices for some time in the new year. When this occurs, IT is left in a holding pattern, only to find itself with squeezed delivery dates or project log jams. Still other organizations make their IT investment decisions on a revolving calendar basis, releasing resources along with assignments. The reader should adapt his or her sense of the process and the tools provided here to accommodate the realities of his or her workplace.

In the end, the success of any IT alignment and planning effort has less to do with the rigor of the process and more to do with the quality of communication among participants. In these discussions, the contributions of the IT leadership involve the timely delivery of relevant information and the realistic shaping of business leaders' expectations. Reason may prevail, but fantasy may pervade the alignment and planning efforts. Stick to the facts. Do not promise too much, leaving your team in an untenable situation when it comes time to deliver. Rely, if you can, on the services of your PMO to coordinate process documentation, working session scheduling, and intra- and interunit communications. Include review sessions to ensure that the message reaching your customers is in line with your own thinking and that of your management team.

To ensure further the ongoing quality of these communications and to help your leadership team succeed more generally, I recommend the establishment of at least one IT advisory board made up of representative line-of-business partners from across the enterprise. For that matter, in a not-for-profit setting, I have employed two boards: one comprising key internal customers and the other drawn from the external community of institutional allies (e.g., alumni, retirees, former board members and officers), IT experts, and business partners (e.g., product and service providers). If well managed, these boards will provide honest feedback on your IT organization's plans and performance. They will also offer practical advice, fresh ideas and perspectives, and at times, even added resources to assist IT in better delivery and performance. ^[17] Furthermore, by actively employing an advisory group, the IT leadership team will have another way to communicate with those they serve. This investment of time and effort will pay off in many ways, including improved relations and understanding between IT and the rest of the enterprise, clearer alignment between corporate priorities and IT activities, and a focused sounding board for the launch of new initiatives.

Assuming a positive outcome from the planning process activities cited above, the IT organization must now bring to fruition those service and project commitments articulated or assumed in enterprise plans. But even the best-laid plans, especially when it comes to IT applications, can take unexpected turns. Although the aforementioned process prioritizes work and allocates resources over a timeframe of 12 months or even longer, it cannot anticipate changes in the business or in IT that might create more pressing needs or more promising opportunities. These so-called off-cycle events merit a management process of their own. This workflow may be illustrated as shown in Exhibit 7.

Exhibit 7: Off-Cycle IT Project Intake — Part 1

As in the annual planning process, each change to the plan must be thoroughly scrutinized. Does it have a sponsor and working clients? Is it funded? What are its TCO implications? What is the value of this proposal to the enterprise versus the values of those already approved and in the queue? If it does have a greater value to the enterprise, and assuming no additional resources or capacity exists within IT to get this additional work in the pipeline, what project(s) will be dropped from the original list, and is there consensus around that choice? ^[18] If a proposed addition to the annual plan passes these reviews within the IT organization itself, it may then proceed to the next level of the intake process, where it is vetted by the PMO through a more detailed commitment process and project plan. See Exhibit 8.

Exhibit 8: Off-Cycle IT Project Intake — Part 2

During this phase of the process, the PMO will assign a project manager, and perhaps a business analyst, to create the necessary scoping documents. Once these are ready, the package must go before stake-holders for final approval before it enters the IT organization pipeline. If the tradeoffs involve two projects owned by the same sponsor, this could be a fairly easy conversation. But if, as is often the case, one sponsor must forgo a project so that another business unit may pursue one of its own, the conversation could be heated. Be sure to present IT's position in a neutral manner. Stick to the facts and rely on the process' value measurement tool to identify the superior opportunity. Let business management make the final decision. When you are faced with a pure add (i.e., no tradeoffs, just added work), you may need to revisit the scope of other approved projects to accommodate the demands of the new project. Here again, use the established rules of the process and its tools to present your case, and allow rational discourse and sound business thinking to prevail.

In today's rapidly changing world, the adaptability of IT's management processes is paramount. Do not assume that the plan with which you conclude the formal planning cycle is cast in stone. Flexibility and responsiveness to evolving business needs are the hallmark of a winning IT organization. The remaining chapters of The Hands-On Project Office explore in more detail the organizing principles, work processes, and best practices that can help the reader's IT team achieve these positive results. Chapter 4 discusses the particular approaches and tools for service delivery management. Chapter 5 does the same for project management. These two chapters speak to the proper conduct of work stemming from and driven by the IT action plan.

^[10]For an example of an IT action plan in use, see The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt3~5~Action Plan~example. For the actual planning template, see chpt3~6~Action Plan~template. For a hardcopy version of this tool see Appendix B.

^[11]See The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt3~6~Action Plan~template.

^[12]This example is drawn from the sample action plan, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt3~5~Action Plan~example.

^[13]This example is drawn from the sample action plan, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt3~5~Action Plan~example.

^[14]If a proposed change to the plan will require a significant change in service delivery levels, impact multiple IT operating units, or involve additional IT resources above a certain threshold amount (say, $25,000), the process should accommodate such adjustments. Chapter 5 considers these issues in more detail.

^[15]See The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt3~7~planning~timetable~example and chpt3~8~planning~timetable~template. For a time line format and work flow for your planning process see chpt3~9~annual planning process~work flow.

^[16]Although performance management is not a particular focus of this book, incorporating the values and metrics of the IT action plan into IT performance management is essential to the health of both processes. The IT team will adhere more strongly to the operating principles and delivery commitments if team members understand that continued employment and pay increases are tied directly to the modes of behavior and deliverables represented in the IT plan. For a performance review template that does just that, see The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt3~10~performance review~template. This and similar tools should be maintained by the PMO for IT organization management.

^[17]For a sample IT advisory board charter, see The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt3~11~IT Board charter~example.

^[18]For an electronic version of this workflow, see The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt3~12~Off-Cycle Approval Process~workflow.

---