Saving your way to Bankruptcy

How often have you hear “Honey I bought it on sale and saved us a ton of money”? Really? Did at the end of the month you could see your bank balance increase? Often, we hear similar words inside an enterprise. We’ll saved 1000 man-hours with this new project.   Can you really save man-hours? I’ve not seen any place where time could be saved, much less get paid interest on it.

So, if these questions seem logical, why do we continually hear internally and from vendors about all the time savings? Possibly because emotionally we all like the idea of bargains and savings. The problem becomes that savings is not always savings.

Several years ago, I help develop an economic justification methodology specifically for my employer. As I had done this previously for other employers it wasn’t a large stretch if all they wanted was a standard ROI procedure.   I had brought up to management building an business case on time savings would have little value as CFOs and other management would know time saving is not economic benefit unless you do something with it or avoid having to get more resources to accomplish the goal.

The simple examples: I could automate a process using technology “saving” one hour a day per person. If I can defer hiring additional resources (cost) to accomplish a goal for a smaller investment in the technology, then I’ve actually saved money. If, however, I “save” one hour per day of staff time and nothing is done with that time, then I’ve actually lost money. If I continue to save time and money this way, I’ll be bankrupt in no time.

My advice for avoiding such a problem is while in the planning phases of a new initiative consider what you’ll be doing with the savings. Will the staff be able to effectively use that additional hour a day? This could be getting out one more proposal to a potential client, exchanging knowledge between peers, or any number of other activities. The key here is to have a plan on how that savings is to be used.

KPIs – Key Performance Inhibitors and a method to transform theses back to Indicators

This month I am dividing my time between several initiatives at work:

• Technology development activities
• Process adoption
• Metrics definition
• Skills transfer

A rather interesting and eclectic combination of activities. But as I started to ponder these I started to reflect on the metrics definition activities of past and the relationship to other initiatives on my list. My goal is to create a suite of KPIs for my group that is useful in advancing our success. With that premise several things come to mind.

• KPIs or metrics that truly indicate how the organization is progressing to its goals; rather than those fool us into believing we’re doing well when we’re not
• KPUs that the organization believes in; that is, we have control in positively effecting these and can relate to achievement of our goals
• KPIs that are diagnostic; they provide insights to help us determine what we can do better

This is a tall order considering people often are suspicious of how measurements are used. Especially if such has been used in the past not as guidance but justification for other agendas. This typically results in KPIs that are meaningless but always show green, even in the face of disaster. Such have a witnessed before within sales organizations that measured success by size of backlog rather than quality of backlog or customer satisfaction. This eventually became a game of musical chairs with the unlucky sales rep. at the end of the cycle taking the hit for a bad backlog he had nothing to do with.

Based upon such experience, my belief is that KPIs need to be a serious discussion and negotiation between all levels within the organization. Staff must believe that these measurements are able to be influenced by their actions; Management must believe these measurements indicate status of the journey to goal achievement.

These seem simple enough, except that the altitude that each party operates at is different. If you’re a Senior Executive you’re often looking at corporate performance: profit/loss, customer satisfaction, market share, etc. If you’re a programmer in IT you’re focus is on cost and time of delivering an application, response time of system, uptime, etc. This difference in metrics can and often does create misalignment between management and staff.

The results of which is often KPIs become Key Performance Inhibitors as staff become disillusioned with measurements as they can’t relate their measurements with goals management focuses on rather than how their measures relate to business measurements.

This conundrum can be address with a method called Hoshin Planning. Hoshin Planning is nothing more than a cascading set of matrices of goals, strategies, and measurements that relate one altitude of measurements to another. While the technique works well, it does require additional effort between management and staff to be explicit about the goals, tactics and measurements as well as reasonable in setting measures and targets that assignees believe are achievable. This however, is not a simple twenty-minute exercise and like all planning requires constraint revision in the light of new information (i.e., planning forecasts are not accounting transactions).

Structure in Threes: Metrics and Measurements

Spent the last few weeks divided between multiple projects and goals.  However, that gave me time to think about the topic of measurements.  Often in the IT field I see it being a great effort used to prove value or performance that ultimately has as its goal justifying existence.  When I hear about a new metrics initiative in most organizations it seems to boil down to how can we show with numbers that we’re meeting our targets.  All too often I think back to the radio show “The Prairie Home Companion” The closing words of the monologue are “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average.”

