concepts


People don’t want cheap - they want good

Posted by James Kahn on February 7, 2008 in concepts

Okay - I’ve had this one in the pipeline for some time, and Paul’s comment about me not blogging enough has got me motivated. A bit unpolished, but what the heck.

Being a pre-sales engineer, I have a constant need to justify the solutions I put forward. Customers always want to know what they’re getting for their money - as they should - and are interested in the benefits that the solution will give them. The sales guys question parts of the solution so they can understand it, and the deeply technical propellorheads ask why we don’t just use some scripts. Aside: Don’t even get me started on how many stuffed up IT environments I’ve seen where techies slapped together a few scripts where they should have got the architecture of what they’re doing right in the first place.

Undoubtedly, whoever the conversation is with, it always turns to money. People don’t want to spend more than they have to.

But they don’t want shit. They don’t want something that won’t work. They don’t want cheap. They want something that is good. Something that suits their requirements. This is an almost universal maxim. Even if someone doesn’t realise it, deep down, people want something suitable for their situation.

Let me give you an example. Living on an acreage block, I need to do a fair amount of property maintenance. A few months back I was given a near-new Ryobi Electric chainsaw (worth around $100) which I’ve been using to keep my property from turning into a jungle. It has major issues. The biggest issue is that I’m limited by the length of the power cord. It’s also not very gutsy, and the chain is a huge pain in the ass to tension. It’s impossible to do it without the bar and chain popping off, and a long string of expletives exploding from my mouth.

As I found myself battling a branch from a wattle tree the other weekend, using three extension cords, chainsaw oil started leaking out all over my hand. “This is stupid”, I thought. The chainsaw was cheap - free in this case - but it doesn’t suit my needs. At this stage I’m planning on spending around $750 to replace it with a good STIHL model. The STIHL will cost around seven times what the Ryobi costs - but I will be happier. And safer.

While I used the analogy of a chainsaw, IT Infrastructure is similar. No matter what the requirement is, there will be any number of products, solutions, or workarounds to fit the bill. Each will have different capabilities. The solution that is chosen at the end of the day should be the one that is the best fit for the business - not the cheapest.

Let me leave you with a story.

A few years back I was having a conversation with a friend in New Zealand. Ray owns a successful company that provides project managers as a resource to large corporations in NZ. We were discussing his business over a cup of coffee at Starbucks.

“Ray”, I asked, “how did you get to where you are? How did you build your business?”

“It’s not rocket science,” Ray replied. “My project managers are good, but they aren’t cheap. But people don’t want cheap - they want good“.

Change In Business

Posted by James Kahn on June 4, 2007 in concepts

Ian Blyth has a great blog post up about integrating new software or change into a business - in this instance, Systems Center Operations Manager 2007.

The five stages are essentially:

  1. The existing status quo;
  2. Resistance to change;
  3. Chaos as change occurs, knowledge is updated and people learn;
  4. Integrating the idea or software into the business processes; and,
  5. The new status quo, at a higher level of performance.

Recommended reading.

Compromising Quality for Reality

Posted by James Kahn on May 16, 2007 in concepts

If you’ve been in the IT industry for longer than a day and a half, you’ve probably had to compromise on something technical. Usually the story goes like this:

  • The customer implementing a web-based remote access solution doesn’t want to put in two-factor authentication, despite the fact it’s been proven to be exponentially more secure than a username and password.
  • The CIO decides that all user workstations will stay on Windows XP for at least another year, instead of migrating to Vista.
  • The CEO knocks back the idea for a stand-by data centre in favour of a less optimal “back up and pray” routine.
  • You work for a multi-billion dollar international company and you’ve had to cut out your number one and two features from your new virtualisation product in order to ship on time (I just had to add that one in. No hard feelings, Microsoft.).

It’s the old story - nobody seems to want to do anything properly. Can’t they just…

Woah. Hang on tiger. What does it mean to do something properly?

In the minds of most technical people, doing something properly means implementing every feature. Automating as much as possible. Installing on the best hardware. Configuring in the most secure way. For a developer, it can mean “release when it’s done”, like in the open source world. For a Systems Engineer, it can mean that a Standard Operating Environment machine builds itself, installs and configures every app, and migrates user settings automagically. Technical utopia. White marshmellow clouds, anyone?

The stunningly stark contrast to the technical mindset is the business side of the fence - dollars, and time. Can we leverage the 80/20 rule and cut some corners for most of the benefit? Will implementing this improve our profitability by reducing costs or increasing revenue? Are there other projects that will have a greater impact on the business?

The best path often lies somewhere in the middle, and this is where compromise comes in. As an advocate for whatever technical solution you’re trying to implement - whether you’re selling it to another company or to your own management - convincing the guy that makes the final decision to implement the “proper” solution won’t always happen. When you do compromise on a solution, the important part to know is not whether to compromise, but what parts you should compromise on.

