jump to navigation

Slices Of Apple, Part 1 July 27, 2008

Posted by Chuck Musciano in Leadership.
Tags: ,
add a comment

I beat up on Microsoft a lot (and offer praise when it is justified). In the spirit of fairness, it’s Apple’s turn, given the absolute debacle of the rollout of the iPhone 3G and related technologies.  It’s a great case study for CIOs, developers, and just about every IT person in between. Over the next few days, I’ll be extracting some lessons to be learned from Apple’s ongoing woes.

Stay Humble

Pride goes before destruction,
a haughty spirit before a fall. -Proverbs 16:18

Before dissecting the specifics of Apple’s problems, it’s important to note that they set themselves up for all the scorn and criticism they are now getting.  Apple has spent years poking at Microsoft, using every failure to highlight how great and infallible Apple products are.  Bug-free, easy to use, simple to configure, and secure, Apple has people believing that their systems and software are somehow different from every other piece of software out there.  When Apple products fail, people are astoundingly forgiving. A similar failure from a Microsoft product yields everything but torch-lit marches on Redmond. Somehow, Apple is just too cool to be wrong.

When things began to unravel, you couldn’t help but be amused as the problems began to pile up during the iPhone rollout.  For anyone who has lived through a less-than-perfect deployment of any system, big or small, it was somehow reassuring to see Apple struggle just like the rest of us.  In the end, software is software, and poor execution yields lousy results, no matter who runs the company or how fanatical the customer base becomes.

The most damaging aspect of all this is that, for the first time, Apple’s shiny reputation has been tarnished outside of the IT community.  Nerds can recount problems with Apple OS releases and other odd product failures, but for the mass of mortals who use iPods and iPhones, their infallible technology provider has stumbled, revealed to be just another purveyor of buggy, poorly tested software.  Apple couldn’t always live up to its over-hyped reputation, and that day of reckoning has finally come due.  The cost of that slip, given their previous arrogance, will be huge.

The lesson to be learned is simple: stay humble.  No matter how good your track record, you are just one project away from a similar disaster.  Lose focus for one minute and you’ll be digging out from a pile of problems.  The price of great IT execution is eternal vigilance.  No one, at any level, ever gets to let up, slip up, or give up.

When things go well, be thankful, show your appreciation to those who really enabled the success, and don’t let it go to your head.  That way, when things go poorly (and sooner or later, they will) you won’t have people rooting against you if only to reward your ego and arrogance. That’s one lesson from Apple that applies not only to project management, but to every aspect of life.

Advertisements

Is There An ROI For ROI? February 25, 2008

Posted by Chuck Musciano in Leadership.
Tags: , ,
1 comment so far

One of the mantras for effective IT management is ROI: computing the Return On Investment for a proposed IT project. If the ROI shows that the investment can be recovered in some reasonable timeframe, the project is approved.

This kind of analysis works well for tangible projects in which the return and the investment are both equally measurable. If you are replacing one piece of hardware with another, or renegotiating a service contract at a fixed price, ROI can be very helpful as part of your decision process.

In general, you can easily compute the “I” of any project. Hardware, software, service, support, consultant fees, travel costs, employee salaries: these are all easily measured and tracked.

Unfortunately, many IT projects yield an important return that is completely subjective. How do you measure the “return” on an effective disaster recovery plan? How about license compliance or endpoint security systems? In general, any project whose end result is the avoidance of an undesirable situation cannot be evaluated using ROI. Hopefully, the rest of your management team probably agrees with this and won’t ask you to try.

Other projects are more fuzzy. Projects that yield efficiency or process improvements are often subjected to misguided ROI analysis in an effort to numerically justify an essentially intangible project.

