Smart people can make stupid decisions. Case in point: business executives who decide they can address their technology needs without involving IT, responding to the IT supply-and-demand crunch that afflicts so many enterprises today.

In my experience, nobody wins in these do-it-yourself projects. The executive who sponsors the project puts his or her reputation on the line by promising outcomes dependent on technologies that he or she is ill-equipped to develop, implement, or manage. The IT executive finds him- or herself powerless, relegated to integration and support tasks without having had adequate resources and time allocated for the project. Meanwhile, the CFO watches dollars flying out the window as the budget for ill-conceived and poorly executed initiatives becomes a moving target.

But although it’s tempting to try to redirect a DIY technology initiative and send it back into the arms of IT, that’s usually the wrong thing to do. Invariably, the IT executive will try, but fail, to address the technology needs of the now very grumpy executive. The very grumpy executive will blame his or her function’s performance issues on the lack of the necessary technology to support the unit’s plans. And the CFO will discover that it costs more to stop a DIY project (while trying to satisfy the requirements of the ever-grumpier executive) than it does to let it go forward subject to agreements with the executive to operate within newly defined guardrails regarding costs, benefits, and timing.

Once begun, DIY projects take on a life of their own and it’s in the best interests of all involved to make the best of a bad situation. IT should heed the advice of one wise CIO and treat the projects as a “great opportunity to partner, change their organization and save everyone’s job” by supporting the initiative and improving the way future project priorities are defined and the speed at which technology is delivered. And CFOs should snatch (at least a little) victory from the jaws of defeat by holding the business executive accountable for delivering performance improvements enabled by the new technology.

The only way to prevent DIY projects from emerging in the first place is to set up a situation in which business leaders would never consider going rogue — by pursuing low-priority initiatives and/or contracting directly with an external IT provider. As CFO, you should partner with your CIO to:

1) Sponsor an IT prioritization process in which business leaders can get to weigh in and have their voices heard. Once decisions are made, however, everyone is expected to buy in.

2) Ensure that IT operates as a “one-stop shop” (by brokering internal as well as external technology solutions and delivery approaches), and stipulate that IT-related procurement decisions require IT approval.

While it’s a given that smart people at times make stupid decisions, they rarely embark on courses of action that run counter to their best interests. DIY projects are a symptom of enterprise incentives and capabilities gone awry. Help your smart people make smarter IT decisions by learning from — not stopping — DIY projects.

Orginally published at CFO.com

A productive CIO-CFO relationship is critical to the successful exploitation of technology. And, in general, CIOs find the relationship difficult and frustrating to navigate.

One of the root causes of the frustration stems from the fact that when it comes to IT, CFOs serve multiple and often conflicting roles: CFO's are IT's business partner, banker, and in some cases, boss. This means that in a given work week, it's not unusual for CFOs to request additional IT support, cut the IT budget, and criticize the CIO's progress in strengthening the company's competitive position.  

As a business partner, CFOs are not - and should not be - the CIO's top priority. And, for the most part, CFOs agree. They understand that front office investments should trump the back office. But CFOs are human. They hear about the promise of real time analytics at conferences and complaints about manual workarounds and multiple versions of the truth in staff meetings, and feel compelled to throw their requests in the demand queue.

In their role as the enterprise's banker, many CFOs are viewed by CIOs as adversaries, not allies. The two parties play an ongoing game of chicken with CIOs asking for more money and CFOs asking for more justification. This leads CIOs to offer up impressive ROIs and CFOs to dismiss the ever-elusive "R" and drill down into the ever-present "I".

As a boss, CFOs are often believed by CIOs to be more a hindrance than a help. Often, CFOs don't have the IT knowledge to serve as a sounding board and don't spend their precious leadership capital to open doors, twist arms, and forge cross-functional alliances to advance the CIO's agenda. This leaves CIOs on their own to exert influence with superiors who expect to be served rather than governed.

