Information Technology

The topic of Information Technology Strategy is one that is near and dear to my heart.  In fact, I’ve harped on this subject a few times (a few posts for your reading please can be found here, here and here and you can find all posts related to the topic with this search).

Why is this topic something I think and write about often?   Because it’s one of the most important topics in business today.  I doubt there are many people who would argue that point.

Every corporate leader that I speak with agrees with me on the topic of IT Strategy….but few can really describe their IT strategy and even fewer can show a plan for implementing that strategy.  This strategic plan doesn’t have to be a huge formal document but it must address a few key questions:

1. Where is the organization going to be in the next 6, 12,18 and 24 months?  What are the short and long term goals?
2. How can IT help the organization achieve the goals described in #1 above?
3. What are your criteria for project selection and what project portfolio management techniques will you use?
4. Is your current IT organization capable of implementing your strategy?
5. How can you bring value to your clients AND your IT staff?

There are other questions that should be addressed by an IT strategy but the above will help get any organization started.

Like most other posts like this, I have an example that might help clarify the above points.

On a visit with a potential client, I was being briefed on the organization’s “big project” that they wanted my assistance with.  On the surface it seemed simple and straightforward…and it seemed like a great idea for the organization. After about an hour of discussion, I started to get the sense that this organization hadn’t clearly thought this new project through.

The new platform had the ability to consolidate the functions from three other platforms that they had already been using…but they weren’t planning on replacing those platforms. They were going to add this new platform in order to take advantage of a single piece of functionality while still running the other three platforms.

I asked them a few questions (e.g., why they were doing this, why they weren’t thinking about replacing their existing platforms, etc)…their response was “well….we already have those systems in place and we just need this one piece in place and we’ll be set”.

After a few more rounds of questions, I finally got the real answer from the group as to why they have 3 platforms that do the same thing and were going to put in another one: They had no IT Strategy.  The CIO had talked about creating a strategic plan for technology but it had been mostly talk.  Because of the lack of an IT strategy, the organization lacked any direction and any guidelines for what IT projects to take on.

We all know how this turns out.  No IT strategy, no IT project selection guidelines and no IT project measurement systems will always lead organizations to flounder around and grasp at whatever projects pop up.  They implement the ’sexy’ projects (the latest technology, etc) without any real governance on project selection.   Organizations end up with three platforms that do the same thing.

I told my potential client that I couldn’t help them with the new implementation. I turned the project down primarily because it was a bigger project than I could take on at that time but also because I didn’t believe in the project’s feasibility and usefulness.

The CIO and I had lunch a few months later to touch base and I was surprised to hear that he had stopped the project that they had spoken to me about.  He had mentioned that he was starting to see that the organization was spinning its wheels and not accomplishing much but he couldn’t understand why.  I mentioned my thoughts to him and I saw his eyes widen a bit as he realized why his team wasn’t accomplishing anything…they had no roadmap to help direct them.

He asked if I’d be interested in helping him draft an IT strategy (I said yes of course) and we setup some time to discuss the topic more in-depth. I spent the next three months helping the CIO craft an IT strategy that addressed the questions listed above.

The IT strategy that we developed has subsequently helped the organization deliver more services for less costs due to a properly thought out IT strategy.  Gone are the days of supporting multiple platforms…the IT staff has one platform and are now focused on creating innovative applications rather than integrating multiple platforms.  The IT staff has also been able to streamline operations and become more flexible. No more waiting 6 months to get a quote to an internal client for a new project….projects are quoted the same day and usually delivered within 3 months.

In addition to the ability to deliver more quickly and at lower costs, there is an additional benefit that come from thinking about question #5. When developing your IT strategy, you should always consider how to create value for your clients….but don’t overlook how you can bring value to your employees as well.   This is a key issue for any IT strategy…how can you make your organization a place where your IT staff will want to work?

Has your organization taken a good hard look at its IT Strategy?  Does your IT group know where they should be focusing their attention?  If not, you really should stop and think about developing a strategy for at least the next few years.  Without a map, you may not end up where you want to be.

If you’d like to know the answer that question, I have a new book for you to read: “Why Work Sucks” by Cali and Jody.

This book (which I haven’t started reading yet…but I plan to start soon) seems to follow the Ricardo Semler approach to organizational developing as outlined in “Maverick” and “Seven Day Weekend“.

