Names for new work

IT maintains services, and it works on new things: anything from adding a column to a report, to a tool upgrade, to a multi-million dollar data center.

Some of these new things are easy to build: one person can add a column to a report. Other new work is very difficult and risky.

Project management is a discipline for ensuring new work is completed as planned, and in many organizations project management is their only formal IT management process. Thus, many organizations call all new work “projects.”

But project management has overhead. As your project management methodology develops, and you for example require project charters for all projects, you’ll start to ask yourself, “Does it really make sense to build a charter to add a column to a report?”

Project management is an important discipline but it isn’t necessarily helpful for smaller work. I’ve said before that work should be called a project only when the project management methodology is helpful. So–what do you call the other stuff?

Here’s my two-part answer for how to approach all your new work.

First, all new work is considered a change request

Any new work should have a corresponding change request (with potential caveats for service request or low-risk maintenance work). The new work could be tiny or huge. There should exist one system of record in which all new work is documented. For example:

  • CRQ 101: Add a column to a report
  • CRQ 102: Tool X upgrade 8->9
  • CRQ 103: Build multi-million dollar data center

Why do I think all new work should have a change request? Here are three of the reasons:

  • As you learn more, the new work may need to be re-classified: for example from a small thing into a project. Using one system allows work to be re-classified more easily.
  • A service request management system can create change requests and not care what happens downstream (e.g. that the particular request is going to become a project).
  • If you can relate records together, then you can relate things to/from the change requests. For example CRQ 103 could have many related change requests for various project deliverables. CRQ 103 may also create known error records as the project identifies errors. CRQ 101 could have an incident or problem record tied to it.

This approach assumes you can then code the change requests in your tool and you have different “sub-processes” for how they are handled. See below.

Second, the type of new work is then coded on the change request

These three “levels” of new work have been useful for me:

  • Projects: True projects requiring project manager resources, charters, etc. These may need business cases, IT governance reviews, etc. before even beginning. The fact there is a change record is mainly a formality.
  • Work units (aka “mini-projects”): Significant work efforts that should have higher visibility and perhaps additional review, but they are not formal projects and do not need project management techniques applied. For example, if one team can conduct a major tool upgrade, that work may be a “work unit.” However, that work may require significant resource management and need IT governance visibility.
  • Tasks: New work that may be complex but does not require significant overhead to implement: adding a column to a report, or upgrading the OS on a server, perhaps. (There may be other categorizations corresponding to ITIL’s change management process, particularly for tasks: e.g. “pre-approved” or “emergency” changes.)

Each organization will have a different threshold for what a project is, or what a work unit is–based on their organizational capabilities. If you are a MS SQL shop and a new product must use Oracle, then installing that new product will probably be a project for you. For an Oracle shop, that same work might just be a task.

The process then differs based on what’s coded. If a change request is coded as a project, its record may need to be transcribed/copied into a project management tool where the project management-specific stuff can be recorded and tracked. The change request for the project more or less “hangs out,” and ideally is automatically updated by the project management tool.

On the other hand, if the change is a work unit, it might require a high level of approval and/or resource allocation discussions.

Small tasks still need to go through the regular change management process.

Very Important Notes

  • Although the project is modeled as a change request, THE DELIVERABLES OF THAT PROJECT MUST STILL FOLLOW CHANGE MANAGEMENT AND HAVE THEIR OWN RECORDS. Approving the project to go forward does not magically allow its deliverables to skip change management. As the project’s deliverables are identified and built, they should be sent through the IT service change management process.
    For example, if the multi-million dollar data center upgrade project were approved, and it needed to take down the network for a weekend, a separate change request for taking down the network (say CRQ 104) would need to be created for the specific network outage. CRQ 104 would then follow the full change management process and would not skip any approval/review steps.
  • There needs to be a consistent method to determine whether incoming work is a project, work unit, or a task. Ideally there should be one decision-maker with the requisite authority and possibly an escalation path if people disagree. Otherwise, one team might call work a “task” and another call the same work a “project.”
  • There needs to be a reclassification process, e.g. if a project should really become a “work unit.”