If at this point in time, your business has not deployed or have the Windows 7 readiness in action, you might be in the "big bang" territory for this upcoming technology refresh cycle. If your business has a "ride it 'til it dies" refresh program, perhaps this is a "Aha" moment.
We have just about completed the Windows 7 Year of the Refresh Roadshows throughout North America. For those of you that I have had the pleasure to meet and chat, I thank you. The sessions and the follow on Q&A flagged several issues and concerns, and validated many of our beliefs about this upcoming refresh cycle. First the disclaimer.
The opinions and comments expressed on this blog are mine, and do not represent those of my employer.
One of the key points that we validated in the sessions, was that this refresh cycle will, for the most part, require a detailed business plan with concrete ROI and contribution calculations. Moreover, this refresh cycle wil require a definitive statement of benefits to the enterprise. We also validated that with Windows 7, new product features, new technologies (virtualization), practice improvements, security, (I could go on and on, but the point is made) suggests that this business case simply is compelling as any we have collectively seen in the industry.
Interestingly, when I asked the question if the business case would be the key mobilizer of the technology refresh cycle, the response was almost universal in its positioining - not without addressing the politics of the refresh.
We have known from previous research that a good (or even great business case) can be trumped by politics, social issues, cultural concerns, and emotional issues. In this refresh cycle it is clear that there are inhibitors to the refresh cycle. This may or may not be a "bad" thing.
In Closed Loop Lifecycle Planning (my research) we have concluded a number of findings in regards to the emotions of change:
1) You cannot overcome emotional argument with business logic
2) Even the best ROI and business cases need to address the emotional, political, and social aspects to succeed
3) The Great Recession is a game changer
Based upon this, the question is how to manage and address organizational behavior. To a high degree, we in IT are our own "worst enemies" in this respect. When we were asked to do more with less, we did a lot more with a lot less. When asked to make older technology work, we made the older technology work (and work well). Now we are at a point where client technologies need to be updated, but the political realities take over- cash is stil short, the economy is still uncertain ... so IT , "squeeze out another year". This tends to be played invariably in one form or another.
To some degree this is really a cause and effect that could be predicted. For many years, PC's and many technologies in general were viewed as "commodities". None of us would argue (or for that matter win the argument) that there is clearly a commodity aspect to PC's. But allowing the argument to go unchecked over time, leads us to the scenario that when we can innovate (such as virtualization, W7, etc) , the commodity perspective takes over. Quantifying the business case will not be enough in many cases since there will be a perspective that at the end of the day, how can you improve on a commodity? Politically, those who believe this may be likely less receptive to a technology refresh of scale since that would suggest that delaying the cycle could have had a less than positive impact to the enterprise.
In the blog we have discussed the potential of continuous process improvements (8% to 10%), the opportunities for step changes (>25%), energy management >$30 per seat, improved productivity >68%, and other amazing statistics that could accompany this refresh cycle. Much of the technology that is available now did not even exist pre-Great Recession.
Addressing the potential of this refresh cycle, requires IT to understand the organizational biases and ground that has already been staked out in terms of position. If once a commodity always a commodity exists, this is an inhibitor.
Perhaps a logical technique to engage is to focus on the economics, identify the perceptions, acknowledge them, and incorporate the objections up front into the dialog. Ignoring the objection will likely result in a sub-optimized IT refresh. Emotionally, convincing teammates that the refresh cycle is not about a commodity discussion will be decidedly different than other refresh cycles.
To some degree, this refresh cycle is about "green field"- a new playing field that is driven by a unique set of circumstances.
This is my perspective, I would like to hear yours!
For the past two weeks (and for the upcoming month) I am delivering a series of field sessions with teammates from Intel and Microsoft. To date, there have been a series of questions and comments that I would like to share and secure your commentary and feedback.
As always, the content on this blog are mine, and do not represent my employer.
Overall, the feedback on Windows 7 has been positive. Most businesses recognize the business case and are seemingly moving ahead. I tested my belief that this refresh cycle requires a really well documented business plan with quantified details and, for the most part, there was agreement. The following represent 5 of the top questions (with apologies to David Letterman's Top Ten list, by the way we did go to the same high school).
Question #1- Should my business adopt 64 or 32 architecture? My response, is that as long as the cost differential is minimal, 64 is the way to go. The idea behind this is knowing that we do not want to even upgrade a desktop or laptop once deployed, having the higher architecture makes sense. For newer applications, multiple sessions, and futures the 64 architecture will return the investment.
Question #2- Does my business need a new PC to make W7 work, or can I add disk and memory if needed? My opinion differed from others in the sessions to a degree. One of the points about W7 is that W7 is optimized on the new Intel iCore technologies and newer platforms. It seems to me that deploying a new operating system on older technology simply defeats the purpose and sub-optimizes. If the technology is new(er) within an 18 month window, different story, but even then I would encourage a look at a trade in strategy. I joked that the answer from the hardware company was to buy more hardware, the software company solves all ills, and the chip company encourages newer chip for benefits. The point I have made in other blogs still remains true- if you line up six consultants in a room and ask the same questions, you will recieve six different answers and all will be correct. The business plan will be unique for each business.
Question #3- Is your business virtualizing? Not surprisingly, a lot of hands go up when this question is asked. There still seems to be a lag in the timing to go from the pilot and proof of concept phase to production. The hands that go up when I ask if there is scaling are fewer,and when I inquire if the roll out plan is defined, there are clearly concerns. This suggests that this to some degree remains a work in process.
Question #4- I asked the follow on question of whether the virtualization is to be deployed before W7, and the response seemed to be, "we would like to" but unsure if the business case, user segmentation, and other factors could be vetted in time. The application stack is almost always identified as the issue. Having W7 run in XP mode for these may be a viable option to consider.
Question #5- Last question (for this blog), What is the timeframe for W7 adoption? Almost all businesses are looking at this today. The constraint is obviously stated as cash. We discussed leasing, PC as a Service, big bang vs. phased and other topics in this area of interest. In most businesses, the business case is in process of being defined.
After the sessions, I remain of the opinion that 2010 is indeed the year of the refresh. The benefits that are counter measures to the gross acquisition pricing approaches 30% to 40% of the overall total. This makes this refresh cycle unique in terms of the economics.
Let me know your thoughts.
This technology refresh cycle is, of course, our first refresh cycle post Great Recession. Many businesses are wondering - should we phase the refresh cycle or should we just "bite the bullet" and big bang the refresh? As in all matters of client lifecycle management, there is no right or wrong answer, only conscious and unconscious decisions. Having said this, however, one can make a strong business case in either scenario depending on your particular business, however, the phased argument is now more challenging to make, to a high degree I have changed my view on this as well.
As in all of my blogs, the opinions represented in this blog are mine alone and do not represent my employer.
Spring is here, baseball, NBA playoffs, Final Four and budget cycles for businesses (I know that this is a stretch but the baseball season begins today).
This year, the budget cycle has some unique aspects to it for client computing. As a counter measure for the Great Recession, many of us (actually most of us) extended the useful life of desktops and laptops. Now our PC fleets are aging. In many cases the new software releases, energy management and power management options, applications, are not quite ready to optimally run on these older devices. We have inadvertently delivered on two things that may/will come back to "haunt" us in IT. First, we did do more with less, and we made the older devices work in the environment. Second, we have conditioned our end users to accept existing age and speeds (and hour glasses) as an acceptable response.
Now we are going forward to leadership and asking for funding to improve the PC fleet. This refresh cycle will likely require a detailed business plan.
This refresh cycle is different than all others before it as we have discussed in several of our blogs- Windows 7, new Intel chip sets, new form factors, new technologies, virtualization, the list is quite an impressive one.
Y2K was our last major IT refresh where it was not a "business as usual" refresh cycle. No one will forget the remediation efforts, and the big "sigh" that happended at 12:01 am. (perhaps big "yawn" is a better reference)
The choice this refresh cycle is whether to embrace and continue the phased refresh, to get back to the 25% to 30% annual model or to embrace the "big bang". For definition purposes, let's consider a big bang as a greater than 60% to 70% refresh pattern.
Most of the industry experts have published and written that the phased refresh cycle is the optimal. (Myself included in the past). The idea that disruption to the end user is mitigated, the resources can be leveraged, budgets are constrained, and a host of other valid considerations are still applicable, however, my opinion is that this perspective may be dated.
In the past 24 months while we were extending the useful life of the fleet, the technology footprint has dramtically changed. We could actually make a business case that suggests that the benefits lost in terms of operating expenses may well offset much of the budget required for this upcoming refresh.
If the conversation with leadership is solely about Capex it will be a short conversation. If you do not have the budget, then there is only so much you can replace. I understand that, but (and this is a big but) if it is all about the capital, at some point you will refresh the fleet, all we are doing is postponing the inevitable. Leasing, PC as a Service, consolidation of the PC budget to IT, all begin to play in this refresh cycle.
In providing guidance in this area, I would not be surprised if up to 40% of the Capex costs are offset by gains in Opex.
End users are seeking a better experience, if you are hiring new personnel attracting them with 5 year old technology (or greater) may prove to be interesting. How does a business justify more current technology to new hires and 5 year old technology to its existing staff? These are examples of some of the trade offs that you may need to consider.
Normal times the phased approach works, I am of the opinion that this refresh cycle has drivers that are unique. The fleets are so old by PC standards that we are almost left by default in a big bang scenario.
The recovery from this Recession, suggests that access to information is a competitive edge (for real this time).
What are you businesses doing to address this issue in your company?
I believe that going forward, it will be a challenge to go back to the phased refresh model.
There is an expression in New England that - "you can't get there from here". I am not so surre that we can return to the pure phased refresh approach in the near term without comprising end user experience, productivity, security, and access.
Back to lifecycle basics. Which is preferable- warranty or maintenance. The Great Recession has had another unintended consequence. By extending the useful lives of desktops and laptops, devices are outside of the warranty window. Should this be a concern, and if so what should your business do about it? I would like to ask you to share your comments.
As always, the opinions and views expressed on this blog are mine and do not represent those of my employer.
If I had my "druthers" I would always defer to warranty, the reason is simple. The conversation that I would never want to have with an end user is - "let me check and see if the device is under warranty". From an end user perspective, this is also the discussion you never want to have with IT.
The recession changed a bit of the dynamics; end users know and perhaps understand that the lifecycle has been extended and that being outside the warranty window is break/fix. End users have their home PC experience to reflect on as well. However, the end user needs to get back up and running regardless of whether or not the service level is warranty or maintenance.
My research suggests that maintenance is at least twice the cost of warranty. This is logical when you consider reimbursements of parts and labor. The real costs are driven however in the business requirements to enter the break/fix operation either by third party or internally. Entering the maintenance business itself may prove to be a greater cost than you may think. First, you have to be good at asset and inventory management. Second, you need to have a logistics approach and warehouse space. If you out task or outsource maintenance you have cracked part of the code I believe, scaling counts and matters. Do not confuse, though, that maintaining older devcies will extend further the useful life or that the monthly cost to support is small. Do not over look the downtime, help desk call, incident management process just to get to the break/fix provider.
If you are a global business, your challenges are even greater.
As the technology refresh gets in gear, and Windows 7 is deployed , what about all the investment in inventory and parts. If you maintain internally do not overlook the training aspect and the impact of the new chipsets. Driver and application issues may initially appear as hardware issues to the end users.
In essence we are at a crossroads of sorts. If the trend continues, the real total cost and lifecycle costs need to be identified and measured. That too presents a challenge.
In many of the meetings and sessions I conduct, we frequently discuss the fact the end users and business units are reluctant to return older, replaced equipment. I often refer to the "Star Trek" episode where the "hoardak" collects things and never returns them. Part of the rationale is that this becomes the hot spare, back up and maintenance strategy at the end user or business unit level.
Aside from the security, costs, risk and practice issues raised, it is an unintended consequence of the warranty vs. maintenance dialog. The recession may have clouded this issue but the economics are very straightforward.
There is a business case for maintenance to be fair. The basis is to align the useful life and a solid inventory control system in place. Businesses that decide that that investment is a part of an overall lifecycle strategy will do well. Defining a maintenance SLA is likely the initial step. The major question is this - does the maintenance SLA mirror the warranty SLA? If the answer is yes, then I would submit that pehaps a new SLA could be defined. Giving maintenance the SLA identical to warranty avoids the issue that it is not the same and that there are conscious trade offs. Maintenance works, and works best, when the SLA's can be comfortably and consistently achieved (without escalation).
The maintenance business has been around a long time and will always be around considering the requirement to support legacy by industry segment, regulations and preference. With this upcoming technology refresh cycle, it may be the time to recalibrate our operational defintions up front. Both warranty and maintenance are mature offerings, so as I always state- there are no right or wrong answers only conscious and unconscious decisions.