What Problem are You Trying to Solve?

The other day, I met a young entrepreneur who is just starting his company with a product that he has a great passion for and thinks will perform very well in the market (due to confidentiality, I won’t mention its name).  He was telling me all about how great it was, how he already had a sales channel set up through a friend, so on and so on….

Work Life Balance – Has Technology Helped or Hurt?

I happened upon an article on FastCompany.com which stated “30% of U.S. workers who employ technology as part of their jobs feel the need to maintain a digital link to their employer at all times.”  The article also stated, “Technology is supposed to facilitate one’s work experience, making tasks smoother and more efficient, not push work so far beyond a traditional 9-5 office-based lifestyle.”  In the end, the author concluded, ”Isn’t it time to tell your company that your life is your life, and work-based tech should be kept at work?”  So, has technology helped or hurt work life balance?

What IT Can Learn From Manufacturing

Background

A long time ago, or at least what seems like a long time ago, in the U.S., Manufacturing was King. For companies whose primary product was manufactured, manufacturing, along with finance, dominated discussions.  There was little concern for quality, cost, or customer service.  The customers would get what they got (and like it), and any additional costs incurred would simply be passed along in the price of the product.  Life was good!

Creating a Necessary Dependence – An IT Business Alignment Whitepaper

 

Over the past several months, I have written several posts about the issues facing IT Business Alignment, a need to create a dependence between IT and the Business, and an emphasis on taking a process centric approach to the issue.

I decided to consolidate that into a white paper, which is now available. 

It’s not sponsored by a large software or hardware company, but does present an approach offered by my company (New Age Technologies) to help an organization move toward IT Business Alignment by focusing on a process to be improved, then understanding how it’s infrastructure and technology can help that process.

Please feel free to leave any comments about the paper at this post, or you can email me at the address on the paper.

I hope you enjoy!

Whitepaper:  Creating a Necessary Dependence: A Process Centric Framework for IT Business Alignment

 

Thanks!

 

Glenn Whitfield

The Communication Divide Continues

 

Effective communication is critically important in any relationship, be it with your significant other, or your business partners.  This is ever so important in the IT Business relationship.  After all, if we want to improve alignment, we need to make sure we understand each other.  Despite all the efforts, the issues continue to present themselves.  A couple of examples from the past few weeks:

In a meeting with IT & operations leaders, a business unit VP was discussing how they needed to better understand the ‘workflow’ and be able to improve it.  He asked IT to help.  Since the organization had Microsoft SharePoint deployed, the IT team went back and looked at the ‘Workflow’ engine in SharePoint.  Unfortunately, the ‘workflow’ he was talking about was the process the people were using to complete their tasks.  Same word, different meanings.

A hospital scheduling organization allowed physician offices to fax orders into the system.  The orders were converted to PDF files using “Fax-o-matic” (name changed).  Indexers then labeled the orders into the email system, and linked it to the order in the scheduling system (I know, a mess, but no $$$ to change).  Hospital leadership would constantly hear of issues with the “Fax-o-matic” system.  When they approached IT, IT would say it was working fine.  To IT, “Fax-o-matic” was the creation of the PDF file from the fax.  To Hospital leadership, “Fax-o-matic” was the entire process from faxing the order to linking it to the scheduling system, as well as finding it as necessary.

Much time and effort could have been saved (as well as some nasty meetings in the case of the second example) if both parties had taken the time to understand exactly what the other was saying,  what it meant to them, and explaining what they were going to do.  If the IT group had said what it was going to look at when the meeting ended, the VP would have realized they were not on the same page.

When communicating, it is not only important that you understand what the other person is saying, but that you are sure they understand what you are saying.

Let me know your thoughts!

 

Glenn Whitfield

Want IT Business Alignment? Change Your Approach and Create a Dependence

 

What’s wrong with your approach to IT Business Alignment is your approach to IT Business Alignment. For over 30 years, organizations have been wrestling with the IT Business Alignment issue, and according to the annual Society of Information Management survey it remains a top issue today. 

Why is this so difficult to get our arms around?  I’ve written previously about how defining IT Business Alignment has been an ongoing issue, and how our organizational structures make it very challenging (here).  We have spent so much time struggling to figure out the right approach that perhaps we have lost our way.

Part of this struggle is due to the definition itself.  ITIL v3 defines Business/IT Alignment as:

An approach to the delivery of IT Services that tries to align the Activities of the IT Service provider with the needs of the Business.

The problem with this definition is it defines Business/IT Alignment as an approach. Other definitions call it an “ongoing process” (Wikipedia).  While there may be a process to achieve it, Business/IT Alignment is not an approach or process, it is an outcome.