CFOs can help improve the CFO-CIO relationship by adopting an enterprise perspective, leveraging their authority, and getting smarter about IT:

• Adopt an enterprise perspective. As a business partner, challenge your people to identify IT-enabled opportunities that deliver benefit beyond the four walls of the finance organization or the company. For example, improving the efficiency of credit processing is good, but doing so while reducing the timeframe to approve and extend credit is even better. There are many good ideas on how to leverage IT, but the truly great ones change the company's products and how the company interacts with and services its customers.

• Leverage your financial authority on behalf of IT. As a banker, help your CIO strengthen the relationship between IT investments and IT returns by holding business sponsors accountable for realizing the benefits outlined in their business cases. To do so, ensure that project justifications outline the operational metrics that serve as leading indicators to projected financial benefits (e.g., improvements in cycle time, quality, accuracy, customer service, etc.) and that project plans incorporate baseline measurement and post-implementation monitoring.

• Increase your IT-smarts. As a boss, you need to lead, follow or get out of the way. If you choose to lead, increase your IT-smarts by reading, studying, attending conferences, participating in research consortiums, and getting hands-on exposure to the technology used in your company and others. If you choose not to get immersed in the IT world, then relinquish your supervisory role and arrange for the CIO to report to the CEO or, at minimum, have the freedom to act as if they do.

Of course, merging your multiple IT personalities won't miraculously heal the relationship if your CIO is in over his head.  But, regardless of the case, doing so will help ensure that you are setting your CIO up for success rather than dragging him down.

Originally published at cfo.com.

Cloud computing is inevitable.  

The end state promises computing resources that deliver against the New Normal's need for speed, collaboration, productivity, and scale.

The transition state, however, delivers nothing but challenges for all involved.

On the vendor side, big names don't necessarily equate to big capabilities.  Every "world class" cloud vendor consists of mere mortal employees who are struggling (given organizational silos, fragmented technology, and dramatic growth) to deliver on their company's service level commitments .  Buyers beware.  Take your reference checks to a new level - and focus not only on vendor capabilities but also the internal capabilities necessary to make sure the whole is greater than the sum of the parts.

On the company side, technology and process changes are pretty well understood, security implications less so, but the organizational impacts are the most profound and sure to confound.  

As we transition from managing assets to services, what is the role for our MVP technologists?  With the transition to cloud, they are being asked to transfer their knowledge and manage service levels without direct access to the tools that allow them to do so.  As an technical IT leader said to me recently, "We are now managing relationships and tickets - not technology."

Don't write off these employees as "unnecessary" in the end state and replaceable in the transition.  Companies need to "lift and shift" their MVP technologists from the micro to the macro:  architecting, integrating, innovating, directing, monitoring, resolving, negotiating.

As you move to cloud computing, how are you making sure that your people are moving with you?    

The article does a wonderful job illustrating that no one owns innovation - it's a horizontal, not a vertical process. One where innovations must travel across organizational boundaries to find purpose and become reality.

There are three major players in the innovation process:  those involved in an open-ended search for knowledge (e.g., found in universities and some great R&D labs), those facing needs and serious constraints (e.g., start ups, front line knowledge workers), and those with the discipline and resources to define and scale products that have broad-based appeal (e.g., vendors and IT organizations.)

Innovation is a messy little soup where the magic happens as the different players interact.  There is no simple recipe, but key ingredients include employees who understand the needs of marketplace, are exposed to the outside world, and work within a culture that nurtures creativity within a disciplined process of iteration, prototyping, and pruning.

The fact that no one owns innovation means that everyone should. This presents an enormous challenge for companies with bloated project agendas, over-burdened employees, and overzealous bosses.  Google's "20% time" is a boundary rule targeted at keeping these toxic ingredients at bay.

What is your company doing to foster innovation?

Answer:  When the employees are leveraging IT without involving IT.

