When is a Change really a Project? ITIL simply says the following are not changes:
- Changes with significantly wider impacts than service changes, e.g. departmental organization, policies and business operations – these changes would produce RFCs to generate consequential service changes
- Changes at an operational level such as repair to printers or other routine service components.
It isn’t clear to me that the natural agency—PMI—offers any clear guidance. PMBOK defines a project as a temporary endeavor undertaken to create a unique product, service, or result. Temporary endeavor implies a definite beginning and end. Unfortunately, this definition is not inconsistent with a Change.
PMBOK offers little guidance about how big or how little a project needs to be in order to become a “Project” except to say the PMO exists to support project managers including developing a methodology, best practices, and standards. I would say a project is a “Project” when the benefits of managing it as a “Project” outweigh the overheads of the PM method. Hence the answer is organizationally dependent. If the organization’s PM methods are non-existent, then you can call anything a “Project” and send it off the secretary masquerading as a PM.
If the PMO’s PM method is detailed and rigorous, then projects would be greater than 80 hours at a minimum. However, in order to avoid the tendency of middle managers to “break up” projects in order to avoid PMO oversight, PMO’s will generally make the PM method scalable, requiring less overhead and oversight for smaller projects and more for larger projects.
In general time alone is a poor indicator for defining the boundaries of a project. A PMO should also look at factors such as strategic alignment, whether the Change supports or endangers the company’s strategy, and the project’s risk profile. Riskier projects should be overseen by the PMO in order to ensure the risk profile is in line with its support of the strategy.
In most organizations the PMO is more strategic and is independent of the IT operational processes. The Change Manager may hear about projects a few days before they are expected to go live (as a Change). In other words, the Project usually precedes the Change, not the other way.