B2B/B2C online strategy and enterprise eBusiness blog

As I’ve transitioned from the marketing department as a web marketing manager to the IT department as an application/development manager, to my now current role of senior IT manager, I’ve gradually moved up the food chain of strategy conversations with both the internal business, customers, and vendors. The constant theme in all of these discussions whenever IT is brought up? Resources (or lack thereof) and the roadblock IT is viewed as to growing the business.

Is every IT department eternally busy?

I don’t understand it. Well, actually, I do, but I’ll say “I don’t understand” just to make it sound like I’m in more disbelief than I really am. The underlying theme of every conversation I’ve had with a customer, vendor, or otherwise is that IT is busy and doesn’t have the resources. It seems as if any project requiring IT resources automatically gets held up in the “IT vortex” of priorities. IT departments are really not this busy.

The IT prioritization issue

Something is fundamentally wrong when IT resources are scheduled 9-12 months out. My gut feel is that what the business is being held responsible to do compared to what IT is being scheduled to do is at times, misaligned. This is not necessarily the fault of IT but rather the business leaders (in which IT should have a seat at the table).

From an operations and manufacturing perspective, we automatically know that it’s standard procedure to have a lengthy-but-calculated process for launching new products to the market. Yet, there’s perhaps somewhat less frustration with operations & manufacturing on these timelines compared to the frustration I commonly witness with IT scheduling. How can this be?

The business doesn’t understand IT

Business users simply don’t understand what they can’t see. Operations and manufacturing have the luxury of producing physical products and business users can see the progress of this development and can visually comprehend the effort that’s put into a product launch.

The challenge for IT leaders is to visualize the various IT processes, illustrate how they plug into the rest of the organization, and be viewed as an ally to projects and not a barrier to entry. It pains me to think how many projects are killed in the course of 12 months because IT resources are required.

Business users need a scorecard for IT projects

Business users need help — they can’t be faulted for not understanding IT, their lack of understanding is on the shoulders of IT leaders. Business users need a scorecard to appropriately rate their projects. There will be some things that internal IT cannot do in the amount of time required. But this doesn’t mean “kill the project!” It may mean outsourcing the project to another firm under the guidance of IT.

Unfortunately, many IT shops are one of the following:

• Run as if all IT-related ideas should be their own. This translates to extended timelines and lost time-to-market as IT puts the stops on a project because it wasn’t “their idea.”
• Operated under the watchful eye of a CFO. This translates to IT operating under the perception that “spending money = bad”.

What’s an IT leader to do?

1. Openly share your project pipeline (disguising projects that are sensitive, if necessary). The business as a whole needs to understand what projects are in the pipeline. If they don’t, they will approach you without any context to why your team is so busy — which is a problem.
2. Openly share the methodology for prioritizing projects with the business users who are submitting the requests. This will help them understand the process so that when they come to you with future projects, they will be armed the right data…and not with a preconceived notion that the project will “take a while” because “IT is always busy.” Knowing the “why” behind project prioritization goes a long way.
3. Accept the fact that you are not all-knowing. It’s OK for business users to come to IT with a new idea. You’re responsibility is leveraging technology to solve business problems and bringing their idea to life. Without you, it’s just an unrealized idea.
4. Spending money is not a bad thing. If you report to the CFO, the CFO is not against spending money. The CFO views business differently and is looking at the return on investment (ROI). If you cannot put in requests for money which outline the ROI, then be prepared to have many of your projects denied.
5. Don’t forget to position yourself as a “go to” person.

I’m a frequent reader of CIO.com articles — such an invaluable source for eBusiness managers and directors. I’m a big proponent of open source and am finding it to be such a taboo subject within the enterprise. In the article The Challenge of Open Source Presents to CIOs, open source is almost presented as a “problem.” So much of a problem in fact that certain enterprises ban it entirely.

Quick question: Since when it is a bad thing to save money?

Now, I understand it can present challenges from governing the use of open source as it pertains to compliancy issues. However, this is no different than governing the proper licensing of Microsoft products, too. The fact that it’s open source doesn’t make open source a “problem.” If you have problem governing open source utilization, then you have a larger software/infrastructure governance problem.

I recently came across an article that really hit home for me. It’s titled “How to determine if you delegate enough.” To quote the article:

How do I know when I am delegating enough? I think that the answer is very simple: You are not delegating enough if the questions that you are getting are easy for you to answer.

If your subordinate comes to you with an easy question … the possibility is that the answer was indeed simple but you didn’t share the necessary information, requiring the subordinate to ask the question. This may mean you retain some information in order to feel that you have not lost control, but it causes your people to be frustrated and to feel that you don’t trust them. It’s important for you to disclose to your subordinates all of the information that they need to do their jobs.

Shifting from “doer” to manager & avoiding “doing nothing” as a manager