This leads me to believe either we’ve set the bar too low or we’re measuring the wrong things.  About ten years ago I was at a senior leadership meeting at one of the well know technology powerhouses.  The one of the senior executives had, by edict, required a “serious” effort to measure performance.  The problem occurred not with the desire to measure, but the implementation of such.  There was no goal, other than measuring.  Thus each division, sub-division, unit, etc. identify metrics to report on.  In total over 1000 individual metrics of which cost the corporation lots of headcount to capture, collate, massage, and report at leadership meetings.  When asked if any of the these metrics were used to manage the organization or inform executives to make better decisions. I saw a lot of staring at shoes by people.  I asked why measure things if you’re not going to use the measurements to inform your decisions and directions; more shoe examinations.  Needless to say I was not invited back to a senior leadership meeting for a while.

Fast forward a few years later, the corporation is not doing as well as it once was and IT budgets are under fire.  I was brought back by a new leadership team; under cover.  That is I would dial in unadvertised and then consult to select members of the leadership team regarding my impressions and insights.  I think I was given this opportunity because during the previous incident I had predicted a scenario of what would happen to the IT org under its present course.  It was not a feat of great insight, it was merely a matter of connecting the dots. In either event I spent time with them, not specifically telling them what or how to measure, but why?  The old maxim “you get the behavior you measure” I’ve found almost true.  Often people measure what makes them look best.  Metrics are often tied to performance rewards.  This often eliminates these from being diagnostic tools.  This a little like the joke about the airplane captain announcing  on the PA system:  “I have bad new and good news.  The bad news is we’re lost. The good news is we’re making great time.”   Eventually there will be a crash.

Which brings me back to the metrics and measurements discussion.  Establishing a measurement program, one should first identify the strategic goals and objectives of the organization, then create metrics around those.  Next identify Key Performance Indicators (KPIs) that support those goals and objectives.  I look at KPIs a little differently than most I guess.  I think the label says it all these are “indicators” of performance, not the actual performance.  These are sort of like road sides telling you your goal is 100 miles ahead, then 50 miles, etc. and your speedometer it indicating 50 miles an hour.  Together these KPIs help you determine if you’re on the right path and operating at the right levels of efficiency and effectiveness.

Which again gets back to a metrics program.  A useful program has a mixture of “strategic” and “operational” metrics.  The strategic metrics tell you where your going, the operational metrics support you in letting you know you’re making progress towards getting to your goal with your resources.

Structure in Threes: Building vs Planning

One of the problems systemic to the design and planning world is the often famous quote:  “Its done its just a small matter or implementation or programming or etc.”  All too often I’ve seen designers or planner consider the job done once the design is finished.  However, there is often a lot of work to get it accomplished; even it there are not changes to the design.  This got me thinking about the terminology used in regard to projects.  To me implementation take is a larger concept than just deployment which seems to be the typical thoughts around projects, especially in IT.  “The application has been installed we’re done”.  True implementation carries with it both deployment and adoption, anything less is just dumping.

The proposed remedy to this is to have adoption KPIs included in project metrics, not just development cost and schedule.  This would foster a greater concern that what is built is actually used.

Today’s Applied Research Agenda

Today’s agenda: R&D around Capacity Management for Services and Processes.  My presentation on metrics and measurement for processes went well, but I know risk and capacity management are a significant lack in this field.  Somehow everyone has gotten the opinion that Moore’s Law will bail them out…that hope is what the other engineering disciplines know now leads to unsustainability.  Received old book I ordered from Amazon Market [Computer Systems Performance Modeling, 1981 –Sauer]   that covered some of this in regards to computer systems.  Coupled with Meadows Limits to Growth (Systems Dynamics that Forrester introduced) I believe I can develop an approach to monitor, measure, and manage processes in more than a reactive way currently the industry norm.  While it will not likely be Nobel Prize winning stuff, I think it will help make Microsoft more competitive and responsive to customer needs     

Working Insights: Process Analysis presentation creation and the movies

Finished my presentation deck for Wednesday’s Business Architect call, sent it out to my manager & colleague, and other friends for comments.  The topic is business process analysis methods.  Its a short 20 minute presentation on the benefits and some methods of value for analyzing processes.  During developing I rediscovered what I already knew: Difficult to compress 2 hours of material into less than 20 minutes.  Makes me truly appreciate movie editors and directors…it take a lot of skill to cut things down to the bare minimum and no more.

