Showing posts with label broken processes. Show all posts
Showing posts with label broken processes. Show all posts

Tuesday, October 23, 2007

eWeek's Subscription Blunder


I'm not sure which genius developed the subscription process for eWeek, but I do know that they should be shot.

Today I received an email from eWeek, offering me a free subscription. Of course, the fee for subscribing is divulging information about your position, buying influence, industry and I.T. budgetary information. It takes a minute or two to complete all the questions.

I'm fine with that.

But don't position your publication as a trusted source for I.T. decision making - a source that will help me be more successful in my career, and then, within seconds of my subscription, undermine that sales pitch with a poor cross-sell.

Case in point.

No sooner had I signed up for eWeek, when I received a confirmation email and an offer to subscribe (for free) to CIO Insight and Baseline magazines, from the same publisher.

Less than 60 seconds earlier, I had just completed their subscription application and when I clicked on the subscribe button, they were asking me to provide the same information again!

With processes like these, I don't know you're going to help ME be more successful.

Any thought to a one click subsciption for other Ziff-Davis publications after I've completed the application? Or a chance to subscribe to other Z-D publications within the original subscription process?

Note to Z-D: If you're wondering why the cross-selling efforts aren't yielding the desired results, put yourself in your customers' shoes and try out the subscription process for yourself.

Thursday, August 23, 2007

Why is Saying NO so difficult?

One of the toughest challenges of any I.T. department isn't installing that complicated system, or upgrading the network or integrating that new acquisition or even Sarbanes-Oxley compliance efforts.

It's saying No (or not yet) to enhancement requests. Setting an honest expectation.

Yet without clear, concise, easily understood expectations, our business community's default expectations are "Yes". They're waiting to hear the answer to "when?"

And so it goes. Development requests come into I.T. The B/A says we'll take a look at it. And it never goes any further or the project gets estimated and added to the never ending "list". Or worse yet, the B/A makes some sort of commitment (trying to be helpful) that has little chance of being met.

The requester is disappointed (or irate) and I.T.'s reputation takes yet another hit.

Who's at fault here?

Not the business person, who is trying to improve a business function or reduce costs or service customers better. To them, why wouldn't I.T. want to get their project done? Who can argue with serving customers better or improving costs?

Not necessarily the I.T. business analyst who's listening to the request and estimating the project. After all he/she rarely has any say in how projects get prioritized. They usually aren't in the position to give a Yes or No, yet that's what is expected of them.

The process is the problem.

Imagine for a moment that your company had no I.T. function. Let's say it's 100% outsourced. (Some of you may not have to use much imagination... but I digress). If you need a system enhancement, you'd have to detail the expected benefits of the enhancement, then get the projected estimated by your outsourcer, before you'd have a complete picture of the project complexity and estimated payback. If the investment was large enough, you'd likely have to go through a capital expense procedure, where you'd take the business case to your company controller or CFO and (s)he'd make the decision whether to proceed or not.

The clear advantage to putting the decision in the hands of the Finance leaders is that;

1. They can hold the business accountable for the business case benefits. This has several advantages. Armed with the expectation that the business will be held accountable for the benefits, helps eliminate spurious "nice to have" requests. This reduces requests and related business expenses estimating projects that will never be approved by the business.

2. CFO's can make system project decisions armed with the overall business priorities perspective. Something that I.T. could seldom do.

This process turns I.T. Projects into Business projects.

Which is what they should be.

Monday, April 16, 2007

Georgia D.O.T. Not So Peachy

In yet another story of government gone terribly wrong, it was reported yesterday, that Georgia's DOT forces hybrid car owners to take emissions tests despite the fact that their testing centers aren't equipped to properly test hybrids.

Perfect.

Because the law is poorly written (probably before hybrids), DOT officials must test every car. When a Georgia resident pulls up in his or her new Prius, the local DOT actually performs what they call an "aborted test", since a) they must test and b) they can't test because the Prius doesn't idle long enough using it's gas engine before switching to electric, hence no emissions! They then follow-up the aborted test with a manually issued "waiver".

If the goal of the emissions testing program is cleaner air, they've gone horribly wrong. I fear that the tests remain mandatory because the original goal of the program has long since been obscured by the revenue the program generates ($25 per car).

Here's a wild idea; Why not give hybrid owners a break and exempt them from the testing and then raise the fees for those folks who continue to drive gasoline powered vehicles? Perhaps you could change a practice that is the source of ridicule. and turn it into a program that would help "drive" the right behaviour (pun intended) AND generate a few more bucks for your treasury.

Makes one wonder how many other government processes are broken. I shudder to think..