Project versus Service

By telleropnul, July 4, 2016

I see the phrase ‘project’ and ‘service’ being used interchangeably at times, which may be a factor in why putting together a coherent services catalog is challenging.  For a service organisation, projects should arguably only and at all times either result in a new service or manipulate an existing service.  A project that does not operate on a service should be treated with suspicion.  As the final steps in a project development lifecycle (the production stage: deploy, maintain and support) there should be a controlled handover where the project ends and the repackaged service continues to exist.

Project development cycle

sdlc1 sdlc2


Services (not projects) are ‘boxes’ in which we ship things.  The shape, size, colour and material of each box is always the same, its contents is not.

  • Services (not projects) are vehicles for deployment.
  • Services (not projects) are stable and ongoing.
  • Services (not projects) can be modular.
  • Services (not projects) can be tiered.
  • Services (not projects) require support.
  • Services (not projects) often use accounting (‘units consumed’) and invoicing (‘units consumed x unit price’).
  • Services (not projects) require an Operational Support Plan (OSP), Product Readiness Certificate (PRC) and Quality Assurance Certificate (QAC)
  • Projects (not services) are new initiatives.
  • Projects (not services) go through a development lifecycle.
  • Projects (not services) are finite.
  • Projects (not services) require a development team.
  • Projects (not services) require time and cost management.
  • Projects (not services) require planning.
  • Projects (not services) require testing.
  • Projects (not services) produce one-off deliverables.

For a service organisation projects should always and only result in or manipulate services.