The answer isn’t always clear. In IT we constantly receive a broad spectrum of requests, from “I forgot my password” to “We need a new enterprise accounting system.” At the two ends of the spectrum, it’s easy to distinguish a simple service request from a project. But in between the distinction is fuzzy, and the results can be less than satisfactory if we choose the wrong approach to manage the request.
The same fuzziness can occur in almost any line of business, but I’m going to stick with IT since it’s what I know best as a retired CIO. Let’s begin with the well-established project definition and then look at ways to ensure we make the best choice.
Defining the problem
The Project Management Institute (PMI) defines a project as “a temporary endeavor undertaken to create a unique product, service, or result.” It goes on to explain what unique means and provides a few examples of projects. Then it and adds a little more detail about the temporary nature of projects and that’s where the guidance ends.
Scheduled computer replacement is an endeavor that doesn’t quite fit the PMI definition. In large organizations where hundreds of computers are scheduled for replacement as part of annual maintenance, we could take two approaches:
Use the IT ticketing system to create one service request ticket for each computer to be replaced, and manage each replacement like any other small service request.
Run the entire annual replacement cycle as a project.
Either approach makes sense if you look at it from different perspectives. That is, a computer user only cares about their computer replacement. They generally aren’t concerned about the others, whether the larger effort is on track, or how much it costs. From their perspective, a service request ticket created just for them is sufficient to coordinate the replacement.
On the other hand, the CIO and the CFO are two key stakeholders who care a lot about the overall replacement cycle performance and cost. Managers also care about the interruption to their employees’ work. And to those concerns we can add the complexity of the endeavor:
Testing and choosing compatible computer models
Bulk purchases and shipments
Temporary storage requirements
Technician scheduling
Updates to the servers that manage the computers over the network
Recycling the old computers
From this perspective, maybe it should be considered a project. The temporary nature of the project can be defined by the fiscal year, but the result isn’t really unique. It’s going to be "wash, rinse, and repeat" every year.
So in the real world…
Because there were more stakeholders than just the computer user, and the complexity of the operation was high when you looked at it from the organizational perspective, the organization that I managed chose to run the replacement service as an annual project with formal project management. This made tracking the overall progress and cost, and status reporting much easier than using our ticketing system. A subsidiary communications plan was developed, and the overall satisfaction with the service was high. Great!
Nonetheless, these gray-area service requests arose often, so we needed a simple, everyday process to determine when formal project management was necessary. Designing that process required a little more thought.
80 hours
IT service requests usually come through a ticketing system. Most requests are common issues like the password reset example above, and the ticketing system does a good job of tracking those requests. On the other hand, project management-worthy requests usually arise in personal conversations or meetings. Regardless of how requests are discovered, it’s important that all go through the same filter process to ensure they are managed appropriately. That’s why we chose to channel those in-person requests through the ticketing system as well, and the IT employee who encountered them first was responsible for creating the ticket.
Usually, the first person to review incoming tickets was not a project manager. As a result it was more likely that projects and service requests could be misclassified. So we needed an easy-to-gauge metric to cause some tickets to come under the scrutiny of a project manager, but only when it was appropriate.
We chose 80 hours as the threshold for review. Any IT employee reviewing a request for the first time could easily assess if it would require more than 80 hours of work, and route it to the Project Management Office (PMO) for final determination of the correct management approach. If the PMO determined it wasn’t a project, they reassigned it to the appropriate IT group.
This process served us well. So great, again!
Why 80?
Before we talk about the specific threshold for PMO review, we should acknowledge the alternatives. We could have chosen other triggers to branch the service request tickets to a project manager for review. For example, who submitted the request, such as an executive or manager. Or we could have created a ticket category called “Project” and let the submitter choose. But that leaves the routing determination to automation or employees at large, respectively, and both are prone to make incorrect choices. We needed a solution that was 100% accurate.
So how did we choose the 80-hours metric? We selected it for two reasons:
It’s two weeks of full-time work for one person, which is easy to conceptualize.
Formal management of projects that meet the threshold is worth the effort.
We needed to verify the second point, so we started by making some assumptions and setting limits:
We assumed endeavors that might fit the project definition, but are not managed as a project would have 15% rework, on average. This figure is conservative according to published research.
We arbitrarily set a limit that the project planning effort should not exceed 5% of the total project effort, on average.
We determined that the average effort to plan for very small projects was 4 hours. This was based on our own experience.
We assumed that projects and service requests require similar levels of effort for execution, i.e. all other management activities not including planning.
Finally, we had all the pieces of the puzzle. If you divide 4 project planning hours by 5%, you get 80 hours of total project effort. Provided that the 4 hours of planning effort is less than 15% of the 80 project hours (12 hours of rework avoided), there should be positive return on our investment in project management.
The Result
The final process was simple and effective:
All requests must go through the ticketing system, regardless of how they are discovered. The first person to discover verbal requests is responsible for creating the ticket.
The first person to review the ticket for routing purposes applies the 80-hours threshold, and routes it accordingly.
Tickets above the threshold are routed to the PMO for review to determine if formal project management is appropriate. If not, the ticket is reassigned to the appropriate IT group.
We haven’t had any substantial tweaks to the process in the 8 years it’s been running.
The key takeaway is to put some thought into creating your own dependable, easy-to-understand process for determining when it’s appropriate to apply formal project management. Hopefully this has provided examples and perspective on the problem, and kindled some ideas on how to determine when formal project management might be appropriate in your organization.
Project EMC2 can help
For small projects, it's important to be efficient in your project planning and execution to ensure that there is positive return on your decision to use formal project management. Project EMC2 is a free application designed for speed and diligence, two factors that ensure your time isn't wasted and work isn't repeated or unnecessary.
Learn more about how Project EMC2 can boost your efficiency today.