Which has me reconsider my thoughts around BPR/M compliments I get in the form: “I’ve never seen anyone but you be able to diagram a process on the fly while we’re discussing it” or “How can you trim these processes down so well that there are minimum steps and each one contributes real value so easily?”  Often I just smile and say thank you, but really don’t think much of it its just what I do.  But I guess its because I’ve spent years honing my craft like editors and movie directors learning how to cut away what’s non necessary to the accomplish the job; in once case telling a story and in mine making a highly efficient and effective process for an enterprise.  I’m sure by now my colleague Sarah is smiling, nodding her head, and saying of course.

Structure in Threes: IT Investment Strategy Lessons

This week as I continue to research IT Strategic Planning issues for a series white papers I’m writing I’m noticing more gaps in the average IT organization’s planning approaches.  Despite more sophistication in technology, the planning efforts are still rather primitive.   Many IT Planning organizations spend significant time on the technology requirements, functions and interactions; which they should.  However, when it comes to the effects and benefits to the business which they serve, these functions come up fairly short still.  The average business case just little more that a primitive ROI based upon very weak assumptions.  It is not wonder why CFOs and Controllers are tightening the screws on IT projects and considering outsourcing and cloud alternatives.  A few organizations I’m aware of are looking at eliminating their IT function entirely and moving everything to the cloud.

Review of prior Portfolio Management R&D at IBM

This coming week’s agenda is to develop the optimum means for presenting the Modern IT Portfolio Management process to executives and managers.  During the initial portfolio management R&D for business investment at IBM an interesting reaction was observed.  Executives and Managers disliked operating on models with more than two to three factors, preferring two factor matrices with binary values.  This was rather interesting observation in that each Stakeholder when surveyed asked for multiple factors to be evaluated.  However, in practice only a couple of factors are examined for consideration.  These factors typically center around near term monetary consideration.   optimal portfolios with high risk.  Thus other factors or strategies should be considered which infers a more complex matrix of considerations.

Lessons learned from Venture Capitalists

Venture Capitalists (VCs) evaluate investment candidates based upon returns like other investors, however, other factors are often used to classify and filter opportunities.  These are often used in what has been called a stage-gate process.  This is a series of smaller decisions that in effect gate weaker opportunities out of the pool of candidates.  This makes the decision not a single yes/no but a series of yes/no decisions.  The other aspect of a VC‘s investment process is the core to the portfolio management concept; multiple independent investments.  Typically this is accomplished by VCs teaming with other VCs enabling them to make smaller bets but spread amount a larger group of opportunities.  This strategy reduces risk by eliminating the eggs all in one basket approach.  The final strategy many venture capitalist used to mitigate risk is employing a variation of options theory.  Employing this strategy, VCs will often stage release of funds based upon a business venture’s ability to meet specific goals.  If a venture does not meet these goals the VC has the option to discontinue funding and cut their losses or potentially take a more active role in the management of the venture.

Other Research

Other areas of investment research under current study for this practice include:

• Stock Brokerage [reviewing interview notes]
• Investment Bankers
• Insurance Actuaries
• Natural Resource exploration enterprises

Windows 8.1 Update and App Store: Microsoft’s Devices and Services strategy -weakness indicator

A week after Microsoft Level 1 help called and escalated to Level 2 with a scheduled callback for same day between 2pm -4pm, still can’t reach Microsoft App store.  Figured I’d upgrade to Windows 8.1 as inference was it would fix the problem while waiting for a callback.  Small problem; Upgrade to 8.1 links you to Windows 8.1 app store which doesn’t work.  Hmmm guest they’re really not interested in the Small and Medium Business market as much as the profess or readiness is an issue.

Over the past several weeks I’ve been tracking the various vendors: Microsoft, Apple Google, and Amazon as far as service quality; part of my Industry Analyst and IT Service Management (ITSM) background**.  A strong component of that is incident handling.  While uptime the customer experiences is the most important metric, handling a response in a timely manner is likely number two on the priority list, closely followed by customer communication.  Based upon that criteria Microsoft readiness to fulfill it’s new Business Strategy of Devices and Services is lacking.  Or may be Small and Medium Business (SMB) is just not the demographic it is going for now; instead using SMB as a buffer to its large enterprise customer business, as large enterprise is now in a transformation to Bring your own Device (BYOD) and virtual working, despite the fallback of Yahoo and Hewlett-Packard to an “on campus” policy.

