Can you provide more context? Are you looking for some specific templates or just a description of the projects themselves? Any particular type of legacy system (e.g. financial, health care, people management)?
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
While I agree with @Kiron statement let me say decommission is leading by strategy. Just to put it into the framework of PMI and others (just in case you like to search for more datiled information inside the standards) business analyst is accountable for that while performing "solution monitoring" activity. Just to put examples in my actual work place we decommission technology because technical obsolescense (some pieces will not be supported by the vendors) or we make software decommision because we migrate to new software architectures like cloud for example. Saving Changes...
Transitioning from hand drafting to CAD systems is one many companies faced 20-30 years ago. It's not just the physical drawings involved. It also includes BOM systems, drawing storage, how drawings are used by manufacturing, etc.
...
1 reply by Valerie Welbourn
Jan 27, 2022 8:34 AM
Valerie Welbourn
...
Keith, that takes me back. I remember digitizers!
Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Ruchika,
SAP rollouts are a good and typical example.
Case: a global HQ decides to harmonize ERP/Finance system in all their country organizations. They develop a global architecture and pilot a country, which then becomes a template for rollout.
In each country you have existing systems, processes which are to be replaced. This often happens in a big bang at financial year end. It involves data cleansing and migration before the cut-over, dry-runs, change management, possibly re-organization and scrutiny of local laws and regulations. And big courage of decision maker to Go Live despite incomplete implementation. After Go-Live, plan for 3-6 months of hypercare including leftover implementation.
Thomas Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Sometimes you learn more from what went wrong than what went right. A prime example is the modernization of the Canadian federal payroll system. The Phoenix system was to replace all payrolls in the federal government. After millions of dollars, years of disruption its still a mess. Part of the problem no doubt was political interference, especially premature implementation. Possible blame could go to wholesale change versus evolution. It would make a great case for an MBA study and possible thesis.
Just wanted to clarify, Peter. Prior to IBM's implementation of Oracle Peoplesoft for the government of Canada's Phoenix, there was a single system, Public Service Compensation System, which was a mainframe-based, batched-input system. Previous attempts at replacing the aging system were unsuccessful in finding a solution or provider..
Even to someone who is involved with the federal government, little has been said about the source of Phoenix' woes. It is obvious that much functionality was inadequately tested before being released.
Sometimes you learn more from what went wrong than what went right. A prime example is the modernization of the Canadian federal payroll system. The Phoenix system was to replace all payrolls in the federal government. After millions of dollars, years of disruption its still a mess. Part of the problem no doubt was political interference, especially premature implementation. Possible blame could go to wholesale change versus evolution. It would make a great case for an MBA study and possible thesis.
Just wanted to clarify, Peter. Prior to IBM's implementation of Oracle Peoplesoft for the government of Canada's Phoenix, there was a single system, Public Service Compensation System, which was a mainframe-based, batched-input system. Previous attempts at replacing the aging system were unsuccessful in finding a solution or provider..
Even to someone who is involved with the federal government, little has been said about the source of Phoenix' woes. It is obvious that much functionality was inadequately tested before being released.
...
1 reply by Peter Rapin
Jan 24, 2022 5:41 PM
Peter Rapin
...
As a casual employee at the time of implementation (took months to process and get paid for a few hours of work) and a tax payer I was/am affected by the spectacular failure of the roll out of the Phoenix payroll system. We may never know what went wrong but I still think it would make a fascinating study, not only from an academic perspective but as a lesson learned for the industry.
In the structural engineering world we have had some significant failures, usually involving bridge construction, which we have used as reminders of our fallibility. Maybe this could become an IT project management teaching experience.
Its probably too soon and too complex to be of assistance to Ruchika but maybe at some point it could be cited as a lesson learned.
Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Just wanted to clarify, Peter. Prior to IBM's implementation of Oracle Peoplesoft for the government of Canada's Phoenix, there was a single system, Public Service Compensation System, which was a mainframe-based, batched-input system. Previous attempts at replacing the aging system were unsuccessful in finding a solution or provider..
Even to someone who is involved with the federal government, little has been said about the source of Phoenix' woes. It is obvious that much functionality was inadequately tested before being released.
As a casual employee at the time of implementation (took months to process and get paid for a few hours of work) and a tax payer I was/am affected by the spectacular failure of the roll out of the Phoenix payroll system. We may never know what went wrong but I still think it would make a fascinating study, not only from an academic perspective but as a lesson learned for the industry.
In the structural engineering world we have had some significant failures, usually involving bridge construction, which we have used as reminders of our fallibility. Maybe this could become an IT project management teaching experience.
Its probably too soon and too complex to be of assistance to Ruchika but maybe at some point it could be cited as a lesson learned.
I feel your pain, Peter. I'm now in my seventh month as an employee and have yet to get my benefits. (Thank God I'm getting paid, at least.)
Jan 25, 2022 8:24 AM
Kiron Bondale
...
Peter -
the unfortunate thing is that whereas engineering is a profession and there's real/perceived liability for the folks directly involved with construction projects which go horribly wrong either during the project's life time or in production use, this is rarely the case with software projects.
Given the historical woeful track record and the differences between physical and intangible projects, there are still lots of challenges in getting large, complex software projects to the finish line in a predictable manner.
As a casual employee at the time of implementation (took months to process and get paid for a few hours of work) and a tax payer I was/am affected by the spectacular failure of the roll out of the Phoenix payroll system. We may never know what went wrong but I still think it would make a fascinating study, not only from an academic perspective but as a lesson learned for the industry.
In the structural engineering world we have had some significant failures, usually involving bridge construction, which we have used as reminders of our fallibility. Maybe this could become an IT project management teaching experience.
Its probably too soon and too complex to be of assistance to Ruchika but maybe at some point it could be cited as a lesson learned.
I feel your pain, Peter. I'm now in my seventh month as an employee and have yet to get my benefits. (Thank God I'm getting paid, at least.) Saving Changes...
As a casual employee at the time of implementation (took months to process and get paid for a few hours of work) and a tax payer I was/am affected by the spectacular failure of the roll out of the Phoenix payroll system. We may never know what went wrong but I still think it would make a fascinating study, not only from an academic perspective but as a lesson learned for the industry.
In the structural engineering world we have had some significant failures, usually involving bridge construction, which we have used as reminders of our fallibility. Maybe this could become an IT project management teaching experience.
Its probably too soon and too complex to be of assistance to Ruchika but maybe at some point it could be cited as a lesson learned.
Peter -
the unfortunate thing is that whereas engineering is a profession and there's real/perceived liability for the folks directly involved with construction projects which go horribly wrong either during the project's life time or in production use, this is rarely the case with software projects.
Given the historical woeful track record and the differences between physical and intangible projects, there are still lots of challenges in getting large, complex software projects to the finish line in a predictable manner.
Kiron
...
1 reply by Peter Rapin
Jan 26, 2022 10:28 AM
Peter Rapin
...
You are right in that engineering is a profession and the Engineering Act (or equivalent depending on the jurisdiction) is there to protect the public, specifically public safety. Two points to be made:
1) Project managers delivering both physical and 'intangible' projects see themselves as professionals and therefore should be held to a high standard.
2) Although there may not be a 'physical' safety issue there could well be a mental safety issue with catastrophic IT project failures such as the Canadian federal Phoenix payroll system.
All I'm saying is that a project failure is an opportunity for lessons learned and that the Phoenix payroll failure would make for a challenging case study. Maybe going forward would not be as 'woeful' if we were given the opportunity to learned from the past.
Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Jan 25, 2022 8:24 AM
Replying to Kiron Bondale
...
Peter -
the unfortunate thing is that whereas engineering is a profession and there's real/perceived liability for the folks directly involved with construction projects which go horribly wrong either during the project's life time or in production use, this is rarely the case with software projects.
Given the historical woeful track record and the differences between physical and intangible projects, there are still lots of challenges in getting large, complex software projects to the finish line in a predictable manner.
Kiron
You are right in that engineering is a profession and the Engineering Act (or equivalent depending on the jurisdiction) is there to protect the public, specifically public safety. Two points to be made:
1) Project managers delivering both physical and 'intangible' projects see themselves as professionals and therefore should be held to a high standard.
2) Although there may not be a 'physical' safety issue there could well be a mental safety issue with catastrophic IT project failures such as the Canadian federal Phoenix payroll system.
All I'm saying is that a project failure is an opportunity for lessons learned and that the Phoenix payroll failure would make for a challenging case study. Maybe going forward would not be as 'woeful' if we were given the opportunity to learned from the past. Saving Changes...
