Analysts, experts, and observers often encourage CIOs to be aligned with the business. I disagree. Alignment is just the first step to a partnership relationship that allows real change. Let's look at what it means to be aligned versus what a business partnership is to help clarify this.
Alignment means IS has a cordial relationship with each department, strives towards the same goals, and has an operating model to support day to day exceptions. Building a basic relationship with other department heads is critical but often overlooked and can serve as the foundation. Relationships can be fostered by travelling together, attending other departments'social events, and simply by going to that new sushi place together. Agreeing on the yearly priorities&ndash often by writing them together or jointly interpreting the CEO mandates,&ndash represents the second step. Unfortunately many IS organizations have not done this and this causes cross-functional prioritization, resource, and funding issues later in the year. The last major step in alignment is establishing an operating model to drive normal activities and address issues.
Creating a business partnership requires much more personal effort by the CIO. Providing the " art of the possible" , cancelling under-performing or shadow projects, and saying " yes, if" to push back and guide ideas are all part of being in a partnership. The " art of the possible" can be a set of sessions explaining or even demonstrating the latest in technology and tying it back to real business problems. This can serve to help guide the project portfolio as well as identify organizational deficiencies (such as knowledge or new roles) in time for the next budget cycle. Ultimately, both teams should start to look forward to the yearly sessions. A less popular, highly visible, and counter-intuitive method for building a partnership is cancelling or deferring a project.
An aligned CIO will often push out delivery dates or commit more resources to help the business look good but a partnered CIO could (and should) cancel the project entirely. Obviously this is heavily dependent on the reason for the original project delay: c ancelling a project due to a project manager issue is extreme whereas cancelling it for significant change management issues or business buy-in concerns is prudent. Shadow projects should generally be cancelled as they are the gift that keeps on giving, typically built on a non-standard platform or with an insecure architecture. Cancelling projects is often the cheapest financial approach but requires a different type of capital: political credit and the willpower to spend it. Finally, learning to say no in a different manner by saying " yes, if" is another great partnership tool. Often IS is viewed as the department of no&ndash no budget, no time, no way&ndash and using " yes, if" allows the department to consider a proposal if the business provides meets their end of the deal. For example, when the business wants to re-prioritize a backlogged project (Project B), the CIO could respond " yes we can do it&hellip if you help us complete Project A first and we jointly take the business case for Project B to the CFO this Friday during lunch." This draws the business in, makes them part of the solution, and engages them in quantifying the benefits while also ensuring it is a real priority.
During a recent dinner with about twenty other CIOs across multiple industries, the facilitator asked " How many projects that come across your desk have real business value?" The maximum number that anyone admitted to was 50 percent, whereas 30 percent seemed to be the average. Thus 50 percent of projects do not have real value and the aligned CIO proceeds while the partnered CIO works with the business to find other solutions