Lenka PincotChief of Staff to the CEO| Project Management InstituteParis, 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? Saving Changes...
Sromon DasSenior Project Manager| Mara ConsultingHalifax, Nova Scotia, Canada
one aspect that i feel is often ignored or added as an afterthought is change management, which incorporates training and knowledge transfer. we are often focused on the technical aspects that these soft skills are often ignored. training and CM should be a workstream in the project in order to sustain gains from an implementation and minimize issues during hypercare
...
1 reply by Lenka Pincot
Oct 11, 2018 9:18 PM
Lenka Pincot
...
Thank you Sromon, that’s a very good point about the soft skills, change management and trainings. I agree CM should be a workstream. But I’m also worried that this is one of the area to be reduced when the project does not go as expected.
- Requirements & definitions for the part of handover or transition.
- Details of SLA after transition.
- Measuring the sanctification of stakeholder( customer).
-End user/Administrator guide (for SW) ( as part of training plan).
BR,
Mansour Saving Changes...
Pench BattaEnterprise Lean Agile DevOps Coach /SAFe Program Consultant (SPC6)| Capgemini, Inc.Bentonville, Ar, United States
Lenka, handover process is almost same in both Waterfall and Agile. Agile recommends go with DevOps (Devlopement + Operations) model, which is both development and operations teams work together throughout the execution of the project/product.
...
1 reply by Lenka Pincot
Oct 11, 2018 9:24 PM
Lenka Pincot
...
Hi Pench, I would hope for a qualitative difference when DevOps cooperation is in place compared to waterfall when PM is handing over the deliverables to operations. Also the transitions might be easier when the project was delivered in working increments. Thanks for your inputs!!
In Waterfall methodology, we focus on documenting the transition documents and facilitating access requests for the Ops team to various aplications / servers. Dev team will do knowledge transfer to the Ops team during Warranty period and will do shadowing of Ops team towards the end of Warranty.
In Agile also documenting of required documents is expected to provide transition to Ops team. But in matured Agile teams and who are already in DevOps culture, transition is very easy as the Dev & Ops teams would have been working together even during the Sprints
...
2 replies by Lenka Pincot and Rami Kaibni
Oct 11, 2018 12:59 PM
Rami Kaibni
...
Lenka, I pretty much agree with Girjia's feedback. One thing to remember, in agile, you deliver increments of working products throughout the project so transition should be a bit smoother than the Waterfall where you handover the entire product at the end.
Oct 11, 2018 9:25 PM
Lenka Pincot
...
Thank you Girija, that is very nice summary.
Saving Changes...
Sam MotesManager II Business Sys, Operational Excellence| BA Systems Inc.Ellenton, Fl, United States
I have found success as Girjia pointed out using transition documents but they key I have found is heavily engaging the Ops team in the transition documentation creation so they have ownership in the hand off. Helps with signoff when you can say you said you would need the items on this list to accept hand off and all have been signed off as complete. Saving Changes...
Anish AbrahamPrivacy Program Manager| University of WashingtonAuburn, Wa, United States
I concur with Sromon on this. I think it's very important to establish a change control board to manage ongoing change in the operational environment. By doing so,the business customer will have a method to request changes to the application without deterring the project team from their intended goal.
...
1 reply by Lenka Pincot
Oct 11, 2018 9:29 PM
Lenka Pincot
...
Thank you Anish, so basically you’re pointing out that Ops would be under change along the project execution. I like it. It can be applied when the project is delivering changes or creating new services and products. But I would guess there must be established fair level of trust that the project will be completed and will deliver the scope.
With lessons learned documented throughout the project phases, conduct post-project review and assessment of both positive and negative experiences.
Provide smooth knowledge transfer from the project team to the operational team. Include operational members throughout the project phases to arrive at the finished deliverables.
There should be proper transition documentation to communicate the processes and procedures required to perform or support the deliverables.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Oct 11, 2018 10:52 AM
Replying to Girija Ramakrishnan
...
Lenka -
In Waterfall methodology, we focus on documenting the transition documents and facilitating access requests for the Ops team to various aplications / servers. Dev team will do knowledge transfer to the Ops team during Warranty period and will do shadowing of Ops team towards the end of Warranty.
In Agile also documenting of required documents is expected to provide transition to Ops team. But in matured Agile teams and who are already in DevOps culture, transition is very easy as the Dev & Ops teams would have been working together even during the Sprints
Lenka, I pretty much agree with Girjia's feedback. One thing to remember, in agile, you deliver increments of working products throughout the project so transition should be a bit smoother than the Waterfall where you handover the entire product at the end.
...
1 reply by Lenka Pincot
Oct 11, 2018 9:30 PM
Lenka Pincot
...
Agree
Saving Changes...
Raymond Van TonderManaging Director| Engagement Consulting Services PTY(LTD)Springs, Gauteng, South Africa
Lenka, you are touching a very important aspect of project delivery; strategic intent or benefits realisation.
It is important to include the criteria of measuring the benefits realisation of the project. Depending on the industry there can be different approaches, but most common is to include "Operational Readiness" or "Operating Model" requirements in the project deliverables. Having a Agile mindset keeps the focus on the Value of the project and not just having a scenario of "A good project Manager successfully delivering the Wrong project".
Typically acceptance criteria is focussed on the project scope of execution and not the business realisation criteria of the project, it is therefore very important to keep the focus on the strategic intent of why you are executing the project.
...
1 reply by Lenka Pincot
Oct 11, 2018 9:34 PM
Lenka Pincot
...
Raymond, that is very good point to have Operating model as part of the deliverables and to keep focus on the intended value.
When combined with other inputs to have transitions documents and change board to adjust Ops environment along the project, it forms certain level of complexity however provides very solid base to maximize the chance of successful change.
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.....
...
2 replies by Brian Kelly and Lenka Pincot
Oct 11, 2018 9:37 PM
Lenka Pincot
...
Thank you Joseph, that is very nice summary. I think it means that to follow-up on and ensure the value realization we would be looking for other roles in the organization apart from PM.
Jan 15, 2021 3:08 PM
Brian Kelly
...
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
Community Champion
