As I am currently experiencing the (painful) steps of moving, it reminded me that the boundary between projects and processes is not well defined.
If we consider the PMBOK definition for projects which has criteria such as a definite start & end, uniqueness, adding value and a temporary endeavor, one could argue that relocating is a project – after all, you start the planning as of when you buy (or sell) a home, it is definitely unique for each instance, it (hopefully) adds value, and one hopes that it will end and is temporary!
On the other hand, let’s consider those companies that specialize in relocating “packages”. The same scope is delivered, and yet to them, it is a service that they regularly deliver.
The difference is that for us, moving is a project – we don’t do it regularly enough to have defined a consistent process, nor have we defined metrics to tell us when the process is “in control”. From a risk perspective, the level of uncertainty on a move is significantly more than it would be to a relocation company.
The same could be said of IT organizations that treat regular requests as projects instead of standardized services – an example of this is a systems team that provisions servers for business applications. If they treat requests to build new servers as project work, it implies a lack of standardization that could artificially introduce unpredictability to schedule & cost expectations. On the other hand, if they define a standardized process for building servers, they will eventually (through process refinement) be able to improve predictability and consequently improve customer satisfaction.
So while this is a blog that mostly focuses on project management, here’s my vote for reducing project work through proactive definition of processes!