A Business Technology Place

Build stuff fix stuff

The daily grind of a technology professional ping pongs between two key areas: building stuff and fixing stuff. If there is one parallel between my professional work and home life it is that something always needs fixin’. It’s a constant and can contribute to anxiety, frustrations, and even anger. To me, building new things is quite a bit more fun that fixing broken things. But which activity gets more of my attention?

In the technology world broken things, or as we say production issues, most often receive top priority. If something that is supposed to work is not, then it requires immediate attention because it is disrupting the flow of business. Employees are onsite and are paid to resolve it. At home, depending on the severity of the problem, it could receive immediate attention or stay broken. Plumbing problems usually get immediate attention while a broken yard tool might stay broken.

Do it right the first time

I remember this from childhood “Do it right the first time and you won’t have to redo it”. That’s really good advice for a kid in school. I had a few projects and papers that didn’t pass the cut.  At work we often battle the constraints of time, money, and priority. We make trade-offs of building something the best way versus the fastest way versus the cheapest way. Maybe that’s the culprit behind so many software bugs and capacity failures.  But then again is there always a better way?

Who’s number 1?

When multiple things are broken at the same time which one gets fixed first?  Business leaders don’t like prioritizing work because they want to do it all right now. Often times the number one project or the number one broken problem is determined by who screams the loudest and that can change every day. I hear technology professionals complain about “changing priorities”. It can be chaotic. It’s definitely a challenge. But in my mind, it’s part of the territory with the job.  There are methods to the madness and ways to survive.

The number one thing.

Treat people with respect and communicate well. We’ll always have broken stuff. We’ll always have new things to build. Technology professionals will always hear things like “you take too long and cost too much.”

But….

To overcome this, treat people with respect by communicating early and often. Let them know that their request is important. Help them to succeed.

In the end, it’s about relationships with people. Things that need fixin’ are just details along the journey.

 

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