It is the outcome of many different approaches and processes which will vary by organization and will involve varying levels of technology.  Defining it as an outcome:

IT Business Alignment is the delivery of IT Services that does align the IT activities to the needs of the business.

Now looking at it as an outcome, how do you know when you’ve achieved it?  Well, it’s just like in the movie Goldfinger, when James Bond is asked, “What do you know about gold 007?”  His response was, “I know it when I see it.”  IT Business Alignment is like this in many ways because there is no “one size fits all” solution; each organization is unique, and alignment will look different in each.  This is what makes it so challenging.  An attempt by Company B to replicate the alignment results at Company A will likely be disappointing, because Company B is different than Company A.

However, to achieve this outcome, there must be some fundamental pieces in place in order to drive the approaches to meet the outcome of IT Business Alignment.  Fundamentally, IT and Business must be dependent on each other for success, and this dependence must be mutually recognized and acted upon.

Creating this dependence starts with creating a relationship and establishing common metrics.  Many will say this already exists in their organization.  Before you do, ask if the actions back it up?  Remember, not only does the dependence need to be recognized, but it must be acted upon.

 One way to act is to take the initiative to engage with the business in helping improve their operation.  This is where taking a process based focus to the operation can provide real benefit.  Using techniques like Business Process Management, or the one we’ve developed like the IT2x Framework^SM, can help IT and Business create the necessary dependence and become aligned.

Once aligned, continue to move IT and the business closer.  Whether you call this Synchronization, Convergence, or Fusion, doesn’t matter.  What does matter is the continuous process of moving toward these goals. 

Change your approach to IT Business Alignment.  Stop treating it as an approach, and start looking at it as an outcome.  Then act toward achieving this outcome, by creating a dependence on each other through relationships, common metrics, and a process centric approach to improving operations. 

Let me know your thoughts!

 

Glenn Whitfield

 

 

 

 

CIO? No, Leader Wanted

 

Change.  That is the overriding theme of today.  So that got me thinking about the relationship between IT and Business, the classic IT and Business Alignment problem, and how “everyone” is always promoting that it must change.  After all, it’s been an issue for like, well, forever.

 

CEOs are always saying they need their IT organizations to understand the business to be aligned, synchronized, converged, or whatever.  They want the CIO to understand the ‘business’.  If this is the case, when looking for a CIO, why do organizations tend to look only at those who have worked exclusively, or primarily in technology?  Sure, the person has to have some level of understanding about technology, but does the CIO really need to know every detail of C#, Visual Basic, or Java?

 

I recently had a conversation with ‘Jack’, a CFO of a Fortune 1000 organization who was sharing a conversation he had with a friend of his, ‘Mark’ – a Fortune 500 CEO.  Mark was having issues getting value and alignment out of his IT organization and was considering outsourcing the group.  Jack told him, “Before you do that, you need to make sure you have the right leader in that position – someone who understands the big picture.”

 

Every organization is different – just ask them.  Maybe it’s time to do something different.  Remember the classic definition of insanity: Keep doing the same thing but expect a different result.  Seems to me that if you truly want to change the way IT functions in the organization, looking outside the technology sandbox for a leader might not be a bad idea.

 

Let me know your thoughts!

 

Glenn Whitfield 

Process Improvement – Been there, done that. Have you Really?

 

A couple of weeks ago, I had the opportunity to sit on a panel to discuss IT Alignment with Operational Goals in the Healthcare community.  It was a lively discussion with several great opinions.  What bothered me was the conversation the evening before the event at a dinner for the panelists and sponsors.

At the dinner, I was conversing with a CTO and we were discussing the “stimulus” package.  He was ecstatic over how much money would be heading his way and how this would help him and his budget problems, and how he could help more patients.  I acknowledged helping more patients is great, but maybe he should take a focused look at his processes first to see what he can gain there and to make sure he is not spending money on bad processes.  I said, “As the saying goes, if you have a mess and you automate it, when you’re done all you have is an automated mess.”  He looked at me like I had horns coming out of my head!  He then politely said, “Oh, we’ve already done that.”   Our conversation was interrupted before we could continue.

What worries me is the “we don’t have that problem” attitude.  I have dealt with his organization.  He DOES have that problem.  He just can’t see it. They had done a re-engineering project several years ago, and had some success in several areas.  They thought they were doing process improvement.  They may have done process improvement, but they were a long way from continuous improvement.

There are two important things to remember when starting a process/continuous improvement program:

