Stop, Collaborate and Listen (Shareware)

 General Technology, General thoughts  Comments Off on Stop, Collaborate and Listen (Shareware)
May 102014

Starting today, I’m offering Stop, Collaborate and Listen in shareware format as a micromanual.

You’re encouraged to register, download and read the micromanual, but requested not to distribute it. If you find it useful, you’re requested to purchase it from Amazon, where the royalty will be like a colourful explosion of fireworks in the day of this most humble consultant.

If you find it really useful, you might even want to contact me to discuss how I could consult with your IT team to make it a reality for your business.

Click here to access the registration form and download.

Here’s a reminder of what Stop, Collaborate and Listen is about:

I’ve been an IT consultant for close to two decades. During that time, I’ve worked with a large number of IT departments ranging from those in small, privately held businesses through to departments servicing world-wide Fortune 500 companies. During that time I’ve seen some excellent examples of how the best IT departments and workers align to their business, but I’ve also seen what doesn’t work. Stop, Collaborate and Listen succinctly provides guidance on what to do in order to get the business/IT relationship working smoothly.

Business Talks

Nov 302010

The worst mistake we can make in IT is to become so embedded in firefighting or triage activities that we lose the ability to pull back and see the “big picture”. This is most likely to happen in a situation where there’s no encompassing strategy.

A strategy shouldn’t be about having a fine level of granularity, and often it’s the perceived need for fine detail that prevents the strategy from being developed.

However, strategy really is all about the big picture rather than the miniscule details. The miniscule details are actually important, but if you stop to focus on them in the strategy, you lose the high level overview and again become mired in the mundane.

In short, the details are the purdue of the projects that come as a result of having a well defined strategy. Indeed, to quote Oxford Dictionaries Online, a strategy is:

a plan of action designed to achieve a long-term or overall aim

No business actually succeeds without a strategy. (That’s why fancy management consultants are paid anywhere from thousands to millions of dollars to come up with mission statements and other such slogans. These in themselves may not necessarily be a statement of strategy, but the best ones will actually align with long-term strategy.) Similarly, no subset of a business will function to its full potential without a strategy.

Like so much of backup, the big problem in developing strategy within IT is that it’s not (solely) an IT function to define the strategy. When developed in isolation from the actual business strategy, SLAs and other functional requirements, an IT strategy is about as useful as a partition on a disk mirrored to another partition on the same disk. So it might loosely be a mirror, when you just look at the partition level – data that’s written to that partition is also written to another partition, but ultimately all it does is slow down the actual work, not fulfil its actual function, and fail to protect the data.

IT without a strategy is arguably better than IT with a strategy that isn’t coordinated with the business. Without a strategy at all, it’s pure reactionary, meaning IT is at least responding to of-the-moment business needs. With a strategy, but one that doesn’t align to the business needs, the IT group is:

  • Potentially spending money on unnecessary items;
  • Using staff unproductively;
  • Draining resources from work the business actually does need.

To a degree, IT strategy is a core responsibility of the CIO (or the equivalent role in a smaller company); it comes from senior management in IT liaising with the rest of the business to determine business requirements, and then liaising with staff in IT to create a targeted strategy that sees suitable staff and systems development in such a way that the business benefits. That’s not to say that the CIO has to do this in isolation. It’s also not to say that it can only be achieved as an internal discussion. Indeed, there are often benefits to involving external sources in the discussion.

Let me give you a much simpler example: in IT, I think we’ve all worked on a problem, or an issue, for an extended period of time, to the point where we finally ‘give in’, and get someone to offer their thoughts. With a fresh perspective, and not mired in the day to day aspects of the issue, it’s quite common in those situations for the person to almost instantly (or seemingly instantly) offer a clear and coherent solution. The same applies practically anywhere: look at just about any field, and if someone is stuck, the best way to find a solution is to get a bit of advice from someone who isn’t personally waist or neck deep in the issue.

I’m not saying that getting consultants in to advise on IT strategy is a magic bullet. In fact, if you take that attitude you’re just going to be milked – a consultant can’t advise blind on strategy, and any consultant who says he or she can is a flim-flam artist. Instead, clear strategy development comes from all three sections – IT, business and an external agent – working together:

Developing a StrategyThe order of the above diagram is actually important. The strategy must be driven by the business needs, which means it sits at the top of the process – if the business doesn’t drive the generation of the IT strategy, then the IT strategy isn’t effective. Both IT and the external advisor(s) will play a role of course, but they’re effectively supporting roles – they provide input to the process. IT provides input in terms of what can be done, what will require budget, what already exists, etc. The external source provides input in terms of what is best practice, what needs to be changed in terms of current processes and systems, and what needs to be removed.

When the three agents work together, true IT strategy is achieved.

So what should be the goals of an IT strategy? There’s actually only one goal:

  1. To enable the business to achieve its strategy.

Any IT strategy that doesn’t have the above as a root goal is not going to help the business. Once this is established as a goal, it’s worthwhile to consider that goals relating to say, staff development etc., are actually business goals rather than goals that should belong to any individual group.

Sometimes it’s not my problem

 Backup theory, General thoughts  Comments Off on Sometimes it’s not my problem
Feb 132010

I frequently work in support – I help a plethora of companies that have NetWorker issues, and I enjoy doing that work because it’s about fixing their issues and either getting them up and running again (if it was a serious issue), or helping them with something they’d not done before.

In short, I like helping people.

One thing I’ve occasionally heard over the years goes along the lines of:

“I don’t care whose problem it is, I want you to fix it.