A well-known technology company has become the poster child for locking down IT to capture efficiencies gained through consolidation and standardization.  Now, all IT decisions must be funneled through IT.  It's a good idea that has gone bad.  It's not unusual for engineers to wait a year for technology decisions.  Going it alone risks termination.  Courageous business leaders mask IT spending in their project budgets by calling it "equipment."

IT is at a crossroads - it needs to either figure out how to bring shadow IT out of the dark - and into the light - or risk being marginalized as increasingly tech-friendly business leaders take innovation into their own hands.

It's time for IT to control what matters. Imagine if IT defined investment policies rather than stewarding all business cases through approval?  Imagine if IT certified project managers rather than managing all IT-enabled projects?  Imagine if IT approved vendors rather than getting involved with all IT vendor provisioning?  Imagine if IT controlled access to applications and data rather than the access devices?

Shadow IT reflects a need.  Rather than shutting it down, IT should be building it up - while ensuring that it meets the needs of the enterprise as well as the individuals within.

How is your company bringing shadow IT into the light?

Here's a simple piece of advice for companies looking to become more innovative: Get IT out of the IT department.

I know it sounds counterintuitive and goes against the drive for centralization that has been in effect at most companies for the past 10 years. But for both competitive and technological reasons, funneling everything through the IT department no longer makes sense. Instead, business-unit leaders need to start assuming more control over the IT assets that fuel their individual businesses. To read the full Wall Street Journal article, click here.  To learn more, listen to a recent NPR interview with Susan.

This week I met with some senior IT leaders to discuss my new book and the future of IT. At the end of the discussion, one of the participants expressed concern about the ability to develop future IT leaders in light of the fact that the company is outsourcing and "we aren't hiring junior IT people anymore." As I looked around the table, I realized that this organization is running on the leaders they developed five, 10, even 15 years ago, in their pre-outsourcing days. These people are getting older and looking tired. Outsourcers, not employees, are performing many of the jobs that helped build their leadership skills.

Where will this organization, and others, find their future IT leaders if not from the junior ranks?

The most obvious answer is to go where the jobs have gone and recruit from IT outsourcers and vendors. But these candidates are a mixed bag. Using Gartner's IT leadership competencies as context, it's likely that the potential candidates will have strong technical skills but equally likely that they will lack the necessary insider understanding of the business and how to exert influence and lead change. As a CIO, I admire the work ethic, drive and process discipline of consultants and I have tried on many occasions to bring them into the organization, usually with little success. Unfortunately, most lacked the ability and patience to sell-in strategies and foster motivation for change (from the inside vs. the outside), lead and grow diverse teams, and deal with the sometimes mind-numbing routine responsibilities inherent in management roles.

Even if the external hires are perfectly qualified, hiring senior level leaders from the outside has a spotty track record. Overall, leaders are built, not bought. And building leaders requires a pipeline and a process. The pipeline is fed by junior and mid-level positions and the process is one of developing leaders by positioning them in a sequence of powerful on-the-job experience. One of the most powerful ways to develop leaders is through cross boundary moves, from line to staff, from region to corporate, from Asia to the United States to South America, from manufacturing to IT to marketing. As a practical matter, cross boundary moves should start relatively early in an employee's career. Doing so not only lowers the risk (to the organization and the individual) but also opens to the doors to further cross boundary moves as the leader progresses in their career.

Outsourcing reduces the pipeline and impacts the process since it reduces the number of junior and mid-level roles and the number of positions available for on-the-job training.

Developing leaders has always been difficult. Broad based outsourcing exacerbates this difficult challenge by removing the number of rungs on the IT leadership development ladder.

There has to be a path out of this conundrum. How is your organization developing its future IT leaders?

Andy Grove penned a fascinating commentary about the impact of outsourcing on American job creation, and the subsequent ability to innovate in the sectors that have been outsourced. He challenges the belief that as long as knowledge work stays in the United States, it doesn't matter what happens to factory jobs. Grove believes that, "not only did we lose an untold number of jobs, we broke the chain of experience that is important for technological evolution." Grove makes a good argument that, over time, companies lose the ability to innovate in the sectors they outsource.