The book introduces the concept of a Results Only Work Environment (ROWE). An excerpt from Cali and Jody’s website describes ROWE as:

In a ROWE, people are paid for a chunk of work, not for a chunk of time. This simple idea creates a workforce that is energized, focused, disciplined, and happy, and it’s already transformed the corporate work culture at Best Buy - a Fortune 100 retailer.

Their Book Page has this to add:

In a “Results-Only” company or department, employees can do whatever they want whenever they want, as long as business objectives are achieved. No more pointless meetings, racing to get in at 9:00, or begging for permission to watch your kid play soccer. No more cramming errands into the weekend, or waiting until retirement to take up your hobbies again. You make the decisions about what you do and where you do it, every minute of every day.

Results Only Work Environment’s (ROWE’s) are an ideal situation for any organization who wants their employees to truly be happy. This environment makes it OK for employees to go grab a coffee with a friend at 10AM or go run a few errands whenever they need to.

ROWE seems counter-intuitive to some people…but makes perfect sense to anyone who’s ever sat through a 8 hour day thinking about how they will get their errands accomplished for the week.

One particular area that I’m interested in exploring, and what has touched off my book idea, is integrating ROWE with a common sense approach to business.  How do we remove the layers of bureaucracy that exists in many organizations (e.g., adherence to antiquated procedures, 4 hour meetings with no outcome, etc).

Specifically, I’m interested in exploring the topic of ROWE in the IT space.  How would this type of environment work in an IT organization with the strict focus on process and procedure? How will a project based IT organization adapt to a results focused environment where people have the freedom to work when and where they want?

Look for more thoughts on these questions in the future.  Until then, read more on ROWE and Semler’s approach to organizations with the following articles.

If you’re in business today (especially in the Information Technology space), you’ve no doubt heard of the need to ‘align IT to the business’ or something similar…you may have even heard me talk about it (see here and here). The majority of my time in my consulting practice revolves around the idea of alignment and that’s also what I’ve devoted this blog to (although I sometimes ramble on about other topics). I live and breath in the space of alignment of IT and business…..and I’m always perplexed by the lack of understanding of what it truly means to align the technology of an organization with the business goals and practices of an organization.

What does alignment really mean? It’s simple (not really…but…): it means that you look at every aspect of your business to ensure that you are taking on the IT projects that will bring you the most benefit. These projects must fit into your strategic goals and must deliver value to your organization. It’s not really that simple..there are always political agendas, pet projects and personal quirks as well as other issues that creep into the equation. which complicates things.  But…for the purpose of a definition, it’ll do.

So…what does any of this have to with Information Technology Leadership? Read on and see.

With proper leadership in IT groups, and proper leadership within the organization, the act of alignment can be made much simpler. Let me ’splain.

As part of the push to align business and IT, there’s been a lot of talk of bringing ‘business savvy’ people into IT groups. To do this, organizations are sending their IT staff to business classes and MBA programs and hiring technology savvy business professionals to run IT groups. This approach is a good one because it gets your IT staff closer to the business and helps IT understand the terminology and business ’speak’ as the rest of the organization.  This approach is flawed though as it lacks the two-way communication that is required to truly align business and IT.

Training your IT staff on the business lexicon is all well and good…but what about training your non-IT staff on what the IT group does and what it can do for the organization? The current approach is one-way. It turns ‘techies’ into business people….but what about putting the onus of responsibility on both sides? Make the non-IT staff truly understand what IT is, what its capabilities are, and what they can do for the organization and you might open up the communication channels even further.

Mike Schaffner had a great quote in a recent blog post (read it here):

I once had a CEO tell me that one of the things she wanted in IT was people that “talk like us” meaning they understand business issues and can explain things in business terms

It’s great that the CEO understands that she needed to have IT people that understood business principles and the business lexicon. Wouldn’t it be just as important for that CEO and the rest of the organization to understand basic IT principles and what technology can do for them? More importantly, doesn’t it make sense to take some time to understand the people that work in IT?

Rather than making “them” (IT) talk like “us” (business people), why aren’t we looking for more of a two-way communication medium? Rather than forcing IT professionals to change, why not look at the organization as a whole and change the way it operates. Integrate the Information Technology professional into the organization so they can be involved from the start on any new projects and can quickly provide input on the best way forward.