So how should you go about it?

1. Make sure they know the risks

The first, and most important point to remember is this - make sure that those that make the decisions, know the risks. This goes for whether you’re working for an IT partner, internal IT, or development. Your role is to identify the risks so that the decisionmaker can make an educated decision.

For example, if you’re putting in a remote access solution, and the decisionmaker doesn’t want to spend money on two-factor authentication tokens, make sure that they understand that standard username and password authentication is susceptible to all sorts of security problems, whereas two-factor authentication is many times more secure. If they still don’t want two-factor authentication, that’s okay.

If they’ve accepted the risk of the compromise (bad pun unintentional) - that’s their decision to make. You’ve done your job by making sure that they’re aware of it, so they could make an educated decision.

2. Accept that there’s always a trade off

Many technical people get upset, angry or annoyed when someone doesn’t want to implement their full solution. I know I’ve been guilty of it at times. In our minds, the solution is appropriate, and the best to fix whatever the current problem is. Why don’t they just implement it!

Accept that there is always a trade off. Businesses only have so much money to go around, and the highest priority projects get the most attention. Much of the time the solution you’re trying to implement might be quite important, but so are half a dozen other projects that cost just as much. It’s a world of finite resources.

Something has to give - and it usually results in a compromise on your solution.

3. Holding your ground

There are some things that you should never compromise on. The school of life has shown me that if you don’t stick to your guns on these, all hell can break loose later.

You should never compromise on:

  • The project implementation process. Especially, don’t skip the design and testing phases. You’re far better to compromise on the functionality of the solution than on the process by which you implement it - you’ll end up with less functionality, but a better solution.
  • The supportability of the solution. Don’t put a rush-job, stop-gap solution in place that is unsupportable because of a lack of time. If you don’t have the time to do it right, where are you going to find the time to do it over again?
  • Your ethics. It’s not up to me to tell you what your ethics are, but if you start compromising them to cut corners - take a long, hard look at what you’re doing. “Because my boss told me so” isn’t a valid excuse.

4. And sometimes, things just suck

If you’ve explained the risks, accepted that compromises need to be made and held your ground where it counts, and you still have to compromise further - you could have a problem. Either there’s a problem with your perception of the situation, or the decisionmaker’s. Figure out how you’re going to deal with it.

Just don’t get bitter when you’re asked to compromise - everybody’s doing it.

Strategy vs Tactics

Posted by James Kahn on April 10, 2007 in concepts

The words strategy and tactics are tossed around some Dilbertised IT departments like a Management Consultant’s wet dream. Once, these words actually meant something. As much as I hate a lot of the unnecessary business buzzwords, I also hate to lose words that are actually useful, and can provide valuable insight into why we do what we do.

So what do they mean, and why the hell should you care?

By their dictionary definitions, strategy and tactics don’t sound very different. In colloquial use, they have a different spin to them. Strategy is about working towards a common, greater, usually longer-term goal. Tactics is a series of steps to solve a problem, or accomplish a direct goal. Players of chess are familiar with these terms. Strategic players tend to move all their pieces in unison according to some greater game-plan, where tactical players work on executing a series of moves.

If you start thinking about what you’re doing with your client’s or your computing infrastructure in terms of strategy versus tactics, you might be able to give a better solution.

For example:

Problem: You’re running low on disk space on the primary file server again.

The Tactical solution to the problem might be to add another disk to the file server. Problem solved.

The Strategic solution might be that you realise that it’s only been six months since you last had to add a disk to the file server. The company’s data usage is growing by 40% per year. With the help of your boss, you build a business case for a Storage Area Network that will handle the primary file server’s growth for the next five years, as well as allow you to expand your SQL Server environment. Backups during business hours with no performance impact are also a bonus. Problem solved.

Thinking strategically can be harder than thinking tactically, but you end up with a better environment at the end of the day, that services the business’s needs more appropriately. Having said that, sometimes the quickest solution is the most appropriate. You just have to judge each situation on its own merits.

When you think in this way, it becomes easier to judge if you’re doing the right thing.

By the way - I don’t play chess, I just know a few people who do.

Infrastructure Planning: The Road to Success

Posted by James Kahn on March 27, 2007 in concepts

No matter the size of the organisation, location, or the platform that you run your information systems on, eventually all companies reach the point where the current IT infrastructure doesn’t match what the rest of the business requires. At the most basic level this can be a lack of disk space on the main shared drive, or a poorly performing Exchange Server. If an organisation is growing quickly, 24/7 IT operations with fast, anywhere-access to email and applications might be required. Regardless of what the current problem is, the fact remains that IT needs to constantly change, upgrade and enhance the operating infrastructure as business needs becoming more demanding.

