Owning All Clouds

cloud-computing-multiple-clouds

By Doug Harr

As part of my career as an IT executive for the last dozen plus years, I’ve led several companies through a process of migrating their business application portfolio to the cloud.  At Portal Software, that meant deploying SuccessFactors for HR performance reviews, and OpenAir for Professional Services Automation.  At Ingres that meant deploying Intacct for Financials, Salesforce for CRM, and lots of other cloud solutions. The approach for me reached its zenith at Splunk, where we had a 100% cloud business application portfolio, and where 50% of our compute and store capacity was at Amazon. With so much functionality in the cloud the question of roles and responsibilities became a focus for the company. In this very cloud-friendly shop, what should IT’s focus be? What level of administration of these solutions could actually be owned and delivered by departmental owners, such as Sales Operations, Customer Support Operations or HR administration?

As one example, both at VMware, where I was program manager for their Salesforce implementation, and at Splunk, where I was the CIO, we had very strong sales operations teams, and fairly complex Salesforce environments. In those environments Sales Op’s began to take ownership of more functionality in the Salesforce suite. This included user administration, assignment of roles to users, territories to reps, and just about all reporting. This grew to include modifying page layouts, and other configuration capabilities normally owned and controlled by IT. In my view the idea of enabling the Sales Op’s team was attractive for several reasons: (1) they wanted the power to do these things (2) they were not waiting for IT on the things they felt were high priority (3) they were closer to the sales teams who actually worked inside the tool, and so they were good at interpreting issues and acting – as good certainly as an IT Business Analyst, or even someone with fairly good technical skills. In these scenarios it freed IT to work on deeper technical issues, level 3 incidents, environment management, integration, reliability, etc.

In another example, at Splunk we made wide use of Amazon EC2 for compute and storage capacity. In these cases, IT System Admins were not needed – environments were spun up and used directly by personnel in Engineering and Customer Support. This was an amazing success, and it freed IT to work on monitoring usage, working deals on cost, and managing the overall vendor relationship.

Not every department has a team or individual ready to own or take a major role in the management of a SaaS or IaaS platform. For every HR department that manages Workday, there’s a finance department that does not manage Netsuite. It depends on the tool, and the personnel. What I’ve found is it can also depend on the CFO and management of a business function – some execs are happy to have these resources placed in the business, some are more afraid of  “shadow IT spend” or they’re caught up suggesting that IT can’t deliver and granting this power is a cop-out. Actually, I had a moment like this at Splunk, where I had not adequately updated two peer execs on our intent to get more deep IT skills hired into Sales Op’s, and had to sort that one out, to make sure everyone understood this was not a shadow operation! So there can be bumps in the road, but in my view adopting this approach is inevitable really, as software platforms and micro apps are becoming widespread, and so is the ability and desire by departmental teams to be more involved in the direction of how those tools, platforms, and apps are rolled out and used.

All this speaks to the future role of IT, and I for one have lived that future, as least in part. It’s one where IT is more strategic, focused on vendor/portfolio management, integration and security. To be sure some functions that are broadly used across all departments, and some that are task specific, still accrue to IT in most cases, or to partners that offer elements of typical IT as a service (think Help Desk). But done well, each department owns more of its technology, feels more in charge of its future, its technology adoption, its responsible use, along with other benefits. And, IT focuses less on being everything to everybody, maintaining disparate queues of backlogged work, and more focused on higher level matters, transforming the business for the digital age, and accompanying delivery of more complex technical solutions.

Right where we should want to be.

@douglasharr

When Using the Numbers Makes for Good IT Decisions

By Reed Kingston

ROI blog image

In his recent blog post, Mark Tonnesen explained why he didn’t rely on traditional business case analyses, such as value case and return on investment (ROI) evaluations, to justify IT investments. I agree with Mark that these methods too often fail to support the right projects, and can fail to expose the wrong ones. I’ll put my MIT quant hat on here for a minute: if you are using tools that are prone to both false positives and false negatives, you should be looking for a new tool, or at least use the ones you have differently.

The problem is not that the financial analysis of an IT investment isn’t important—in fact, it is imperative, as it is for all investments. A good financial analysis casts light on some of the assumptions and trade-offs that are implicit in a large investment decision.

