Section 2.6. Assessing Your Current IT Environment

2.6. Assessing Your Current IT Environment

After all is said and done, you still need to know exactly where you are today. Once you have a corporate IT strategy defined and you've gone down into the next layer and defined your priorities, you should take a step back and audit your current IT department and IT projects. Gather all the information you can on all IT projects and (ideally) pop it into a database. Be sure to include details such as the project name, project objectives (or business objective it's addressing), project length, estimated cost, project risk, and even the business benefits. If you can't define or identify one of those elements just mentioned, it should raise a red flag for you. This comprehensive inventory of IT projects gives you the big picture view and if this is the first time you've ever taken inventory of your IT projects, you might be shocked by what you see. On one hand, you might see a beautiful array of perfectly aligned IT projects…on the other hand, you might see a random assortment of projects that don't seem get you anywhere at all.

The process might seem tedious, but the results are often worth the effort. It's through this process that you often find redundancies that you might have missed before. You can see overlaps, resource conflicts, and a wealth of other information when you step up to the "40,000 foot view."

2.6.1. Evaluating Your IT Projects

There are numerous ways one can evaluate IT projects and for our purposes in this chapter, we're talking about evaluating IT projects as it relates to corporate strategy. As you're taking inventory of your IT projects, you can put each proposed or current IT project in one of three strategic buckets: supports corporate strategies, supports IT strategies, or does not support strategies. Clearly, projects that support both corporate and IT strategies (which, for your IT department, are now closely aligned or the same) are those that should continue to get the most focus and resources. Those that meet corporate but not IT strategies will be second on your list. However, if these types of projects exist, it's a good idea to step back and find out why it aligns with corporate, but not IT strategies. It's possible it was started before you aligned these goals or it's possible that it's a unique project that fits appropriately or is a pet project of a senior manager in the company. Third on your list of projects should be those that align with IT strategies but not corporate strategies. These you should take a hard look at. If it aligns with IT but not corporate, there's a strong chance the project is the wrong project. There's also an excellent chance the project will run into some sort of political problem (see Chapter 3 for more on corporate politics and projects) because top executives will be unable to rationalize or support a project that doesn't further corporate goals. Finally, at the bottom of your list are the projects that don't align with either corporate or IT strategies. The question must be asked: why on Earth are you doing this project at all? Of course, sometimes there are leftover projects that should be completed; sometimes politics are at play and it's a favorite project of someone in a powerful position. If it doesn't align and it's not a political hot potato, consider dropping it, suspending it, or finishing it up quickly (reduced scope or quality, perhaps). There are no hard and fast rules here, but clearly you can see that it's much easier to support, define, and defend projects that align, support, or even further corporate and IT strategies.

2.6.2. Categorizing Your IT Projects

There are several high-level categories you can use to look at your projects as well. When you evaluated your projects (previous section), you looked at them in terms of strategic fit with the organization. Now, you look at them from an IT perspective. While not exhaustive, here's a starter list for you to work with:

2.6.2.1. Strategic or Operational

Projects are either strategic or operational in nature. Strategic projects are those that map with the corporate and IT strategies we've been discussing. Operational projects are those that provide maintenance or utility function. Remember, a project is a one-time solution to a defined problem, but projects can address strategic or operational issues. Although a project may not be viewed as strategic, how well it's carried out can have a significant impact on the business, so all projects that are planned and implemented must be executed flawlessly. Here's an example. Suppose you've determined that three of your key network servers are too slow and don't have enough storage capacity. You've looked at the costs and various solutions and determined that in the long run, replacing those three servers with the latest models will save the company time and money by:

• Reducing or eliminating network bottlenecks (which translates into slow user response, wasted user time, and increased user frustration).

• Reducing or eliminating failures and repairs (which translates into no user response, wasted user time, and increased user frustration).

• Providing opportunities for additional storage, additional or upgraded applications (which translates into faster user response, efficient use of user time, and reduced user frustration).

Clearly, this is routine maintenance in an IT departmentmaking sure network resources meet or exceed corporate (user) needs. However, if this is implemented poorly, it might take the network down for too long during the upgrade or it could provide intermittent, unreliable service for weeks or months after the conversion. If these servers store data needed for a huge client proposal and users are either unable to get the data or not certain of the data integrity, this conversion could shift from a maintenance task to an escalated nightmare in a hurry. Though this may appear to be a normal operational issue, it may also be defined as a project because it is a onetime solution to a defined problem. Just because a project is deemed operational doesn't make it any less important. Later in this book, you'll learn the steps to take to make sure every project you undertake has a much better chance of success.

2.6.2.2. Long or Short-Term

