I've written here about value and benefits, but I've never talked about the underpinnings of Benefits Management. Time to correct that oversight.

Early in my consulting career I worked with a group of folks in the UK who were Cranfield business school disciples. Cranfield has developed a framework they call Benefits Management which talks about ways in which you can ensure IT actually delivers benefits to the business. This framework instantly made sense to me. As a technical guy, I had always known in the back of my head that IT had to serve the business in order to be successful, but I never really thought about it much. Benefits Management was the first framework that explained to me in ways I could easily understand how to bridge that all important gap.

If you're interested, you really need to take the course or read the book, but I'll give you a flavor of it here.

In summary, the idea is that when you make IT decisions, you need to make them based on business benefit. That is to say, how much will each project, program or architectural decision impact the business. This may seem difficult, and it is. The idea that Cranfield introduced me to that helped me understand was the idea of indirect but specific and measurable benefits. Cranfield has some very specific rules about benefits that keep you from creating false value statements. My favorites are:

1) A benefit must be measurable. If you cannot measure it, it's not a benefit by definition.
2) A benefit must have a business owner. If you claim that your software will increase sales by $2M, then the Sales VP must be willing to accept a higher sales quota as a result. If not, it's not a benefit by definition.

I cannot tell you how many IT planning meetings I've been in where one or both of these simple rules have been violated. A classic example is worker productivity. "Deploying this software will increase knowledge worker productivity!" Really? By how much? Is the COO willing to fire people because the company is so much more efficient? Or will production quotas rise because of this? If not, it's not a benefit.

In fact, flagrant violation of these rules led to once was once called the productivity paradox. Although this theory is largely debunked, it shows that massive technology infusions don't result in value unless they're carefully managed.

The second major revelation that the Cranfield framework brought to me was the idea that IT should focus on the top line of the business rather than on the bottom line. In many organizations, IT is simply a cost center. This means that you should do IT as inexpensively as possible. Containing costs leads to higher profits. Every dollar you squeeze out of the bottom line goes directly to profit. Unfortunately, as an IT guy this means you're the one getting squeezed. Not a fun place to be, really.

On the other hand, IT organizations that add to the business' top line are much better places to live. If you can create additional business value for your organization then you can justify higher budgets and larger teams. It's also way more fun to work in a place that's creating new things and adding value than a place that's all about cost containment. Since my exposure to Cranfield I have always sought to be on the value side of the house as opposed to the cost side. This change in thinking really changed my professional life.

ITA

How Do You Become an Architect?

Someone asked me one of those simple questions that are extremely tough to answer today.

"How do I become an IT architect?"

My first answer was flippant (go figure): Get about ten years of experience running IT projects then call me back.

My second answer was more so: The word Architect doesn't really mean anything. Just print up some cards and put that as your title.

Yeah, I'm not happy with that either.

So, the next train of thought is "how did I get here?" That answer is much simpler and sounds a lot like number 1. I've spent most of my adult life planning, delivering, building or fixing IT programs, projects and products. At some point, you find yourself designing more than doing and before you know it, you get an Architect pegged onto your title. It's a bit more complicated than that, but you get the idea.

I think the real problem is that there isn't really a fixed definition of what an IT Architect is. Everyone's got an opinion and they're all equally good (or bad). My personal definition is that the Architect lives in the space between business and technology. We translate from one to the other, when given business requirements we create technical specs. When given specs, we write a business plan or budget justification or impact assessment. In my mind this is the one unique skill that architects must posesses that other members of the IT staff normally don't.

Many of my peers focus on design. They design things. While I design things also, there are other members of the team closely involved in the design. Design in my world tends to be collaborative. Everyone wants to be a part of that. But when I explain to the CFO why he needs to cough up the dough for a new e-mail system; the rest of the team is strangely silent. I also don't hear many engineers clamoring for a specific feature because of the key business advantage it will give the business. Hence, my role.

So, how does one gain both business and IT skills? In my case I came from the IT side (which I think is better, duh) and then learned the business side later. At a certain point in my career I just got bored with technology. In the end, computers are simple. They do what they're told. People, process, business impact. Those things are complex. They change, they have no set rules. I spend much more time trying to figure out how cloud computing will change the IT landscape than how Hyper-V works. Hyper-V is simple. Cloud computing (which to me is a business model) is complex and still evolving.