In my recent role change, I’m now managing a larger range of projects and a larger group of people. I’ve always admired managers and executives who could get their hands dirty. I think this garners respect and establishes credibility with any manager. In this new role, my biggest challenge is identifying the tasks to take on myself and to delegate to my staff. While there are many simple projects and tasks I am perfectly capable of handling without the help of my staff, I need to be able to identify which tasks make the most sense for me to be focusing my time on.

Enter RescueTime - How I measure where I’m spending my time

I recently came across a new free service called RescueTime. It’s a web-based service with Mac and PC “listeners” that install quickly and effortlessly so I can monitor my application usage and website visits. The benefit here is that my “doer” tasks vs. my “management” tasks are clearly divided between the websites and applications I use:

• For example: firing up the Mac OS Terminal app and hopping on a server to move some files around is clearly a “doer” role. I file the “Terminal” app as a “development” task/app.
• On the other hand, reviewing Omniture web analytics data is most definitely a web marketing role, so I flag all Omniture sites as “web marketing” tasks.
• Email, Excel, Visio, Microsoft Projects are all tagged as “eBusiness” applications.

The RescueTime Dashboard

Since I have a dedicated laptop specifically for work, the only time I really use it is for work-based functions. Since the RescueTime “listeners” time out after 2 minutes of inactivity, the service provides a very accurate portrayal of the true time spent working (for me, at least). Of course, when I’m in meetings and the laptop is idle, this “work time” is not captured. Since the majority of my job involves a computer, it’s pretty safe to say that it captures most of my work-related activities on any given day:

Below we see (for the week of March 30th) I spent 55 hrs and 50 minutes working.

Below we see how my 55 hrs and 50 minutes that week broke down into the “tagged” sites and applications I used:

RescueTime then tells me how efficient I’ve been based on the above data collection and my account settings (I rate “ebusiness” as more efficient than “development”):

I’m still spending too much time “doing” and not delegating

When logged into the RescueTime dashboard, you can hover over the above red bars to see the total time spent on the tags. “development” was comprised of more than 11 hours of work. That’s 20% of time dedicated to “doing” which is much too high. RescueTime has also calculated my efficiency. Efficiency is described as:

A score based on the ratio of productive activity to distracting activity. To improve this, spend a higher percentage of time on productive tasks.

Without the RescueTime software and web service, I’d have no way of quantifying this information other than going by gut feel.  Now that I know I’m spending too much time, I am not worrying as much about being perceived as a manager who doesn’t like getting their hands dirty. RescueTime is enabling me to focus on more accurately managing and delegating the tasks and projects for my staff.

Recently, a post on the CIO advice and opinion forum posed the question about working your way up the IT food chain. This made me think more about advice for IT, developers, and general “tech” people and how they can break the mold of IT and advance up the department ladder. Some developers or engineers find themselves working for managers who “have no clue.” What they don’t realize is the managers have the ability to work with internal stakeholders effectively and translate business problems into requirements for the technical team to implement.

Here are some examples of how you can position yourself more effectively with other departments in your organization so they look at you as the “go to” person not by just the title on your business card, but by the value you bring to their business functions.

The title on your business card defines what you do, not how you do it
The title on your business card does not always mean you are viewed as the “go to” person for your functional area — I have experienced plenty of people in business who are avoided at all costs due to lack of strategic and/or big picture thinking within an organization or on a project. Your title defines what you do, but how you go about doing it is another game completely.

In IT, understanding the needs of another department is extremely important when they come to you with a question or request. Nobody likes feeling stupid, and this is one area where IT typically falls short — fail to understand the problem, provide short, non-descriptive answers to questions, and allow the uneducated business person to craft the design requirements for a (web) project that makes little sense. This then results in an application or solution that underdelivers due to poor planning and creates a customer (the employee in the other department) who is unhappy.

Picture yourself bringing your car to a mechanic for service…how do you want to be treated?
(This is often times an easy analogy to make, so if you already understand cars, then pick another area where you are not as knowledgeable in and put yourself in the position of that customer.) You drive your car into the shop — it’s vibrating whenever you “drive it” and you obviously want it fixed because A.) it’s annoying and B.) it seems very unsafe!

Now, there are two ways to approach this: probe deeper, ask questions to help you navigate the troubleshooting process with the customer face-to-face, or take the car and run a series of tests that run the risk of looking at an area of the car that is not broken (and in the end not be able to find anything wrong — we’ve all experienced this, and it’s frustrating!). Vibration in a car can be a number of things — bad brakes, unbalanced tires, unbalanced driveshaft — the list goes on, and can be varying degrees of technical explanation depending on the customer’s expertise on the matter. A “go to” person asks questions because they genuinely want to help.