I once consulted with a firm that justified an internal portal on the grounds that implementing an internal search engine would save (literally) millions of dollars. The reasoning went like this: if every employee searches for a document once a day, and each search is just one minute faster than the old manual method, and there are 50,000 employees in the company, you can save 50,000 employee-minutes a day, or about 833 employee hours, or about 104 days of effort each day across the company. At an average salary of $20/hour, you are saving $16,640 each and every working day! With 250 working days each year, you’ll be banking $4,160,000 every year! They argued that this was actually quite low, since they really expected searches to save more than a minute each, and their average salary didn’t include benefits. They really did all this with a straight face and a big PowerPoint presentation.

I asked if they would be receiving an actual check for $4 million each year. They looked at me blankly. I asked again how they expected to account for this enormous amount of money each year. Again, blank stares. It was clear I didn’t understand their methodology (and wasn’t drinking their Kool-Aid). I stopped asking and kept working on the system.

In general, if you are attempting to do an ROI analysis, and you find yourself factoring in average salaries, or total employee time, or some similar item, just stop. The only time you can use salaries and people is if you can count the number you will be laying off as a result of the project. Headcount reduction counts toward ROI; headcount repurposing does not.

The reality of being a CIO is that we often need to assess and greenlight projects based on intuition, good business sense, and the ability to manage risk and reward. Many projects will improve employee efficiency and give time back to be used for other business purposes. Workflow, collaboration, communication, sharing: they all make a huge difference in our businesses. IT is a key enabler of all these things. They yield intangible benefits with a real impact on your business. Don’t diminish them by trying to reduce them to a simple number. The real value of these things is truly immeasurable and the benefit to your business five years from now is completely unimaginable.

Bottom line: stop looking for numbers where they don’t exist, and start unlocking value wherever you find it.

More, Better, Faster January 19, 2008

Posted by Chuck Musciano in Leadership.
Tags:
add a comment

Perception is everything.  My mentor on the operations side of this business, Bill Rauscher, long ago drilled into me that the customer’s perception is my reality.  It doesn’t matter what I know to be true; what the customer thinks is true will rule the day.  My job, in delivering good customer service, is to get the customer’s perception to more closely align with my understanding of the truth.

This was driven home to me, once again, as I considered ways to decrease the time it takes to complete projects and deliver new tools and capabilities to my customers at work.  These are internal customers; we provide tools and systems that let them do their jobs and serve our external customers better.

From the project team perspective, we make constant progress on our projects.  Concepts evolve into requirements, which drive design, which fuels development, which enables testing, which leads to deployment, which lets us declare victory and move on to the next project.

Our customer’s perspective is very different.  As we work our way through the phases of a project, their perceived value is nothing, nothing, nothing, nothing, and nothing, followed by everything when we finally deploy.  They get frustrated as time goes by with nothing delivered.  If you graph the two perception curves, it looks like this:

How do we fix this?  Traditionally, we try to accelerate the project schedule, driving the time to complete the project down and pulling in the magical deployment date.  Getting things done sooner is good, but all you’ve done is shorten the “got nothing” time that is frustrating the customer.  Moreover, there is a limit to tightening the project schedule.  At some point, you’ll be making the traditional choice between time, money, quality, or your job.

I think a better approach is to find ways to release incremental value to some customers earlier in the development cycle.  You can’t everything to everyone, but you can give some things to some people.  For that subset of customers, they are getting value earlier, and their perception of your ability to deliver goes up.  The curve becomes this:

Some would argue that the small increase in early value (the area under the curve before the final deployment) is not large enough to make a difference.  I contend that any additional value is better than none, and for the users who get that early value, their perception is that they are receiving close to 100% value that much earlier.

There are a few ways you can accomplish this.  You might develop in phases and release partial functionality as it becomes available (some value goes to everyone).  You could engage a willing pilot group to use early versions of the product, giving them value and getting great feedback in the process (all the value goes to some people).  You will most likely find some variation of these extremes, opening up some value to some people as it becomes available and they are capable of accepting it.

As always, this must be done prudently.  You can’t release poor quality stuff early, and some projects do not naturally lend themselves to an incremental release. Still, if you evaluate this approach for each of your projects, you’ll find ways to get some value out there earlier, which is more than you are delivering now.