So…you might still be asking “what does this have to do with Information Technology Leadership”. Well…this is what should be at the forefront of every IT leader in the world. Scratch that. It should be at the forefront of every leader in the business world.

Before you make IT personnel ’speak business’, why not take the time to understand what drives them? Understand why they do what they do. Most times you’ll find that IT Professionals like to solve problems using technology….which is exactly what organizations need in abundance these days. Stop forcing ‘them’ to act and speak like ‘us’ and start working together to understand what IT can do for the organization and what the organization can do with IT.

In order to “lead IT”, organizations need to look for leaders on both the IT side and business side who can bridge the gap between the two worlds and help fold IT into every aspect of the business. Bring IT into the strategic planning sessions…heck….let your IT staff take a crack at leading your strategic planning sessions. You might be surprised to find that you’ve got some very savvy folks in IT today who haven’t been given an opportunity to show their true value.

If you truly want to align IT with business, you must first lead change within the organization.  Lead the organization into a new reality and help everyone understand that IT is more than a bunch of ‘techies’…the IT group can be one of your most important assets into today’s competitive environment.

Organizations need to ensure that the proper leadership is in place within both IT and the rest of the business.  These leaders need to understand that IT and IT personnel can be a competitive advantage.  Organizations need to pull IT into the organization and make it an everyday part of business life rather than a necessary evil. To truly align IT with the business, leaders to lead the change that makes people say “I’ve got a meeting with IT tomorrow and I’m excited about what they can do for me” rather than “I’ve got a meeting with IT tomorrow and I’m not looking forward to it.”

If you didn’t believe my ramblings in “Common Sense and Technology Selection“, I’ve got a nice anecdotal (and funny) story that backs up my assertion that common sense is lacking in the technology selection process in most organizations.

Jump over to The Daily WTF and read this story….I’ll wait for you. Go.

Did you read it? It’s funny…but sad. And true. And this type of approach (selection via buzzwords) costs companies’ millions of dollars a year (if not billions).

If you didn’t read my “Common Sense and Technology Selection” article (shame on you!), here’s the process that many companies use today for selecting technology (the one that doesn’t use common sense):

1. Hear about the “latest technology” and/or hear a buzzword.
2. Think “yes…we need that….that will make everything better!”
3. Talk to a few vendors.
4. See a demo.
5. Buy the platform
6. Throw it over the wall to the technology group to implement.
7. Go look for your next buzzword.

Now…go read this passage from the the story on The Daily WTF:

The next time I met him, a scant 6 months later, he was backing into my loading dock with a truck full of brand new desktop PCs, older servers, and all manner of fancy Cisco 10/100 and Gigabit gear. “The CEO read a pamphlet about the lower total cost of ownership of thin clients. We’re rolling them out branch-by-branch now. The server and network upgrades are killing us. All these shiny new desktops are going to be coming your way now.”

In the story that is related on The Daily WTF, this particular company my 5 or 6 trips to ‘recycle’ their computer equipment. How much money do you think this cost the company? Had to be an enormous amount.

Interesting analysis today over on Jeffrey Phillips’ Thinking Faster Blog in an article titled “Productivity Barriers“.

In the article, Phillips discusses a recent newsletter from IFS (an ERP software vendor) that discussed the issues of usability of ERP systems. In the newsletter, IFS relates survey results that tried to, in Phillips’ words, understand:

…how much of a barrier the enterprise software most of us use everyday presents to becoming more productive

The research that IFS presented is quite interesting (click here to read the results on CIO.com). In addition to looking at usability, the research looked at productivity and asked questions around what factors caused a loss in productivity in the organization. The results aren’t surprising…results included things like (not in any order):

• too many emails
• too much work
• lack of clear priorities
• poor IT optimization
• too many meetings

The survey respondents were than asked to supply factors that effected their own productivity and, again, the results aren’t really that surprising…results included things such as unclear objectives, not enough resources, too many meetings, etc etc.

What I found most interesting was Phillips’ take on the root causes of the above issue. He writes:

Unclear objectives/priorities - poor management strategic direction and communication

Too many meetings - poor management skills and time management

Too much work/Lack of resources - downsizing and “doing more with less”

