Please login or join to subscribe to this thread
Operations often include multiple projects. Improvements for efficiency, error reduction, flow reduction, etc. drive projects. Changes to the product, growth or reduction of operations, implementation, maintenance, and retirement can generate projects.
Although operations are an ongoing effort with an emphasis on repeatability, unless the market never changes and the business is already run perfectly, it still requires temporary endeavors to capture and maintain desirable business metrics.
A project has a defined start and end. For the other part, operations are repeated activities that are performed periodically.
If there isn't a clear delineation upfront of when a project will end, the line becomes blurred indeed. This is why it is always a good idea to start with the end in mind...
A lot must depend on the nature of the operations, the products and services. In information technology, constant evolution tends to be the norm rather than a temporary endeavour. Usually people start thinking in terms of "projects" when current resources are deemed to be insufficient in scale or knowledge to cope with change, but arguably that doesn't have to be the case. If your operational capabilities are sufficiently elastic and responsive to business needs then you won't have to resort to a project in order to deliver or accelerate change.
It is very important to ensure that the handout from the project to the line is smooth and agreed upon upfront. A way to go about this is to create a work package (could be called Handout or Transfer or something similar) with their corresponding deliverables and acceptance criteria.
Keith made good points.
I think you are talking about transitioning to a new *team* rather than ending a project. End of project doesn't mean you necessarily have a different team or even a different operating model. End of project may mean the team has different priorities but if the team is suitably agile (in the organisational sense) then the start and end of project is almost a non-event. Each iteration can be considered a new "project".
Operations is delivering the value of an organization to it's customers. Hence it is measured by growth (revenue) and efficiency (cost).
Projects often deliver change to operations (new market - revenue, new IT system - efficiency) and are born out of the need of operations to grow and be efficient.
So projects have understand the problem (of operations), and define and deliver a solution, which includes changed roles and changed processes. Handing over solutions to operations might require Organizational Change Management and a longer transition period (I have worked with a 18 month transition in the case of outsourcing).
Using operational resources in projects creates prioritizations issue, since operations management is mostly payed for running operations, not projects. But operational resources are key stakeholders for the project, as they provide requirements, feedback on the design and testing and in the end are expected to use the solution.
So operational staff has a role in projects but they do not run the project.
Please login or join to reply