Sometimes the problem described is not the source of the problem at all
Odds are the customer doesn’t know exactly what the problem is, but they may suggest a fix because they don’t want to appear stupid in front of you. This happens countless times in business! They could say “the tires feel out of balance” but in reality, it could be that the vibration only occurs during braking, which generally points to warped brake rotors (among other things). Being the responsible businessperson you are, you would always start this process by going back a step or two to understand the customer’s needs and a description of the problem.

This will ultimately lead to a more accurate and timely resolution to a problem and a solution that hits the nail on the head. Part of being the “go to” person is providing that guidance that other departments lack — knowing they can come to you with an idea and you can help them make the most of it without making them look incompetent is critical in business. You will turn them into repeat customers.

Your customers (fellow employees) don’t really care about your deadlines
Another problem area in IT is the ability to turn on a dime or the tendency to paint a dreary picture from a resource standpoint. Just like bringing your car to the shop, you don’t really care to hear about all of the other work the shop has queued up, so spare your own internal customers (fellow employees) the details. Explain that you want to help them, understand their timeline, and fit their project into the mix where you can. If you make other departments feel like you’re doing them a favor for every request they come to you with and that it feels like pulling teeth just to get some time, you will lose your position as the “go to” person. Likely, they will look elsewhere or even outsource — at which point you’re cut out of the process completely.

A “go to” person follows up.
Ever brought your car to a mechanic, the expected due date comes and goes, and you never hear from the service manager? Avoid this situation at all costs. Manage your customer’s expectations, and provide reasons for why you’re going to be later than promised. Things happen, deadlines change, but how you manage the situation will also improve the satisfaction and perceived value you bring to a project and will ultimately paint you as a “go to” person. The “go to” person gets things done and follows up when they have or haven’t been accomplished. It’s just that simple.

Work through the process and/or problem, don’t work around it or point fingers
Many times IT is looked at for solutions to sharing data or information with other internal departments or external customers. This often times means creating a new process for the application or implementation you’re building on behalf of a department. If the success of your project implementation depends on the actions of another person or department, then work with them until their job is finished. Unless explicitly told to do so, don’t “pass the buck” and assume your work is done when another department has to get involved. Part of being a “go to” person is finding the answers to problems that are outside of your current knowledge or your functional area’s expertise.

Your internal customers may not realize the amount of collaboration involved, so don’t hesitate to give them a high-level (notice the phrase “high level” — avoid the technical details!) overview of what’s being done throughout the project. This is what will make them look to you in the future for other projects and view you as a “go to” person.

I’ve come across a few posts lately as well as some confusion (in the office and in blogs) about the roles and responsibilities of the CIO (Chief Information Officer). A CIO is not “the computer guy,” “web guy,” or “a techie.” A CIO essentially bridges the communication barrier, knowledge, and strategic gap between the many departments of a business that require technology (whether they realize it or not) to solve business problems.

Big-picture thinking
The CIO is a strategic position because it requires big-picture thinking, and the ability to quickly and effectively identify broken processes (or lack thereof) where technology can be integrated to improve efficiency and the bottom line — or better yet, drive new business and capture market share. Driving new business and capturing market share is really a critical area where a CIO can contribute — because it requires a heavy dose of business intelligence and market awareness.

But I thought the CIO was the head of the IT department?
The IT department is an operational entity, responsible for executing the support of the daily technical needs of employees, implementing new technology as a result of a business need, or implementing/building new services as a result of a business need. IT still needs the “business need” delivered to them as well as an operational manager who manages the department. Depending on the size of the organization, there may be multiple operational managers within the various divisions of IT. The CIO will guide the functional managers in IT to implement solutions that satisfy current and future business needs/problems.

Why don’t other departments just talk to the operational manager(s) of IT?
Typically, departments (marketing, HR, Finance, engineering, etc.), lack the technical expertise to be able to identify exactly what they need to solve their problem. IT can normally listen to these problems and provide a very specific solution. The problem is when these solutions are implemented in silos. Over time, you have many “one-off” IT projects, built as temporary fixes or workarounds that gradually grow into a substantial maintenance burden and waste of IT resources.

This is where a CIO-role plays a strategic role. The CIO has visibility to multiple departments and layers of the organization. The CIO thinks about all of the needs of the various departments, takes future needs into consideration, and plans for scalability. The “silo effect” is neither fun or fair to anybody in IT and as a company grows, managing all of these silos because cumbersome and uninspiring — and costly. To undo years and years of silo’d development is usually a major undertaking.

Alright, so the CIO doesn’t manage the IT employees. What is the CIO involved in, then?
To quote an excellent editor’s note from InformationWeek, “CIOs are less involved in day-to-day operations and technology implementation and more involved in business strategy, revenue generation, business-process management, and customer relations.” This article was written in July 2004 and still holds true today. The only addition I would make is that the CIO is also heavily involved in online strategy because it is such a critical customer touch-point and is a major source of revenue generation (directly via e-commerce or indirectly via offline sales), customer relations, and requires strategic business-process management.