IT not optimized/doesn’t work the way the company works - inflexible technology supporting a business that is required to be flexible and change

So, in my simple analysis, many of the issues related to productivity have to do with clear management direction and communication, and the ability to communicate what’s important. Additionally, in today’s market, flexibility and adaptability are just as important as established processes and operational excellence, but our technology, systems and processes aren’t designed that way.

Jeffrey Phillips’ hits it on the head.

Most problems with productivity today can be traced to a few factors (at least in my experience). These are:

1. Poor Alignment of Information Technology and/or IT Process to the Business goals - If your organization needs to be flexible, don’t put in an inflexible IT system and/or IT process.
2. Reliance on formal IT process - Process is good. Process is necessary. Create process to allow for flexibility, speed and change. Most processes today in the IT world do not follow this mantra. They are created and then their creators expect people to follow them closely with no deviation and no room for change.
3. Poor Communication - Managers need to understand that in order to get the most of their teams, they need to clearly outline the responsibilities and expectations of the people in their teams. Without this clear communications, people will spend time trying to determine what they should be doing and/or who should be doing it.
4. Poor Leadership - with good leadership, an organization can overcome many things. Excellent leaders will overcome poor process (by changing the process), poor alignment (by aligning IT and business), and poor communication (by ensuring communication improves).

Phillips’ analysis of the results of the IFS study were right on the mark….or at least they match up with my own thougths

Mike Schaffner posted an interesting article titled “Hiring the Right / Wrong IT People to Achieve Alignment” in which he pointed at a recent article by Dr. George E. Strouse titled “Are You Hiring the Wrong IT Staff to Achieve Your Alignment Goals?” that appeared on CIO.com. Check both articles out.

An excerpt from Dr. Strouse’s article sum’s the topic up nicely:

The real problem underlying the IT business alignment conundrum is that we’re not hiring the right people in IT. The right people need strong backgrounds in both business and technology. Most IT hiring managers place too much emphasis on strong technology backgrounds.

As regular readers may know, I’ve written about this topic a few times (see here, here and here for a few samples).

I’ve spent a good portion of my career working with organization’s trying to align their business strategy with their technology. I’ve found is that the difference between success and failure in this activity is found within the people that the organization has hired.

The majority of these organizations who were successful had employees within the IT organization that could ’speak’ to the business side of the company. The IT group wasn’t strictly technologists…they were technologists with business backgrounds. Those organizations that struggled with aligning their technology with their business goals were the ones that placed an emphasis on technology knowledge over business knowledge.

Mike Schaffner relates an interesting antecdote on this topic:

I once had a CEO tell me that one of the things she wanted in IT was people that “talk like us” meaning they understand business issues and can explain things in business terms rather than just business terms.

I’ve had similar conversations with CxO’s as well. They are tired of hearing acronyms and technology buzzwords…many just want to understand how technology can help the business achieve it’s goals.

Interesting things to think about…as are the Related Articles below. Enjoy!

One of the projects I’ve been working on over the last few months is the implementation and customization of a Content Management System (CMS). The CMS chosen by my client is Sitecore CMS, which is garnering some attention for its somewhat unique approach to the world of CMS and was recently named a “Cool Vendor” by Gartner.

Sitecore’s product is pretty interesting. It’s a .NET based product that gives you the ability to (er…forces you to) create everything from the ground up for your website. Everything is customizable…layouts, templates, everything. The product is delivered as a .NET ’solution’…in other words, you can open the ’site’ in Visual Studio and customize to your hearts content.

Personally, I like this approach because it provides a great deal of flexibility and provides developers with a way to easily ‘hook’ into a Sitecore website and customize it…..but it isn’t the right solution for every problem. If you are looking for a CMS, or just interested in CMS platforms, you should look into Sitecore. If you are looking to buy, expect to pay more than some CMS platforms and less than others
Here’s a quick Hit List that you can use to determine if Sitecore is right for your organization:

Sitecore is a good option if:

