This is the Blog of Will Weider. This is the place where I share what I have learned through my mistakes and other crazy things in the life of a healthcare CIO.

Menu

How much time do IT folks work on projects?

I spend a lot of time analyzing how much time we spend moving forward strategic initiatives, versus support and minor enhancement work. As I have looked at our various operations over time I have found that number fluctuates between 15% and 25%. So, if you have 10 analysts in an IT department, your only getting 1.5 to 2.5 FTEs of project work. Hardly enough to accomplish a big project.

We spend a lot of time talking about how we can get that number higher. And like anything you want to improve we have to measure it. Our IT team track all of their hours so we can analyze the data.

This year we are estimating that we have the capacity to work on 100,000 hours of IT projects. But, the nature of that work is that there is a lot of inefficiencies. Folks are not on an assembly line waiting for the next part to arrive. There are a lot of stops and starts. It will be interesting to see how much project work we actually complete. I would not be surprised if it is less than 50,000 hours. I will let you know.

Post navigation

5 thoughts on “How much time do IT folks work on projects?”

Project management is a major topic of my new book. Making Information Technology Work: Maximizing the Benefits for Health Care Organizations. You can download a case study about IT project management and governance at University Hospitals in Cleveland at http://www.nyu.edu/classes/kropf

As a project manager, measuring hours on projects has always been an interest (if not requirement – for capitalization), but I’ve seen two amazing dynamics at work since implementing Scrum for our project management.

1. Developers who commit to delivering certain software functionality (projects) find a way to greatly reduce the time they are pulled into maintenance/support. This appears to be due to the public commitment, team commitment, and personal buy-in to a process that helps them succeed.

2. Committing to deliver _some_ working software within the 2 or 4 week timeboxed delivery schedule means immediate ROI on presumably the highest priority feature request. Rather than waiting for the entire 6 month project to go line before beginning to collect ROI, the company starts collecting at the end of month 1 on, say, 20% of the priority features.

My company works with a number of clients in the healthcare industry, and getting a good understanding of project capacity is probably one of the most common challenges these clients face.

Time capture is unfortunately the only way to get a good handle on this, and given the perceived negative implications of what the data can be used for, I’ve seen companies take a few different paths:

1. Ask people to only report project time (this assumes that they have a consistent definition for what a project is!). The disadvantage is that you have to make assumptions that the remaining hours are spent on operational activity, yet if the person is working a lot of overtime, what do you as the “aggregate” amount to calculate the percentage of project work?

2. Ask people to report project time in detail, but all other time as one big aggregate amount. This enables you to handle 100% time capture, but may not provide the level of detail that is desirable for understanding non-project activity utilization.

3. Capture detailed time for both project and non-project activities – this should be the most accurate approach, but as the 3rd commenter above indicated, it is also the most fraught with issues.

A few best practices apply:

a. Only ask for the level of detail in time entry that you will use for decision making.
b. Request staff to enter time in increments that are no less than a quarter of a day or two hours. That way, you should get no more than four entries for any given day.
c. Over communicate to staff what the data is (and is NOT) going to be used for
d. Demonstrate the value to staff of the data – hopefully, it will be used to enable you to justify staff augmentation, improve project prioritization approaches OR to push back on certain project requests