A Business Technology Place

Classic IT Challenges – Estimating Work

This is the fourth post in a series of writings to discuss issues facing Information Technology (IT) departments. The first three challenges were project work vs production support, prioritizing work and operations vs innovation.

IT shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group. My thoughts are more around framing the problem than presenting solutions. Estimation

Challenge #4 -Estimating Work
Estimates provide the basis for developing budgets, creating timelines, and setting customer expectations. I have suggested before that estimating is the most powerful step in the software development cycle because it determines if projects are approved or rejected.

There are a couple of challenges with estimating work. The first is that despite processes that call for initial estimates and then re-estimates when more requirements are defined, most of the important decisions are based on the high-level estimates. Project budgets, timelines, chargebacks, and approvals are most often formed at the beginning of a project and often before the requirements are truly understood.

The second challenge is trying to keep the amount of time spent on an estimate within reason and to keep the time spent on the estimate from impacting active work. Creating an estimate requires time from an analyst. So there is a cost! Organizations should be mindful of this because spending money on a project that is not yet active or approved lengthens the the time to recognize return on the investment and it could possibly take people away from working projects that are already approved.

Example 1
A team receives a high level description of a project and is asked to provide an estimate. A timeline is built from the estimate and shows a final delivery in 90 days. 15 days into the project a discovery is made that two systems are not compatible and that a major assumption about equipment availability is not true. The new information will require an additional 30 days on the project timeline. How does the team and react to this information? Is the budget revised? Is the timeline revised?

Example 2
A portfolio management organization has five active projects. Three new project requests arrive. The same people working on the five active projects are the estimators for the new work. If they stop work on the active projects it will create delays in the project timelines, but executive management wants estimates on the new requests to determine what to do with the requests.

The Challenge
Estimates are by definition inaccurate. Yet, important decisions are made from them. IT team members feel the pressure not to underestimate because budgets are created from the estimates and it’s hard to secure additional funding for budget overruns. But IT team members are also pressured not to overestimate because stakeholders may cancel the project, complain that estimates are unreasonable, or take the work to an outside agency. Business stakeholders want accurate estimates delivered in a timely manner and with a minimal amount of detailed project requirements.

Next Week
Challenge #5 – Understanding Project Complexity

Classic IT Challenges – Operations vs Innovation

This is the third post in a series of writings to discuss issues facing Information Technology (IT) departments. The first challenge was project work vs production support and the second challenge was prioritizing work.

IT shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group.  My thoughts are more around framing the problem than presenting solutions.

Challenge #3 – Operations vs Innovation

1916 Library Truck

1916 Library Truck – Innovation or operations?

The third challenge is based on the fundamental service expectations from management and stakeholders of the Information Technology group. Some business stakeholders primarily rely on IT to keep technology equipment operating efficiently and with high availability. I call this the operations expectation of IT. The business owner is concerned about delivering some service or product for the business, not about all the details of the equipment that make it possible. I like to think of this as the invisible part of IT. If everything is working then stakeholders don’t know the group exists. But if something is wrong then everyone knows it and IT is on point to fix it. The operations side of IT is expected to reduce or eliminate costs in the business.

But some stakeholders in the business are expected to grow the business through sales and market share. For that they often need innovative solutions. They want the IT development department to be innovative and provide new solutions that offer competitive advantages or competitive differentiators. That’s a completely different mindset and skill set from the operations teams within IT. The innovation teams are expected to grow revenue for the business.

Allocating resources within IT to support these two thoughts is a challenge because most IT shops don’t have the luxury to have dedicated personnel for each function. Even within IT development, programmers are pulled between production bug fixes (operations), new functionality, or even completely new technology platforms.

This challenge is similar to the first challenge of production support vs project work. The key difference is that the innovation expectation often takes IT into new areas where they have not previously provided service. Innovation requires IT to think about new ways of doing things rather than solving a request with existing tools.

Example 1
The IT development group has a backlog of helpdesk tickets reporting software defects and another backlog of defects discovered during QA testing. A new project request is entered by the marketing department to create a new application and is expected to grow revenue by some forecasted amount. Do the production defects or the new request receive priority?

Example 2
The IT team is three days from launching a new service for a client. The data center takes a lightning hit during a thunderstorm and several pieces of equipment are lost. Replacing the equipment will take team personnel away from the project and jeopardize a schedule overrun.