Problems arise when an investment comes off as lower profile, as happens often when reviewing IT investments. Decision making will always be biased against standalone technology investments as these are often poorly understood. How will “we’ll reduce network congestion and improve security by x%” fare in budget meetings against the sales and marketing team (“we’ll open up more markets!”), engineering (“we’ll design more products customers love!”) or operations (“we’ll lower costs with a new production process!”). That could be a pretty tough sell.

Getting to Good Decisions

Trying to justify IT investments without a business case driven by an internal customer organization can be an uphill battle. So how can CIOs and CTOs drive support for sound IT investments? Make sure important IT investments are tied to business cases that support increased revenue, reduced costs, increased customer loyalty and lower churn. Then provide financial analyses demonstrating how the proposed IT investment supports those business cases. This step defines the strategic value of the planned IT investment, making it a much easier decision for everyone to get behind.

Reed Kingston is a managing director at StrataFusion. Contact him at rkingston@stratafusion.com; follow Reed at twitter.com/reedkingston.

Why I Never Look at the Value Case or ROI

By Mark Tonnesen

iStock_000029072446Small

When evaluating potential IT initiatives, the most common approach is to focus on the numbers and look at the return on investment (ROI) or value case. For example, say your company is considering implementing a new Enterprise Resource Planning (ERP) system. Chances are the CEO and CFO will ask, “What’s the ROI?” Or, “If the new system will cost $10 million, can you show me how it will produce a much greater gain?”

As far as I’m concerned, though, if you’re asking about the value case or ROI when evaluating IT initiatives, you may be asking the wrong question and looking at the wrong things.

What You Should Be Asking when Evaluating IT Initiatives

What gets lost in the value case or ROI approach to evaluating IT initiatives are the bigger questions that are more important than the finance-driven calculations:

  • What problem(s) are we trying to solve?
  • What is the value to the business of solving this problem?
  • What objective/end state can we achieve with this initiative that we don’t have today?
  • What’s the best way to achieve our business objectives?
  • How important is solving this problem or achieving this objective for the business’ ability to reach its goals?
  • How will this help us make better decisions and run our business more efficiently?

Not Everything Can Be Measured (Using the Same Yardstick)

A problem with the ROI or value case approach is that you might be trying to quantify the unquantifiable. For example, say you are considering implementing wireless internet service throughout your office for $XX per month. How do you calculate the ROI on this? You can take a best guess at how this might improve productivity and come up with a number. But that would just be a guess. And it would ignore other factors, such as the positive impact this might have on employee satisfaction or addition benefits such as mobile applications. Once new capabilities are in place and available to the full team, they may lead to unexpected innovations and enhancements that further improve productivity. It is difficult to predict the benefits new capabilities unleash.

The Numbers Can Tell You Anything You Want to Hear

Your team’s best guess regarding the ROI of a proposed IT initiative is just that: a guess. As an example, I once worked with a large high-tech company that was big on ROI. The team worked on a series of technical support initiatives to develop self-service tools for customers. To justify these projects the team put together graphs showing a reduction in customer support cases and calls, and an increase in customer satisfaction.

Knowing what the cost of a support call, the team developed analyses that showed that the cost of each initiative was lower than the cost savings it would deliver and the projects were approved. Unfortunately, the projected savings never materialized. The team neglected to include factors such as growth, customer adoption rates, issue severity addressed by the tools, continuous improvement costs and operational support costs for the tools. An analysis that included all the right factors—beyond just cost—would have helped the company make a better business decision.

Where to Focus: Business Impact

When evaluating IT initiatives, I recommend steering clear of the value case and ROI approach. Rather than pulling numbers out of the air to justify (or kill!) a program, take a hard look at the business impact that the initiative will have. Ensure you are solving the right problem and include measurement points along the way to check whether the expected goals are being achieved.

Mark Tonnesen is a partner at StrataFusion. Contact him at mtonnesen@stratafusion.com; follow Mark at twitter.com/mtonnese.

Rapid M&A Integration

By Mark Egan

???????????????????????????????????????????????????????????????????????????????????????

  • Focus on the people
  • Take an aggressive approach to migrate the new business into existing systems
  • Plan to complete the work within 90 days of deal closing