In my experience, most companies IT departments don’t spend enough time planning what they should do with their infrastructure and spend too much time babysitting what they’ve got when it clearly doesn’t suit. Regardless of whether IT is on the periphery of your business or is strategic to your company’s survival, IT infrastructure planning is critical. While the helpdesk driven IT department was par for the course in the 90’s, the reality in today’s knowledge-centric economy is that IT needs to stay ahead to make sure that the business isn’t hamstrung by a lack of availability or functionality.

So how should you plan your infrastructure? Start at Step 1…

1. Be A Visionary

The first step in infrastructure planning is to be a visionary by investigating new technology and determining how (and if!) it applies to your business. Being a visionary is about finding out about new technology, getting excited about it, and then getting everybody else excited about it. Being a visionary isn’t a full time position - it usually takes just a few hours each week.

Most importantly, for a visionary to be effective, you need to have direct communication and trust with the decision makers in your organisation. If you don’t - then get on board with someone who is.

2. Have A Goal

So now you’re aware of what technology is out there, and what suits your organisation. With this information in your mind and notebook, you need to build a goal that your company’s IT department can work towards. This needn’t be overly complex, flowery or utopian - simple goals are best. You’ve probably heard of the principle of low hanging fruit. The same idea applies to forming IT goals - determine what will provide the largest benefit to the business, that will most likely be the easiest to implement.

The following are some good examples of goals. They are simple to understand, and specify concrete measures:

  • To be able to withstand a full data centre outage while maintaining IT service availability.
  • To be able to build or rebuild a Standard Operating Environment PC within 30 minutes.
  • To be aware of any IT service line problem within five minutes of the problem occurring.
  • To reduce hardware dependence and costs by virtualising all Windows Servers.

Some bad examples of goals include:

  • To increase synergies by aligning efforts with business practise. (Excuse me?)
  • To upgrade all the servers. (To what? And what is the benefit?)
  • To enhance business flexibility by providing streamlined deployment services. (Sounds like a sales pitch, not a goal.)

What you need to remember about having goals in infrastructure planning is that they must apply to your business and that you must be willing to re-evaluate them if circumstances change. They’re goals, not the ten commandments.

Once again, the goals must have buy in from the decision makers for your ideas to be successful.

3. Build A Road Map

After you’ve defined your goals, you need to build a road map to achieve them.

A road map is a series of high level stepping stones to get you from where you are now, and end up where you want to be. You don’t need to get down to the nitty gritty - keep it simple, and keep it high level. The simpler the road map is, the easier it will be to communicate the road map to other people who may not be technically minded. Don’t confuse simple with easy - just because the tasks are easy to grasp, doesn’t necessarily mean that they’ll be easy to do.

If your IT goal is “to be able to build or rebuild a Standard Operating Environment PC within 30 minutes”, you might include the following steps in your roadmap:

  1. Evaluate and compare different Desktop management systems.
  2. Discover applications and hardware already present in the organisation.
  3. Compile list of standard applications.
  4. Implement Desktop management system.
  5. Build SOE and package all applications for deployment.
  6. Pilot Standard Operating Environment.
  7. Roll-out new Standard Operating Environment to all users through Desktop management system.

Depending on what your goal is, you may have completely different steps in your road map. You could have a different set of steps than I’ve got in my example for rolling out a Standard Operating Environment - that’s OK too. It’s important than your roadmap fits your situation, and your environment.

A word of caution - before you go ahead and complete your road map, you probably want to check that the vendor’s technology you’re implementing actually does what you’re investing in it for. You might want to include a proof of concept stage at the beginning of your road map, or receive a product demo from the vendor.

4. Execute The Road Map

Okay, this should be obvious. Once you’ve formed your goals and built your high level road map, what now? In the much-cliched words of Nike, just do it.

Depending on the size of your organisation and the size of the change, this could start off by buying product, forming a project or submitting a business case to the board. Whatever it is, it’s getting into action that counts. The hardest part of launching any technological change in an organisation is getting started. Once you’ve kicked off, everything else falls into place. Form your project team, build your project plan, and go for it!

5. Stop, Re-Evaluate, and Go Back to Step 2.

So now you’ve bullet-proofed your data centres, are able to deploy a new PC with the touch of a button and halved your support costs, what next? Go back and build a new set of goals! By the time you’ve finished upgrading one part of the business’ infrastructure, you’ll no doubt need to improve some other part. Information Technology in business is like The Never Ending Story - just when you think you’ve finished, requirements will change and you’ll need to augment your business’s IT infrastructure in yet another way.

That’s the fun of IT!