The PC is dead? Really?

I'm sometimes really impressed and humbled by the things other bloggers write. Some days, I think "wow, there are some really smart folks out there and I just can't compete." Today is not one of those days.

Nicholas Carr wrote a blog posting today (The PC Officially Died Today The New Republic) that really makes me wonder what he puts into his Double Latte with a twist. Let's set aside the actual topic of the article, the iPad. It's a cool little device and looks sexy as hell. Let's talk about the death of the PC as we know it (Mac, Windows, Linux, whatever). The reality is that the PC platform is the worst computing platform known to man, except for all other platforms which have been invented. Sorry Winston.

What this really comes down to is the keyboard. Quick, efficient input requires a keyboard. Folks are willing to sacrifice this in the name of convenience, but to really do any serious input, you need one of these clunky things I'm using right now (and I'm assuming Mr. Carr used one also). I would love to see something faster and more convenient than a keyboard. Haven't seen it yet. Voice activation? Have you ever tried dictating to someone? I type faster than I can talk. Natural User Interface? What, like ASL? No thanks. Killing off the mouse may happen (though I doubt it) but the keyboard is here for a while. My primary work machine will always have a keyboard. Until someone comes up with something better. Still waiting.

So, if you have a computer with a processor, display device, some local storage (volitile, non-volitile, magnetic, solid state, whatever), a keyboard, some sort of input device (touch, mouse, trackball, whatever) and a connection to a network; what is that? Well, in the biz we call that a PC folks.

ITA

Should we just get out of the way?

Saw this interesting story on ZDNet today:

How did IT fall so far behind the tech curve? Between the Lines ZDNet.com

Gartner makes the case here that IT is so messed up that they've become the problem instead of the solution. The article made me stop and think about some long held beliefs. Here are the things they made me question (in no particular order):

1) Standardization is good. While it's true that standardization makes MY LIFE easier (and it's really all about me and my needs, isn't it?); I'm questioning now if it makes our customer's lives easier. In reality the standardization drive was done to reduce IT costs by allowing users to make fewer choices on their own. This reduces the number of wrong choices but also eliminates some good ones.

2) IT is really hard and should be left to experts. There are some things we do that are really hard. Configuring a Cisco router is not something that I would let just anyone do. But installing MS Office? You really just need to click OK a bunch of times. Accept all the defaults and you're probably OK. Are we holding things too close to the vest?

3) Allowing users to purchase their own technology is more expensive than doing it for them. This is a tough one. I know that if I do a group purchase of laptops, I can get a discount. So this implies some savings here. On the other hand, I have to manage this process with my expensive labor. This negates to some degree the savings. Seems to me that that larger you get, the more economies of scale kick in and make the group buy scenario work.

The scenario I see playing out is that users get all excited about some new technology and buy it. Then it doesn't work. Then what? As long as the users are OK with me telling them they're on their own, I'm OK with them buying their own stuff. Deal?

Customers and Partners

A recent discussion with a client got me thinking about the nature of customers and partnership. This particular client has a very decent business selling complex software to the US military. Unfortunately, the military is a great customer but not a very good partner. What I mean by this is that they are fundamentally unable to support and maintain complex enterprise class software the way a typical large private sector enterprise would.

The things you would normally expect to just happen need to be explicitly spelled out and included in every contract. In many cases, the military is assuming that all systems are “turn key” in that they need to provide zero support and maintenance for the systems in question. As a long term enterprise IT guy I found this shocking. Simple things like backups and regular maintenance become long protracted struggles. If it wasn’t in the detailed contract, it won’t happen.

I found myself fundamentally questioning my assumptions about customers and my relationship with them. I now realize that this state of affairs is not a given in the vendor customer relationship. I don’t really have customers in the traditional sense that exists in many industries. In reality I expect to have a partnership with my clients and they have to work hard to make my products work. I sell things to professional IT people and they understand what is required to maintain them. We speak a common language and we make huge assumptions about what will or will not occur.

The next phase of the software industry is the move to cloud computing and SAAS. In this model, we are able to transition away from the partnership model that I know and understand to a different world. This is akin to the difference between retail and wholesale buying. If you buy one washing machine from Sears, they show up and install it. They even take the old one away. What happens if you buy 10,000 washing machines from GE? I’m sure they don’t help you install them. They show up on palettes at your massive wearhouse and they’re your problem. Different market, different business model.

This implies that the current spread between “retail” software companies and “wholesale” software companies will continue to grow and expand. Will there be a place for more traditional ISV’s who sell to IT professionals? Sure. Think Costco or Home Depot. Terrible service, but great value if you know exactly what you want. The software business is so young compared to things like shipping and CPG that we will continue to see evolution in business models and very rapid pace of change for some time. This is great for folks like me who enjoy change. Not so great if you’re looking for a “safe” job that won’t go away on a moment’s notice.