IT projects may be long or short-term in nature, that's not news to you. However, it's often a good idea to categorize your projects by duration for several reasons. First, as you read in Chapter 1, projects with a more limited scope and a shorter duration are often more successful than longer, more complex projects. In addition, projects of short and long duration often share resources. In some cases, it's desirable to mix long and short duration projects so that you make the most efficient use of resources. Shorter projects can often be scheduled in between other tasks or projects when resources are available or are not being used at maximum capacity. While this may sound like a pie-in-the-sky concept (when compared to your every day reality), if you've taken some time to categorize projects by duration, you may just find opportunities to better utilize your limited resources. If you don't, at least you'll know exactly how much time your various projects are slated for (scheduled). Later in this book, you'll look at managing resources to maximize efficiency.

2.6.2.3. Hardware or Software

Another useful category for projects is hardware or software. Clearly some projects may fall in between and you may find additional categories in this area helpful. The point of separating hardware from software projects is simply to help you get a good feel for the types of projects you have. It's like cleaning off your desk. The amount of work hasn't changed but your ability to more quickly organize and complete your work goes up dramatically. Later in this book when we discuss project plans, we'll delineate areas where hardware project plans and software project plans may have slightly different steps involved.

2.6.2.4. Develop or Deploy

Experienced IT project managers usually recommend separating the discovery phase from the implementation phase. Another way of saying that is don't try to implement something you have yet to invent. If you have projects that are in trouble, it might be useful for you to determine if any of them have fallen victim to this type of planning. If so, these projects might do well broken into multiple projects that separate discovery (or invention) from deployment (or implementation). If you are going to upgrade your company's entire infrastructure and use a new program you're developing, which is based on a new security algorithm, you might do well to create three project plans:

• Test security algorithm

• Develop and test new program using security algorithm

• Lab test and deploy new infrastructure components

Finally, it's important to know which projects involve development effort and which involve deployment effort. When you're talking about a software project, it can be particularly useful to determine which is which. Here's an example. If you have an application that is new and you have clients willing to test it out, you may have development and deployment going on simultaneously. It might be useful to identify your development projects separate from your deployment projects. Although deployment projects may also require development, they are specifically related to deploying the application. This might include writing a custom interface to map or import client data from an old system to yours. It might involve writing code to improve the installation and configuration of your application on a variety of platforms. It could entail creating a Web interface for your application and developing a hosted application model. All of these are certainly development tasks, but they are also part of deployment. As you can see, there may not be any black and white answers here, but taking the time to classify projects can help you see what's going on in your IT department.

2.6.2.5. Project or Process

We'll mention one last categorization that might be usefuldetermining whether something requires a project or a process. It's a fundamental question that should be asked before undertaking any project and we'll give you the tools to evaluate this later in this book. However, here's a preview. A project is a solution to a stated problem. A process is a set of procedures used to address ongoing operations. Sometimes new processes are needed to address operational issues. Before jumping in and developing a whole new project plan, you should determine if the solution should be in the form of a project or a process. Projects can produce new business or operational processes, but sometimes projects have been created when a process is really all that's needed. Evaluating current and proposed projects in this light can help you avoid creating projects when a process is all that's needed.

Applying Your Knowledge

This mapping process can be a great opportunity for you to meet with people in your organization representing the various business units. As you work together to map or categorize projects, you can derive some great benefits. The opportunity to build relationships with your business unit counterparts will help you when the going gets tough (see Chapter 3 on corporate politics for more on the value of building relationships). You will also have the opportunity to learn about your company and its business from the experts in each business group. As you've read, the stats are favoring IT pros that have both IT and business experience and learning from this expert group can jump-start your understanding of the important business elements in your firm. And the reverse is also trueyour counterparts in the business units will have the opportunity to learn a bit more about IT operations. Perhaps the most powerful outcome from this type of meeting is the opportunity for business unit managers to identify IT projects that are redundant, useless, or clearly no longer needed. By working with this group to map IT projects to strategic objectives, you'll reduce (or eliminate) resistance you might otherwise encounter when suggesting scrapping (or mothballing) a project.

Once you've gained agreement on the projects that should continue, you'll need to prioritize those projects. They can be prioritized using different methods, but a good starting point is trying to determine how much each project contributes to the strategic objectives and perhaps how many strategic objectives a project addresses. You'll also need to look at other constraining factors such as how effectively projects use assigned resources or how quickly a project needs to be completed. You're bound to end up with a list of projects beyond what the company can implement or fund today or in the near future. By mapping projects to strategic objectives and prioritizing them with your business counterparts, you can make a much stronger case for funding the projects that align with strategies and get less resistance for scrapping the ones that don't align (or never made much sense in the first place).