1)      To get the full impact, it must be a continuous process.  You can never think you are done improving.

2)      Leadership must get “boots on the ground” and see how the processes are being executed.  They must ask questions and get engaged.

There’s a lot more, but without these, you will not get the full, sustained impact of a continuous improvement program.

So how do you know you truly have a continuous improvement program?  – When you stop calling it a “continuous improvement program.”  And then, when someone from outside the organization comments on what a great CI program you have, your response is, “Oh, I hadn’t noticed – that’s just the way we do things here.”

 

Glenn Whitfield

What IT Business Alignment Isn't

 

I’ve been doing a lot of research over the past few months on the classic IT Business Alignment issue, and am putting the final touches on a white paper that will offer a definition of IT Business Alignment and present a framework for how an organization can start toward the goal of achieving better alignment.  Until then, I want to briefly talk about what IT Business Alignment isn’t.

While reading CIO magazine the other day (yes, the actual print edition), I came across one of those sponsored ads that looks like an article – “An IT Focus on Process”.  The ad-article immediately caught my attention due to my focus on process and process improvement.  As I read, I’m thinking there’s some pretty good stuff here – a focus on structure processes, need for organizational alignment – then it came.  The hook, the savior, the thing you need to achieve IT Business Alignment:  Software.  Yep, buy our software because it does all these great things that will allow you to achieve IT Business Alignment. 

Whether or not the software actually does these things I don’t know.  It may be the greatest software ever written.  But IT Business Alignment isn’t software.  If buying software is all we need to do to achieve IT Business alignment, why is it still a problem after 30+ years?

Companies are constantly pushing for the one thing that will enable an organization to achieve alignment – maybe that is why the issue has, in some circles, become stale.  People go off, buy the software, install it, and then wonder why they aren’t magically aligned.  They focus on the technology, maybe glance at the process, are blind to the people and wonder why things don’t go as planned.  How about a new approach: Focus on the process while engaging and involving the people to prepare for the technology.

Why not give it a shot?

Let me know your thoughts!

 

Glenn Whitfield

IT Project or Business Project?

100% of IT projects fail.

OK, maybe it’s not all of them, but everyone can agree the percentage is larger than anyone connected with the process would want to see.  While there has been much research on this, with case studies, methodologies and frameworks developed to help an organization be successful at implementing a project; one reason that often goes unnoticed is how the project is defined from the very beginning.  Is it really an IT project, or is it a Business Project that involves IT?

Now, before you go off and say, “Well, every project is a business project,” let’s set up some parameters for this discussion.  We’ll use the traditional paradigm in an organization that IT is a department, and anything that involves technology will be led by the IT department (PMO, etc.).

The way it traditionally works is the organization decides it wants to install a new system to help it improve a particular Business area (doesn’t matter if it was initiated by IT or the Business area), then, once approved, a project manager from IT is assigned to lead the project.  There is probably a “champion” from the Business area (likely a VP), and there may, or may not be dedicated resources allocated from the Business area.  If a resource is dedicated, it’s usually someone who “has the time.”  So, off the organization goes with its latest “IT Project.”  The IT PMO leader reports out to the “steering committee” that has been set up to oversee all IT Projects.  As time goes by, hiccups happen, setbacks occur, and the IT project manager is answering to all of the issues the project is having.  When it is “finally” implemented, it doesn’t work as expected, and is usually deemed another failure (the degree of which varies).  Who catches the ire of management, well, IT of course.  After all, they were the ones who were responsible to manage and implement the project.  So, IT leadership huddles up and tries to come up with a new project management approach, or technique to manage their “IT Projects.”  And the cycle repeats again and again and again.

Why does this happen?  Because we define every project that deals with technology as an IT project, and then try to manage and lead it accordingly.  And we fail.  So, what should we do?  The first step is to determine if we have an IT project, or a Business Project that involves technology.  This is done by determining who will get the greatest benefit or impact from implementing the project as the organization measures itself.  If the organization is installing a new finance system, then although the whole company can benefit from this, the greatest impact on the business processes is probably in the finance department.  Therefore, someone from the Finance team should lead the project day to day (with project management support from IT).  Likewise, if it’s a server virtualization project, then, although virtualization will benefit the entire organization, the business process impact is in the IT department; so this should be led by IT.

To improve your chances of success, identify the true project owner – who is impacted most, and who gets the most benefit, then select the project leader from that area.  This is a great opportunity for an up and coming leader to show their stuff!  Give them the proper support (like PM from IT experts) and authority they need, and let them get to work.

You will be amazed at the results.