Back to the ISV selling to the military. In this case, you have a customer who is not ready to accept the technology that you are attempting to sell. You can make tons of money, but in the end your business is based on a house of cards because the customer cannot receive long term value from a system that they cannot use or support effectively. What to do? The obvious answer is SAAS. Move the business from wholesale to retail. In the case of the military or other security sensitive organizations, this is not always possible. What else? The thing that sprang to my mind is appliance. This is seriously old school, but after working with this customer, I’m starting to understand the appeal of a black box that requires zero technical support from the customer. Just plug it in and turn it on. You lose some functionality this way, but gain a level of control over your deployed technology. You are no longer held hostage by the IT capability (or lack thereof) within your customer organization.

This brings me to my second conundrum with this client. They are very focused on customer deployment and usage. Software sales that do not lead to deployments are considered failures. At first blush, this makes sense and shows a keen understanding of the value cycle. If the customer has not deployed your product, they are getting no value from it. This means that you won’t sell them another product and they won’t give you good word of mouth. So, a focus on deployment makes sense. However, see problem one above. Their customer base is not able or willing to do the hard work needed to implement systems of this complexity. What to do?
In practice, this policy has led to customers holding the company hostage. Failures within the customer organization are solved via solutions (more tech, more labor, etc.) delivered by the vendor. This imbalance in extreme cases leads to a vicious circle where the customer becomes more and more passive while the vendor deploys ever more heroic efforts to make the customer succeed despite themselves. What’s lacking in this relationship is balance. A partnership is needed but what they are getting is a client-vendor relationship that’s out of balance. How has this come to pass? How can the customer expect to receive almost unlimited support from this vendor while doing almost nothing on their own? To my outside eye, this looks very much like the type of co-dependency relationship that you hear people talking about with alcoholics and those who love them and support them. This well meant love and support only enables them to continue their addition almost indefinitely.

In a business sense, the issue is that the vendor’s goals are wrong. Their stated goal is to have “completely satisfied” customers. They define this as customers who are willing to give a reference to a prospective customer. This goal is a bit too simplistic and has led them to this terrible state. My suggestion to this client was to change their definition of success. I feel that a successful client engagement is one that enables the customer to stand on their own. Just like successful child rearing, the goal is to put yourself out of a job as soon as possible. A customer who does not need you and does not call your support line is a good customer. One that loves you because you perform heroic acts to fix their broken server in the middle of the night is not a good customer. Think about it just in terms of dollars and sense. The first customer is much more profitable than the second and will lead to the exact same number of references and will have the same positive effect on your marketplace perception as the second customer. The goal is to produce more of the first scenario and reduce the number of the second scenario.
So, how do we measure this? As we’ve discussed before, a benefit does not exist if it cannot be measured. Many of the things you need to do to construct these types of relationships are fuzzy and difficult to measure. Joint ownership, stakeholder buy in, upfront frank discussions of requirements and customer expectation management are all key here but don’t have hard metrics attached to them. An interesting metric to get started here is to measure the current user base. How many support calls per seat are generated by your customer base? How does this relate to the sales and services process? In some cases, bad customers are born in the first sales pitch. Salesmen who under sell complexity set an unrealistic expectation in the customer’s mind that will persist throughout the relationship. An interesting metric to consider is to measure Sales on overall deal P&L. It is difficult, but you can measure deals based on their overall margin at the per deal level. Deals that are under-sold will wind up being less profitable on a per deal basis. Customers who are unprepared will require additional post sales resources and that also cuts into profitability. Hidden costs often creep up in the services side since most support agreements are not incident based.

Here are some specific recommendations I gave to this client:

1. Keep the deployment metric. It’s good and gives sales the right perspective on long term value. We can fix the bad behavior with proper metrics and management.
2. Add a “profitability” metric. Each deal must be profitable within a specific time window (1 year) and meet margin targets set by sales. “Strategic” deals that are loss leaders are fine, but must have a real backend within xx months. Each negative deal needs a deal above target margins to make the overall numbers work out.
3. Place better cost controls on services. There is a temptation to “make it right” by giving pre or post sales technical resources away for free. The reality is that these resources are not free. You are simply hiding the costs by playing a corporate game of three card monty. Every customer delivered hour must be accounted for. You get paid, or you record this as a loss.
4. Give technical teams control over effort estimates. Pricing and quotes are owned by sales, but effort estimates are not the providence of sales people. They don’t know what they’re doing so why give them that authority? Allowing the sales team to modify effort estimates down gives the customer a false sense of the effort required. In turn, you need to hold the technical teams responsible for their estimates. Managers who estimate well should be rewarded. As my old CFO used to say; “a variance is a variance, estimating way to high is no better than way too low. Get within 10% or you’re just guessing.”
5. Dispense with “fixed price” bids. This will cost you in the short term but is necessary. You can only survive on fixed price deals when you either tightly control the variables involved or you increase your bid to include large contingencies. Neither of these are realistic when dealing with the DOD sector.