Project Management

Please login or join to subscribe to this thread

What are your tips for a successful transition of finished project delivarebles to operations?

linkedin twitter facebook   Benefits Realization   Change Management  
avatar
Lenka Pincot Chief of Staff to the CEO| Project Management Institute Paris, France
When a project is over and there are deliverables, which may include software, organizational changes, new processes, new knowledge incorporated in employee trainings, it is time for closing and handover to operations.
Do you see a difference between handover of deliverables delivered in agile or waterfall environment? What are your practical tips how to make the handover a success and ensure that the deliverables will create benefits as intended? How do you see your role as PM in this project phase?
Sort By:
< 1 2 3 >
avatar
Brian Kelly Senior Programme and Project Manager | Contract London, United Kingdom
Thanks Lenka for raising this discussion. I'm rapidly learning Agile and need to develop an RFP for Agile development... I’m also trying to understand how we transition from Agile to operations (if there is no Dev Ops org in place), and welcome responses. I assume Sprints would need to be defined to handover documentation, retrospective lessons learned, complete training, and close the project budget moving into Opex for run support. Real world responses or links to similar discussions welcomed!
avatar
Brian Kelly Senior Programme and Project Manager | Contract London, United Kingdom
Oct 11, 2018 1:58 PM
Replying to Joseph Toth
...
Lenka -

I have actually been having this discussion on my current assignment as well.

Regardless of an AGILE --or-- WATERFALL project delivery, my advice would be to make sure that you had a clearly defined scope that itemized what was included in the overall set of project deliverables. Your question regarding how to "...ensure that the deliverables will create benefits as intended? " is what I've named " value realization ". This typically is NOT something generally covered within the scope of a project. Consider the construction of a home. You will be able to prove to the new homeowner that HVAC has been properly installed & tested, however, you will not be around to help vet whether or not this HW installation will deliver the expense savings as was advertised. "Why...?" Because that aspect of the project was NOT in the contract / plan for delivery. Likewise, if that type of deliverable was not included in the SCOPE DOCUMENT of your project, as an element of "value realization", would not be something the PROJECT TEAM would end up having to confirm.

"Value realization" within the scope of the project would be something like: " reduction of keystrokes by 50% "; "record imaging error quality reduction of 50%"; # servers retired. This can be measured AND validated thru testing.

"Value realization" outside of the scope of the project would be things like: "revenue generation"; " cost reduction "; "increase of market share"; "efficiency"; "product quality"; adoption rate, etc. Typically, these aspects of project / product value would come from the business side. NOTE: I have not personally experienced ( nor have awareness ) of any organization that attempted to follow-up on this aspect of a proposed scope / business case document.

In summary, the role of the PM in delivering project / product "value" is defined by what is included within the approved scope statement. Inclusion / exclusion of these types of success factors will ultimately come down to the cost associated with the LOE needed from select project team members to hang around LONGER until those metrics are validated. If NOT included within the scope of the project, it is up to the project owner to make sure that what has now been built meets its intended need.

Hope my response helps address your question.....
I'm rapidly learning Agile. My thoughts re: “clearly defined scope that itemized what was included in the overall set of project deliverables”. - Approved scope statements with overall deliverables don't exist in Agile at the outset, since we are delivering value in increments. The Triple Constraints Triangle is therefore flipped upside down as scope is controlled (changing scope requires replacing low value items in the backlog with higher priority value items that don’t impact value already delivered). The same principle applies in SCRUM method with any forced changes in Sprint scope balanced by prioritising over lower value work in that Sprint (however it will impact the velocity measurement). Happy to be challenged on this to better reinforce my understanding of Agile. Thanks
avatar
Oliver Schneidemann Transformation Professional New York, NY, United States
Assuming this is at nearing project close, and not delivery of an iteration? If I were a Project Manager, I'd want to bring answers to the 3 following questions to my sponsor: (1) what did we say we would deliver (business case, agreed scope), (2) what did we actually deliver (this implies that any residual scope that wasn't delivered is not a surprise to the sponsor), (3) what have we handed off to those who will use what we delivered, and have they actively accepted their ownership and accountability. Getting the last part (BAU handoff) right, to me, is most critical. As a Portfolio Manager, I'd look for the benefits forecast in the business case, and should report value capture.
avatar
Amr Abd El Azim United Arab Emirates
To do the Handover from Projects to Operation following need to be done :
1- Project is financially closed ; All suppliers are paid ; and all invoices are collected from customer
2-All Deliverables are completed and approved by Customer (As Built documents ; snags clearance report)
3-Handover meeting to be done with operations team for warranty period ; and agree on budget allocated for this period.
< 1 2 3 >

Please login or join to reply

Content ID:
ADVERTISEMENTS

"A narcissist is someone better looking than you are. "

- Gore Vidal

ADVERTISEMENT

Sponsors