Mergers and Acquisitions (M&A) are an important strategy for expanding business. Unfortunately, many times these actions do not meet their intended goals. Although considerable emphasis is placed on technology, products, and new markets, some fundamental issues are overlooked. After working on over 60 M&A transactions, I recommend that you focus on three areas: engaging your new employees, integrating the new business into existing systems, and completing all integration work within 90 days.

Engage Your Employees

First, focus on the people. Make sure that you answer their top three questions:

  1. Do I have a job?
  2. Who is my manager?
  3. What is my scope and responsibilities?

Until you answer these three questions, employees of the acquired company are not really listening and can’t focus on integration work. Be honest with employees, especially if you do not have a role for them, and provide assistance in finding a new role and incentives to work through transition period.

Migrate New Business into Existing Systems

Next, take a very aggressive approach to migrate the acquired company into your existing systems. With few exceptions, migrating acquired company systems over to your internal systems is much easier than investing a lot of time evaluating the acquired systems. Make sure that your existing systems have capacity to support increased volumes and additional businesses. This can be done as part of your IT readiness work well in advance of any M&A activities.

Have a 90-Day Plan

Finally, have a plan to complete all the integration work within 90 days of closing the deal.  Many IT tasks, such as e-mail, unified web site, and personnel systems can be completed on the first day of operation for the merged company. The remaining tasks should be aggressively planned for completion within 90 days. This approach positions your organization to take advantage of the newly merged company to develop new products and services and sell the expanded offering to your customers.

StrataFusion works with clients to develop their rapid M&A integration programs enabling them to improve the overall quality of their work as well as reduce costs.

Learn more about “Mergers and Acquisitions” in StrataFusion’s Knowledge Center and get to know our CIO/CTO Advisory practice.

 

Conquering “Big Hairy Audacious Goals”

An IT Transformation Starter Guide

By Mark Egan

Big Hairy Audacious Goals

  • Complete a “Big Hairy Audacious Goal” within 90 days
  • Clearly define the goal
  • Recruit your best staff to work on the project
  • Remove all barriers and set up the team to operate like a start-up

We all face “Big Hairy Audacious Goals (BHAG)” in our careers. However, many of them turn out to be crises we have to address rather than proactive initiatives that make significant positive impact on the organization. At StrataFusion, we believe in order to transform your IT organization successfully you need to set some BHAGs. At a former employer, we had a goal to set up the first private cloud and were asked to use company products. This was a big test of using all of the company products together for the first time and provided a showcase of this technology for our customers.

Step 1: Define the Goal (and Secure Support)

First, we started by clearly defining the goal: in 90 days, set up an operational private cloud that supports a mission-critical business application. We selected a business intelligence (BI) system supporting our marketing organization due to its critical requirement to understand our customers’ buying behaviors and design marketing programs to gain their attention. We then set up a regular cadence of meetings with our R&D organization to ensure we were using the products as designed. With R&D’s buy-in, we got support when we ran into issues, as many of these products had never been used together before.

Step 2: Recruit your Best Staff

Next we formed a BHAG team with the very best staff within our organization, recruiting them to the project full-time. Initially there was a lot of push-back as we pulled these key staff members out of their existing roles and key projects. We engaged the team and gave them a free hand in bringing in any staff from other organizations inside/outside the company.

Step 3: Remove Barriers

Finally, we removed all barriers for the team and allowed them to operate like a “start-up,” eliminating internal process constraints. The BHAG team did not have to follow change control processes, and was allowed to use non-standard hardware/software and bring in third-parties as required. We provided strategic management support for the BHAG team and held weekly meetings to remove any obstacles from completing their project.

Success

The private cloud project was completed on time, and the mission-critical applications continued to support key functions in marketing. We had developed a showcase for our customers demonstrating how to set up a private cloud in 90 days.

StrataFusion has worked with clients to develop big goals and transform their IT organizations so they can focus on key areas such as revenue growth, customer satisfaction and innovation. With the right team and the right strategy, conquering a “Big Hairy Audacious Goal” is achievable in 90 days.

Conquer your IT Transformation Project. Let StrataFusion show you how.

StrataFusion IT Transformation Practice