This is normally directed by an exasperated IT manager at a bunch of one or more vendors/support providers during a long running issue where different groups believe that the problem originates from different locations outside of their contracted support realm. Thankfully any time I’ve been involved in this it’s been as integrated support provider who (like the customer) has been trying to get the disparate vendors to stop finger pointing. So I’ve got no doubt that there are times when people say this that it’s fully justified.

I’d like to suggest though that sometimes it’s not fully justified; sometimes it’s not my problem – sometimes it’s not someone else’s problem. Sometimes it’s your problem.

This is a bitter pill to swallow. Let me sum up where it ceases to become someone else’s problem with a mangled quote:

The joy of a cheap price will have long faded when the realisation of a poor choice sets in.

I am sorry; I’ve searched high and wide for the original form of this quote, but I’ve not been able to find the original writer, or the original exact words, so I’m hoping I haven’t stretched it too far beyond its original meaning.

So where does the above quote come into play when someone has just pulled out the “I don’t care whose problem it is, I want you to fix it” card?

It comes into play in situations where:

  1. Critical components of your production environment aren’t under a support contract. (E.g., operating systems, databases.)
  2. Staff are not sent on or otherwise given access to critically important training.
  3. Staff are assigned tasks outside of their skillset without mentoring to help them reach that point.
  4. Against all advice, a bleeding edge solution was purchased.
  5. Without checking compatibility guides, disparate software/hardware/components were purchased.

I’d argue that in each of those situations, there is a good chance that some leeway should be given when various partners and vendors start finer pointing. Let’s go through each of those items:

Critical components aren’t under a support contract

It doesn’t matter if you’ve got storage support contracts, and hardware support contracts and individual application support contracts if core components, such as operating systems don’t have support contracts. Support isn’t a “shade of grey”; it’s binary. You either have it or you don’t. Choosing not to have part of it implicitly reduces the effectiveness of other parts of it. If an application or hardware support provider says to you “we think it would be wise to escalate this to <your OS vendor> as well for their feedback”, it’s not necessarily their fault if your response is “we don’t have support for <OS>”. Even more so, if they know that there’s a known issue with the unsupported component, it’s usually unrealistic to expect them to provide a workaround/solution beyond that.

Untrained staff

This is something I make a big point on in my book, and I want to be clear that I’m not talking about magical certifications but honest to goodness training. Needless training is wasteful, but consider this: if someone is escalating issues that any person with adequate training would already know the answer to, then not sending them on training is a false economy. I.e., they spend time not knowing what to do, then they spend time escalating the issue, then they spend time working with the vendor to fix the issue. It doesn’t take many of these incidents to actually eclipse the time it would take to send them on training.

Unskilled staff

There’s an old UI and system design principle:

The system should be as simple as possible, and no simpler.

This means that the system should be designed for the target audience or users. It doesn’t mean that a nuclear power plant’s control systems should be so simple that a janitor or lunch-room worker can fully operate it. (In actual fact, when you break this rule and start designing systems to be simpler than they should be, you start making the system more complex and harder for experienced user interaction, and more susceptible to “black box” failure.)

The net result of this is that staff who are assigned particular roles either should have the skills for those roles, or have someone available to mentor them to help them get their skill levels up to the required level.

My core case in point in this is that in situations where backup administration is done by system administrators, it’s very common to see the “newbie” or the most junior person get that task. I know, I’ve been there – it’s how I started in backup.

It’s also entirely, ahem, “ass-backwards”. A junior person is least likely to understand the potentially complex interrelationships between operating systems, applications, storage systems, performance tuning and networking requirements of the average backup system. This is a natural fit for the most senior staff rather than the most junior staff.

To put it bluntly: if you put the wrong person in the job without suitable mentoring provisions in place and they make a serious mistake, it’s not their fault, nor is it the fault of your support vendors, it’s your fault.

Bleeding Edge Solutions

In any competitive bidding process, it’s highly likely that at least one solution proposed will be bleeding edge. Sometimes it will be because the only potential way of achieving everything you want to do is by going bleeding edge. Equally as often it will be because it’s a common sales strategy: sell the thing with the most shiny bits.

Bleeding edge is thusly named for a good reason: if you slip up, it’ll cut you.

Now, if you’re demanding that everyone involved in the sale of a bleeding edge solution drop the finger pointing and start resolving the issue, that’s likely to be perfectly valid. But spare a thought for vendors on the periphery who weren’t involved in the sale but somehow have to continue to support the bleeding edge solution. And spare a thought for the people who explicitly told you that it was a risky solution.

Incompatible Systems

There’s nothing wrong with having policies to, or simply deciding to purchase different components for a solution from a variety of suppliers and vendors.

However, as I mention in my book, when you do this, it pushes the onus of responsibility onto you to do one of the following:

  • Explicitly confirm compatibility of all disparate components.
  • Explicitly tell all vendors the overall solution and components to be deployed, and explicitly state that what they sell must be known to be compatible.

The enterprise IT realm in particular is not plug and play. Just because X works with Y doesn’t mean that X works with Y2, and it doesn’t mean that just because X works with Y and Y works with Z that X will work with Z as well.

Why do I care? Why should you care?

Why do I care about this, and why should you care about this? Business is evolving. It’s no longer about traditional vendor/vendee or supplier/customer relationships. It’s about building business partnerships based on trust and a mutual desire for common success. As we know from our personal lives, partnerships that are entirely one sided don’t work.

The old business model confidently maintained that “the customer is always right”. This however loses relevancy in a true partnership. In a business partnership as well as a personal one, we know that true strength comes from each side acknowledging the needs and goals of the other side and working out how to mutually satisfy those goals without detriment to either.