Congratulations—you’ve successfully aligned your IT priorities with core business goals. As we highlighted in an earlier post about IT alignment, this process can be streamlined if your CIO reports directly to the CEO. More than one-third of CIOs now report directly to CEOs, a 10 percent jump from just one year ago, according to a recent KPMG survey. Another key to success: Getting the IT and line-of-business units to speak the same language, to think in terms of business—not technology—mandates. Business mandates can include everything from cost reduction, to improved customer service, to speed to market, to better communication with your supply chain partners.
But hold on. Before picking technologies to help achieve business goals, you’ll want to agree on exactly what “success” looks like. Say you’re updating the company website with the goal of simplifying customer navigation. What is the success metric? Is it fewer drop-offs? Is it more time per visit? Is it increased sales or registrations? Remember to be specific with your business-side colleagues about exactly what metrics will be used to gauge progress.
These key performance indicators (KPIs) should go to monitoring the rationale for the technology’s deployment (items like reduced cost, greater speed or effectiveness), as well as business-value metrics, such as customer satisfaction, market share, and profitability. You’ll also want agreement on how often these KPIs will be measured, how they’ll be reviewed, and by whom. Just as important: Decide on a process for what happens if a KPI misses its mark. Specifying the KPIs, and the process around them, now, before deployment, definitely reduces the chances of unfulfilled expectations and finger-pointing later on. And remember that the metrics you track can change over time as old goals are achieved or the business evolves.
Build or buy?
For virtually every technology investment, you’ll have to ask this basic question– “Should we maintain this in-house or outsource it?” And the right answer isn’t always obvious. Take a business application delivered via a cloud service, for example. Cloud applications have a number of benefits, such as a predictable cost model and ease of deployment. But there are other, important considerations, such as:
- Can a cloud service provide the configurability the business expects in the future?
- Does the application require special compliance or security elements unavailable in a cloud service?
- Can the business bring valuable new features to market with an in-house developed application?
- Will the total cost of the cloud (hardware or network upgrades, monthly subscription, consulting fees, data migration, etc.) really work out to be less than an in-house solution?
- Can an on-premises IT approach replicate the techniques, benefits, and economies of a cloud service?
Careful review of these questions can help determine the answer to the initial “build vs buy” question, helping you to choose the technology investment option best for your bottom line.
After deciding the “build vs. buy” question, think in terms of a pilot. Given the many advantages of piloting a technology solution before large-scale deployment, you’d be shocked by how many organizations mismanage this key step. Before launching the pilot, take time to hand-pick your beta testers. Consider the following when recruiting and using beta testers:
- Do they fit the profile? If the app will be used by HR executives, you want beta testers in that role (or who have experience with that role)
- Offer your pilot testers something in return for their participation to show you value their involvement.
- Remember that a failed pilot can still be a win if it gives the project team new ideas about how to deploy a technology.
(Regarding failed pilots, consider conducting a post mortem– Look for problems with processes or people. Even successful pilots deserve a post mortem. Get the project team to go over what worked and what didn’t go so well, then apply what you’ve learned to your next project. By templating project execution, your projects will be predictable and successful.)
To gather feedback from your beta testers, create a question set (a phone call often is better than a questionnaire for this). Some of the questions you should ask are:
- Tell me about your experience with X.
- What specifically was helpful?
- What specifically was unproductive?
- What could be improved?
- What was confusing?
- What would you share with others about X?
- Would you recommend X to your colleagues?
- Is there anything else you’d like to report?
Enlisting beta testers gives stakeholders “skin in the game” in the development process, contributing to its future success during wide-scale deployment. But this only works if you commit to incorporating the testers’ input and insights. Don’t undermine the acceptance of the finished product by disregarding or downplaying the opinions and concerns of your beta testers.
Pilot to deployment
A word about pilots: You might wonder, “What’s the appropriate number of beta testers for a pilot?” or “How long should a pilot run?” Unfortunately, there’s no rule of thumb here, given the host of variables: the size of your business, the urgency of the business mandate, the organization’s culture and your resources. In fact, a better way to conceptualize your pilot is as a methodology, a discipline, a way of developing a solution that is tightly tied to your business goals. This will codify how you collect performance and user data from your beta testers and help create an iterative process for improving the solution, based on this feedback.
The key word here is “iterative,” meaning continual or ongoing. In other words, the infrastructure you create to measure your pilot doesn’t ever really go away. Because in a very real sense, you’ll always be piloting, even after deployment. Whether it’s a new operating system, a new shared printer, or a new feature on the company website, you should always keep an eye on performance and usage data. Along with these metrics– key performance indicators (KPIs) you’ve established in cooperation with other parts of the organization– pay attention to suggestions (and complaints, too) from your users during and after the pilot. In the case of complex projects, though, you should try and break the work into parts, which will result in running numerous pilots simultaneously.
Scaling the solution
When the time comes to move the pilot to wide-scale deployment, you’ll want to pay special attention to scalability. That is, what happens when the solution is touched by a large number of production users. Thankfully, there are plenty of tools to help you simulate the impact on systems and networks of simultaneous, diverse users. Use them!
Even so, expect to be surprised when whatever you deploy is subjected to real-world conditions. Scalability issues are particularly important for SMBs. To remain competitive, businesses need to control costs and prepare for future growth. For many, this means delivering consistent performance, products, and services, possibly even to a global market. Given this, it’s no wonder why so many SMBs turn to Software as a Service (SaaS), subscribing to cloud applications accessed via a Web browser.
The beauty of cloud services
Unquestionably, cloud services are the hot sector of the market right now. The cloud software market reached $48.8 billion in revenue in 2014, representing a 24.4% year-over-year growth rate, according to IDC. Cloud software is expected to grow to surpass $112.8 billion by 2019 at a compound annual growth rate (CAGR) of 18.3%. IDC also forecasts that SaaS delivery will significantly outpace traditional software product delivery, growing nearly five times faster than the traditional software market and becoming a significant growth driver to all functional software markets.
By 2019, cloud software model will account for $1 of every $4.59 spent on software. If you take away anything from these numbers, just know that cloud technology is becoming a huge and increasingly important resource for business growth. But cloud services should be evaluated according to the current needs and future expectations of the business. Whether your business application is delivered through the cloud or on premises, you’ll want to capture expectations about performance.
Again, key performance indicators (KPIs) should be proposed and agreed upon with the relevant stakeholders. Along with the KPIs themselves, you’ll want a schedule for when these metrics will be reviewed and shared, and what happens if they are underperforming. As your IT operation builds experience with the pilot and the early days of the production deployment, from squashing bugs to learning the peculiarities of the solution, you’ll want a process for capturing and documenting these items. Not only is this a best practice in terms of development, it is valuable information for the support team.
Training the team on known problems with the solution makes them better equipped to handle support calls, once you’re in wide-scale deployment (just be sure to provide an easy way for users to report problems). Speaking of your user base and full-scale deployment, have you sufficiently explained to these people why the solution is being deployed? Be sure to use some of the same business mandates that you articulated at the beginning, when the technology solution was picked in the first place. Do this convincingly, and your users will understand why the system is worth their time; moreover, they’ll help you improve it.