• You have a good sized website and/or many websites to host.
• You are a Microsoft shop with SQL Server, Windows Servers, etc.
• You have a development staff who are fluent with .NET (C#, ASP.NET) or are OK with paying an outside firm for this work & expertise.
• You are willing to invest in a long-term approach to migrating all your websites and web apps into a .NET environment (this gives you your biggest ROI in my opinion).
• You are OK with looking at a payback period of over 1 year. My personal opinion is Sitecore is at about 18 to 24 months or longer depending on what you spend to implement and what customization you have done.

Sitecore is probably not the best option if:

• You can’t spend much money
• Your payback period is less than a year
• You have no development staff with .NET experience nor do you want to pay for outside development
• You aren’t a Microsoft shop
• You have a few sites and don’t need .NET integration

For the developers out there…if you’re interested in jumping on a bandwagon and learning a new product, there is a tremendous need for sitecore developers in the marketplace. I’m contacted ~3 to 4 times a week for resources. You can download an ‘express‘ version from Sitecore for free (not to be used as a commercial site) and join their Developer network to jump in and start learning.

Sitecore is a good product and provides a very good ’skeleton’ for a CMS but might not be the best selection for anyone looking for a quick turn CMS and/or quick payback.

As some of you may know, I’ve talked about agile methodologies in software development in previous blog posts (see links below). The topic of Agile methods still seems to be quite hot these days and many organizations want to ‘go agile’ and many vendors sell themselves as being ‘agile’.

This is great….but many of these same organizations and vendors don’t really understand what it means to be agile and to use agile methodologies in projects. It isn’t just about having a daily scrum or developing in iterations…it also includes working with your teams and clients in a more agile way and involving those people throughout the development process. This involvement of clients is a key piece of the agile world….but some organizations just don’t get it.

I’ll use an example from my past to illustrate:

I had a vendor working for me to develop a software product. The vendor was selected based on experience, recommendations and the fact that they were user iterative development methods. I spoke to them about their iterations and methodologies and was given the rundown of how they do daily scrum meetings every morning and are very agile in their approach. This was great news to me.

The project was scoped and approved and the vendor began the development process. As part of the expectations that I set at the outset, the vendor knew that I wanted to be very involved in the iterations and they agreed to do so. The day of kick-off came and went…and then another few days went by with very little communication from the vendor (and a few emails & phone calls to the vendor from me).

A week passed with no communication….I was a little disturbed but I thought that the 4 week iterations must have the vendor extremely busy and that I’d hear from them the next week. The folloing week came and went (2 weeks since kick off) and I had heard very little from the vendor and zero insight into their progress.

During the 3rd week I was finally able to get some time with the vendor’s project manager (note to vendors: don’t ever let 3 weeks go by without speaking to your client!) and he told me that they were still in ‘definition mode’. Huh? They had the requirements for the first three iterations….why were they in ‘definition mode’? What in the heck is ‘definition mode’ anyway?

I asked the project manager what he meant by this and he said that their first ‘iteration’ was always a project definition and requirements gathering mode and then they would move into development.

I asked him to look at the scope of work and explain to me where it says that the first four weeks would be spend gathering requirements. He couldn’t find anything like that but said that it was common practice for them.

If I had the decision making powers, I would have went to another vendor…but that wasn’t my call…the decision maker liked this vendor and so we stuck with them.

After 6 months of development and many discussions about what agile/iterative methods are and questions about when I could see some output from the iterations,, we were finally able to see the ‘finished product’….and it wasn’t anything like what we asked for or needed.

My boss finally allowed me to close the door on that vendor and bring in a few software developers to tweak the product. We were able to get what we needed out of it with another two months of work.

Funny story about that vendor…they finally stopped using ‘agile’ to sell and went back to their old waterfall methods and they are doing well. They have some good people on board but they were trying to be something that they weren’t.

The point of this story? If you claim to be agile, be agile. Don’t use agile and iterative development methods as a sales tool and then try to sneak waterfall methods into the project. Truly embrace the agile methods and in turn, embrace your clients and involve them in the development process. You’ll save yourself a lot of time, money and heartache.

Oh…and if you want to use waterfall methods….go right ahead. Take the same advice to heart though and embrace your clients during the development process and your projects will turn out much better than if you try to develop in a black box.

A few more of my posts on the subject:

• Agile or Waterfall…does it matter?
• Billy McCafferty - Introduction to Scrum and Agile Development
• Agile Project Management & Product Strategy - A Case Study
• Agile Management

[tags] Agile, Iterative Development, Client Management, Project Management [/tags]