If you've been in the IT business and you find yourself topping out, then it may be time to think about becoming an architect. Go to business school. Take one of those Executive MBA courses. Look at the world differently. Just take your CFO out to lunch. Learn what makes him tick.

ITA

I predicted this

The anti-Google forces are starting to gather: Google is a dangerous monopoly -- more than Microsoft ever was Betanews

I predicted this would occur last year.

OK, it wasn't a really tough prediction. Americans love the underdog. They hate the big guy. We're funny that way. When Google was an up and comer, everyone loved them. The more successful they get, the more people want them to loose. Strange. The same stuff that makes you a hero will ultimately damn you if you get too good at it.

For the record, I think this is crazy. Google is doing the right thing. Just like it was crazy to criticize Microsoft for being successful, it's crazy to do the same thing to Google.

ITA

Change is a Value Precursor

You cannot add value without changing something. That's a fact. Think about it. I'll wait.

OK? Ready?

From gold made into jewelry to a consultant putting words on a page, the act of creative construction or destruction requires change. Therefore, change is by definition a value precursor. If you do not change something, you cannot add value.

This statement is not true in the reverse. Change does not imply value. Not all change is good.

"So what?" you say.

So, as an architect our job is to be a change agent. By definition we change things in order to create value. The value we create is by creating new objects, processes or artifacts. These changes can result in value to the business if we do our job very well. They can also become shelfware and provide zero value. This is the choice we make as architects.

As you view your architectural domain, think about the broad array of changes you COULD make. Then construct a system that allows you to make good choices by evaluating the impacts of those changes to the business. In most cases, the choices are not simple. Otherwise, the positive change would have already been made long ago. There are usually pros and cons for each choice. The cons are usually painful and sometime involve sacred cows within the organization that everyone is afraid of touching.

In a recent strategy review meeting, a broad array of choices were presented to the team. The problem space was very large so there were many things we could invest in and it was fairly unclear how to proceed. Many of the choices were interelated and it was unclear where we should start. I really needed to create some sort of structure to the problem because all the unknowns were making it impossible to make any sort of decision.

Step 1: Put things into buckets.

In this case, I needed to gather things up into smaller buckets so I could look at the buckets individually. Most large problem spaces can be bucketed up. Don't allow the team to wallow in deciding what the buckets should be. You can adjust later. This is just a framework for making the problem simpler. Sample buckets that I've used before:

• Operations, Sales, Marketing (For a consulting company)
• People, Business, Process, Technology (for an IT shop)

You get the idea.

Step 2: Sort into the buckets

Take all the random junk that you're talking about and put them into the buckets. If things are really out of control, I make people put their ideas down on sticky notes and group them on a wall or whiteboard. Then we argue about the groupings. Sounds dorky, but it gets people to think and DO SOMETHING instead of navel gazing.

Step 3: Sort within the buckets

Inside each bucket, you'll probably wind up with similar things. Group them by affinity then stack rank them. The things with the most positive benefit on the top. Again, as we have discussed you may not ascribe value to something that cannot be measured. Budget, headcount, morale scores are all valid criteria. "That's a cool feature" isn't.

Step 4: Assign priority

This is the hard one. If you have fifteen buckets, you can't go do them all. If you have four, you may be able to assign one to each team member. This is really a judgement call. I cannot tell you how to do this (sorry). I can say it gets easier with time. If you get stuck and the team cannot decide, fall back and punt. You can ether do an affinity matching exercise (where the team simply votes) or you can use metrics to decide (revenue breakdown, budget, etc.). Either way, making a decision is important and this step can't be rushed.

Step 5: Assign Owners

This is the point where the meeting usually ends. Everyone congratulates themselves on having a good meeting and NOTHING AT ALL HAPPENS. I've seen this hundreds of times. Unless you have specific action items with assigned owners nothing good will happen as a result of your hard work. Don't let your architectural heavy lifting come to naught. If you don't have the pull in the organization to get things done, be sure your sponsor is on board with the process and get them to make assignments and follow up.

My friends in the UK call this exercise the "bun fight" because of all the back and forth arguments that happen. I call it "making the sausage" because it ain't pretty but the result tastes pretty good if you know what you're doing.

Good luck!!

ITA

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.