Behind the title is a human

People with titles of authority (managers, VPs, CIOS, CEOs) should be respected for the risks and responsibilities they assume, decisions they need to make, and the paths they have created. But too often people who report to them forget that behind the title is a human - A real person, not just a title, who has feelings, desires, challenges, likes and dislikes, and families.

Sometimes we get too close to what we are trying to communicate that we forget that the person we are talking to (or writing to) is being pulled in many different directions. If we can eliminate distractions within our control and remember we are talking/writing to a person, we make it easier for them to absorb our message.

Update: For more on how to remove the distractions and effectively communicate technology, I invite you to join me for my IT Communication Skills Training course at http://ITCommunicationSkills.com

Essential Skills for IT personnel who want to grow

Moving forward requires growth - personal growth, professional growth, technical growth. But knowing what areas to grow in is sometimes a challenge. When appropriate, I am of the mind to ask - "What skills do I need to grow to help you (or the business) succeed?". But since that isn't always possible, I also listen when others share their insights on what skills they need. If you are a technologist, realize that the truly transferable skills of business knowledge, communication, and financial acumen are highly sought after. But don't take my word for it - read it in these Computerworld articles:

• Most Valued Skills
  
  
• Smart Career Advice

Today's issue of Computerworld contained several articles on building project management and business analysis skills. In my opinion and experience, these two skills are essential in any career path and very transferable in and out of the technology world.

SLAs can improve IT/Business Alignment

Service Level Agreements (SLAs) between IT organizations and vendors help ensure expectations are clearly communicated and service delivery meets expectations. Instituting SLAs between supported business areas and the IT organization can also help improve IT/Business Alignment. While it takes time to sit down and discuss (and document) the expectations, it gives everyone a common frame of reference on which to move forward.

A couple points to consider:

• Adapt your SLA discussions to meet the business' culture. Some cultures are not condusive to a formal SLA process. Even if you don't put formal SLAs in place, having the conversations around expectations is beneficial.
  
  
• Document SLA discussions - Even it you don't formally institute SLAs, the process of initiating conversations and discussing expectations still opens up avenues of communication and creates bridges and alignment.
  
  
• Keep discussions positive and service oriented - create win-win for both the business and IT. Discussions should not be "us" and "them" type discussions. Instead, it should be "how can we best serve your needs" type discussions.
  
  
• Be accountable to what the business considers important. Track your statistics and progress against the SLAs. (Or, if you don't put formal SLAs in place, you at least now know what is important to the business and what they would consider credible statistics in which to measure how IT is really doing.

IT is so often only remembered when there is a problem. Understanding expectations and reporting your progress against those statistics goes a long way towards building trust and credibility with the business.

For more questions to ask during the SLA process, see this Computerworld article by Steve Case.

Defining Requirements and Selecting Vendors

Rick Proctor, VP of IT at Thomas Nelson Publishers, Inc. reminds us that it is our responsibility to help the business clearly define their requirements and to really understand what a vendor's solution can (and cannot) do before implementing the solution. His advice is one of communication and how essential it is to clearly communicate not only with the business but also with the vendors.

For more on the importance of communicating with vendors and understanding business need, check out this Computerworld article about working with vendors. I worked with Loreen for over three years; she is amazing at setting expectations and communicating with staff, the business and vendors.

Lessons in Business Continuity

This morning, I am again reminded the importance of back-ups. I went to retrieve some files from my old laptop, only to discover that they were corrupted during the last operating system upgrade. Thankfully, I ensured that I had a backup before I did the upgrade (Murphy's Law!!) and was able to pull the files from the backup CD.

Doing back-ups and having a Business Continuity/Disaster Recovery plan seem like a no brainers - but then why are they so often not where dollars are spent in an IT organization?

Only when the benefits or the consequences (aka Risks) of not having a backup or business continuity plan becomes clear, does buy-in happen. Unfortunately, it takes time (and funding) to pull together a truely workable and effective business continuity plan. And it takes time to achieve corporate buy-in that time and money be spent in this area.

How can you accelerate the buy-in process?

A couple ideas:

• Identify areas of risk to the business.

  For example, what is the impact to the business if the ability to recieve orders via EDI is cut off?

  What is the impact to the business if the building floods and the servers that maintain inventory and distribution counts are cut unavailable?
  

• Identify solutions that can be implemented in a multi-step fashion focusing on the highest return with the lowest outlay ('the low hanging fruit')

  
  

• Pitch your ideas laterally as well as upward, create buyin by focusing on how the business will be positively affected. I.e., avoid focusing doomsday, catestrophic events but instead focus on real-world everyday possibilities.

Business continuity is a huge topic which I could write on for days, but in reality what I write isn't important - what's important is how you present your proposals and your ability to gain approval for business critical solutions (even if the business doesn't recognize their criticality.)

Selling Your Proposal - Achieving Buy-in

Michael Hyatt's post on How to Sell Your Boss is a wonderful primer on how to achieve upward buy-in. If you are interested in gaining executive insight on how to achieve buy-in - READ THIS.

Features vs. Benefits - Another view

Michael Fortin offers a more in depth definition of how to determine the difference between features and benefits.

Features vs. Benefits

Are you highlighting the features or the benefits?

A feature is what it does.

A benefit is the result.

For example, What's unique about a PDA contacts list? For the product I'm currently writing about - it's the 'time bomb' feature. The contacts list self-destructs if it isn't synched to the enterprise database within a given period of time. Cool - but why?

The result is that sales people cannot (easily) take the contacts list with them, when they leave the company. The benefit is that the software safeguards the company's sales contact information (intellectual property).

David Garfinkel provides a good example of this using a fan analogy in his post on Tuesday.

While all the fuss between features and benefits usually has to do with sales and marketing products, the techniques also work for internal documentation, user documentation, and management reports. After all, achieving buy-in is about getting users and management to agree to use or endorse the technology you have in place or in the solutions you are proposing.

Asset or Liability?

Is Information Technology an asset or a liability? Is it a unavoidable cost of doing business in the 21st century or is it a business enabler improving the business' bottom line?

The answer to this can be swayed based on how you perceive IT and how you are communicating the value of your technology solutions.

Learn the Business

Understanding business process and how your business is using technology currently in place is one important step toward solid communication and 'right-sizing' technology solutions.

But assuming you are already doing that, let's take it one step further - How can you proactively meet your businesses technology needs?

• Read business industry publications (i.e., trade magazines and websites) - Every industry has its own set of trade publications. If you don't know what they are, search online, ask those in the business what they are reading, and/or keep your eyes out for what is showing up on people's to-do stacks and break room tables.
  
  
• Ask those working in the business what they do and take time to learn how that fits into the overall picture.
  
  
• Listen carefully and listen with the intent to absorb what they are saying - not with the intent to respond or show your expertise.

In short - Be curious, ask questions, and re-iterate (or confirm) what you hear/read.

Use Statistics to build Credibility

Statistics and numbers increase the credibility of your message - whenever possible include them.

However - be sure that you:

• Are using credible statistics, from reliable data
  
• Can show the supporting data and/or source of your statistics/numbers
  
• are comparing 'apples to apples' (i.e., relevent and comparable) information
  

Participating in benchmark studies, reading industry best practices (e.g., from Gartner or Meta), and maintaining high standards in your own record keeping of stastical data goes a long way towards providing sources of statistical data.