Does this argument apply at a lower level to IT outsourcing? Consider whether or not this statement has merit: With extensive outsourcing, over time, companies lose the ability to innovate IT.

Successful outsourcing requires strong internal leadership. Question is, how can an organization attract, develop and retain IT-smart leaders in an environment where many of the developmental assignments are outsourced? In the case study outlined in the last blog, the organization needed leaders with expertise if they had any hope of realizing:

1. The project was buried under too many layers of management.
2. Even though there were multiple managers involved, the project lacked the level of management expertise and clear delineation of accountabilities and authorities.
3. The process for defining requirements consisted of too much paper and not enough hands-on prototyping.
4. The project team did not have any practical way to manage scope given that success factors were not defined.
5. The recommended technology approaches were too risky.
6. In spite of strong senior level commitment, the level of front line organizational churn and user dissatisfaction necessitated cancelling and restarting the project.

Relying solely on external service providers for this expertise isn't the answer. Even if our case study vendor knew everything listed above (and, believe me, they did not), vendors often don't know how to be heard and are conflicted about the messages they should send in light of the fact that these messages could negatively impact their relationships and, potentially, their revenue.

Some researchers are questioning the value of broad-based outsourcing. Research on IT management practices within the banking industry found that top-performing companies outsource less, and those that outsource IT on a wholesale basis "struggle to use IT to drive value and have limited strategic flexibility as the business context evolves and hardware prices plummet."

What do you think? Is it possible that large scale outsourcing not only limits strategic flexibility but also the capability to innovate with IT and therefore use IT as a strategic asset?

Think outsourcing eases leadership burdens? Think again.

A company decides to implement some packaged software to streamline their financing operations. They decide to outsource the work. The company does a great job working through a disciplined process to define requirements, solicit bids, evaluate vendors, finalize the scope of work, and negotiate the contract.

They hire a brand name consulting company to make it happen. The project seems to be humming along when the projects hits a wall, in what they thought were its final two months. It turns out that the users hate the software and for the next eight months, the project devolves into senior leaders "encouraging" the users to accept the software through education and some minor modifications. The project is eventually delivered but not without a significant amount of organizational angst — it exists today and will continue for the foreseeable future.

The software is late and not accepted by its users. The search for the guilty party settles on the vendor. Everyone agrees they are at fault and resolves to pick a better one next time. Clarify the scope of work and relative responsibilities, they chant. Hold them accountable.

Lessons learned? Case closed?

Hardly. This is an all-too-typical case of the difficulties inherent in outsourcing. Outsourcers have specialized expertise, but they don't have perfect expertise. After all, they are hiring from the same pool that you do.

When outsourcing, you can't manage through the contract, you have to manage through the people. Delegating to a vendor is no different, on a day-by-day basis, than delegating internally. You have to stay close in the beginning to ensure that objectives and success measurements are well understood, the approach makes sense, accountabilities and roles are clarified and the team jells. Then you have to stay close enough throughout the project to see what others aren't seeing, catalyze the right conversations, and ensure that the right mid-course corrections occur.

In the project above, internal leadership believed that their work was done when the vendor walked in the door. They assumed that the vendor knew what they didn't know — about how the business and IT operated, the legacy systems, the packaged software, and the new technology platforms. And they were completely dumbfounded when the users revolted against the software.

When internal leaders outsourced the work, they made the mistake of outsourcing the leadership of the work as well.

This is a common outsourcing fallacy, but a crucial one to recognize, because it has led many to believe that there's little need for senior leadership expertise within IT. That is, since IT is outsourced, leadership can be, too. While it's true that IT organizations that operate with an extensive network of outsourcing relationships have fewer employees, those that remain have to be much more sophisticated in their ability to exert indirect — versus direct — influence.

Is your internal leadership sophisticated enough to make outsourcing work for you rather than against you?