The Challenge
The immediate challenge is allocating people across operational work and new innovation. But I believe the challenge goes deeper. An operations skill set and mindset are different than an innovation mindset. Innovative individuals work with shades of grey and unknowns whereas operations individuals operate with black and whites and certainties. Innovation is open to explore. Operations minimizes risk through tight controls.

Next week
Challenge #4 – Estimating Work

Classic IT Challenges – Prioritizing Work

This is the second post in a series of writings to discuss issues facing Information Technology (IT) departments. IT shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. In my own experience, I have seen these challenges in multiple business environments. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group.  My thoughts are more around framing the problem than presenting solutions.

Challenge #2 – Prioritizing Work
The second challenge is how to prioritize work and to maintain priorities. Several years ago I wrote about different approaches to creating priority for work projects in an eCommerce Release Management post. Priorities for project work are most commonly determined by financial measures while priorities for operational support are often determined by a service level classification. Creating the initial priority for work and inserting work into an existing backlog is a difficult puzzle, but it’s one that often has a prescribed formula and in most cases is pretty straight-Priorityforward.

The more common challenge with prioritizing work is maintaining priorities so that work can be completed without creating an environment of chaos due to context switching. The implications of stopping something that is active to start something new are high. This type of work increases work-in-progress and ultimately requires longer to complete tasks since stopping and restarting activities takes time to reacclimate to the task.
Priorities are often stressed and challenged when business requests outpace the rate of work closure. So to keep active work in an active state, the IT group must often say “no” or ask to delay the start on a request.

Example 1
The IT development group has three active programming projects. They are 20%, 40%, and 60% complete. Two new requests come in the system and the stakeholders request they start immediately so they can be completed by a specific date. Some members of the steering committee favor stopping the project that is 60% complete to start one of the new projects.

Example 2
It’s Friday and a desktop engineer has four tickets to close by the end of the day to meet a service level agreement for new desktop setups. Two new tickets are entered for two employees who start work on Monday. They need computers and a phone connection by Monday at 8am. The typical SLA for a new employee setup is one week, but the hiring manager forgot to put the request in until Friday morning.

The Challenge
The obvious challenge is to how to properly sequence and complete this work. What gets priority and how does management protect resources against context switching? Often times there is a single person or single development group to complete the requests coming from different stakeholders. Neither stakeholder is happy with a delay. So it requires a balancing act and careful communication to explain the situation.

Next week
Challenge #3 – Operations vs Innovation

Classic IT Challenges – Project Work vs Production Support

Information Technology (IT) shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. In my own experience, I have seen these challenges in multiple business environments. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group.

This is the first post in a series of writings to discuss issues facing Information Technology departments. These thoughts are more around framing the problem than presenting solutions.

IT creates and maintains technology platforms.

IT creates and maintains technology platforms.

Challenge #1 – Project Work vs Production Support
The first challenge is how to concurrently allocate people for project work and production support work. Most IT shops are not blessed with a labor budget large enough to cover dedicated staff for each function. In general, production support will take precedence. At least for issues that create a system outage where orders or work is not processed. But what about production support requests for non-critical issues?

Example 1
Someone requests a modification to a report that requires a database administrator to adjust a set of SQL queries and alter the report format. The report is used internally and has been in-use for years. The new report layout is a preference of the requestor to make the output easier to read but the current report layout does not disrupt the workflow associated with the data.

At the same time the database administrator is asked to performance tune a set of queries for software code that is part of a new release.

Example 2
An inter-company department is moving to a new area of the building and creates a request to move PC equipment, configure departmental servers, and provide network connectivity.

At the same time, the infrastructure staff is asked to create and load a new test environment for the latest software program in the development area. The test environment requires network access, a web server, a database server and an application server.

The Challenge
The obvious challenge is to how to schedule these events when they require the same people and have the same requested due dates. What gets priority? At the root of this that production support requests are often unplanned or unknown until they are requested. Project work follows a more predictable request schedule because it is typically associated with a task on a project plan that is shared by the project manager.

The real puzzle is dealing with the unexpected while keeping the schedule of the known project work.

Is there some prescribed method to solve these dilemmas when they occur? Telling people there will be a delay is never an easy conversation to have. It’s a classic IT challenge. There are frameworks and processes. But each IT shop has a different amount of people and budget. So there isn’t a one-size-fits-all solution. IT staffers, management, and stakeholders must be flexible and patient.

Next week: Challenge #2 – Prioritizing Work