On the flipside I can see why Apple is able to charge premium rates for products and services.  The AppleCare service representatives my wife and I talked with over the course of two weeks to resolve contact syncing issues, ICloud setup, and updating her IPhone to the new OS were impressive.  They continually pushed to ensure their systems and product issues were resolved, scheduling calls, and calling back numerous times throughout the week.   It looks like they are using consumer service as a training ground for moving to Enterprise Services.  If they make a move into enterprise services, they are likely to become the Mercedes-Benz or BMW in the market.  If Apple become the BMW of services, Amazon is likely to take on the role of Toyota or GM role, leaving Microsoft in the Ford, Nissan, or Chrysler position as it works out its ITSM issues.  Between Amazon and Apple, Microsoft is going to have a significant challenge is the services business if all they do is focus on the technology side the equation.

**yes, I event keep response records for the IT support I give my wife throughout the year and track support hours using QuickBooks -though she doesn’t get an invoice from me.  I might have to reconsider that some day 🙂

Book Review: Disciplined Entrepreneurship Bill Aulet

Given so many of my Senior Colleagues have recently separated from Microsoft and are considering their next move, I figured I would continue with my Book Club Book Review activity I was doing as part of my Community Lead Activities.  This week’s book  Disciplined Entrepreneurship by Bill Aulet.  The book is a consolidation of the lessons learned within the Center for MIT Entrepreneurship.  The book lays out 24 Steps to a Successful Startup in a style similar but not exactly like Stories that move Mountains.

 

Unlike most entrepreneur books, this one moves you away from focus on product design early.  Instead, rightfully in my opinion, Aulet has one focus on the customer.  Not with platitudes of the customer is always right or any other such tripe.  Aulet firsts asks you to identify who is your customer.  Not just a name but getting intimate with details about who s/he is; what motivates them; and what are the things you could do for them of value in their eyes.  While many consider the myth of the lone Entrepreneur pushing his/her better mousetrap into the public consciousness as the path to success; the numbers of successful businesses do not bare this out.  The majority of those that succeed focus on satisfying a customer’s need or desire.  From here you are asked to size the market based upon defining your prospective customers.  One may and are likely to have to iterate on this customer/market size equation until a viable market is defined to go after.  From this step one finally goes into defining, but only at a high level, a product concept to be validated with beachhead customers.   After this baseline is established many of the traditional techniques are put into play to define a business model (refer to Business Model Generation as an example).

Overall I give the book five stars for content, readability and applicability.

Structure in Threes: Capabilitiy Models

Most of yesterday was dedicated to continuing to fix my wife’s IPhone contacts and syncing with desktop.  By 10pm I had finally reloaded a restored copy of her contacts to both laptop and phone.  Later today its back to AppleCare to restore her apps.  Apple is still suggesting using ICloud to sync multiple devices, but at this juncture its unlikely she will trust any cloud provider.  This has taught her a lesson businesses are either about to learn the hard way or have Enterprise Architects, like myself, developing disaster contingency and continuity plans prior to jumping to the cloud:  Technology changes that you run your business on require serious change management.  And even then the a poor implementation can require many hours to recover.  Another lesson or side benefit, she’s starting to see what my career really is about: enabling others,  preventing crises, and recovering from crises.  The unfortunate thing about the Enterprise Architecture profession is that goals one and two are what enables goal three, but goal three is the only one that gets other’s attention.

This morning before jumping back on IPhone recovery, I’m reading through the COBIT 5 management guide.  It’s rather odd how most standards, processes and models now take the form of the CMMI maturity model.  While I’m a supporter of the maturity model construct it has it’s deficiencies or rather I should say poor adaptation of the concept leaves deficiencies in the applied domain.  Often I’ve seen various organizations adapt the maturity model construct for their domain of expertise but as a marketing tool to infer gaps which their product or service naturally fulfills.  However, these capabilities are often not completely filled by the product or service as the capabilities have to be built with these tools, knowledge, processes and behaviors.

The COBIT 5 generic capabilities model points to level characteristics, level generic enablers, and generic level enabler capabilities.  However, it appears the rating of conformance is a subjective exercise.  May be that is acceptable at present as this field become more defined.  However, linking performance to organizational design then become more subjective also.  It may be the design methodology I’m working on will have to include the concept of tolerance and performance ranges (similar to physical product engineering) for the results of selecting the various design attributes.  I’ll have a better handle on that when I encode the governance model into a spreadsheet and link it to the organizational design spreadsheet.  The results should give me a more robust assessment criteria as well as a diagnostic tool for clients that will guide them to a more specific areas to address rather than a shotgun approach.