Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Innovation, Lessons Learned, Strategy
Choosing a methodology
I could use some input/discussion on the best approach/methodology to use implementing the modernization and consolidation of legacy core finance, acquisition, property systems into a single integrated suite of applications. If you have experienced this type of project what methodology did you use (waterfall, hybrid, agile, scrum, etc.)? What did you wish you had used?
Thank you for your consideration.
Sort By:
Page: 1 2 next>
Joseph,

did this for several clients, moving them from legacy to ERP standard solutions (we used SAP) for finance, sales, logistics, HR and many more. Did not do acquisition and property specifically.

The SAP system comes with a recommended approach, which I would call hybrid. It is a step by step approach and should be adapted to the situation.

In my view, the beneficiaries of such a modernisation are company executives, not the individual users. Users often consider such a project as a thread, and it may be that some loose their roles and power. Hence I think a change management part must be included and a step by step approach is helpful to make progress as you tick off results.
...
1 reply by Joseph Newberry
Dec 18, 2020 1:47 PM
Joseph Newberry
...
Hi Thomas. Oracle e-business suite is selected for Financial. Good tip on SAP's recommended approach - give's me an action to check what approach Oracle has (likely it does).
And awesome 2nd tip, i.e. using a change mgmt system for the transition. Action - check if anyone is losing their job or role.
Thanks very much Thomas. I appreciate your input.
Dec 18, 2020 10:13 AM
Replying to Thomas Walenta
...
Joseph,

did this for several clients, moving them from legacy to ERP standard solutions (we used SAP) for finance, sales, logistics, HR and many more. Did not do acquisition and property specifically.

The SAP system comes with a recommended approach, which I would call hybrid. It is a step by step approach and should be adapted to the situation.

In my view, the beneficiaries of such a modernisation are company executives, not the individual users. Users often consider such a project as a thread, and it may be that some loose their roles and power. Hence I think a change management part must be included and a step by step approach is helpful to make progress as you tick off results.
Hi Thomas. Oracle e-business suite is selected for Financial. Good tip on SAP's recommended approach - give's me an action to check what approach Oracle has (likely it does).
And awesome 2nd tip, i.e. using a change mgmt system for the transition. Action - check if anyone is losing their job or role.
Thanks very much Thomas. I appreciate your input.
Joseph

happy if you found that useful.

Regarding change management, one option I saw in practice with a SAP implementation that everybody (including management) was fired and invited to apply to one of the new jobs.

As a result, much fewer people were lost during the process as usual, as it was seen as a fair process.
...
1 reply by Joseph Newberry
Dec 18, 2020 4:51 PM
Joseph Newberry
...
That was a nice alternative. Glad it worked out for some people.
Dec 18, 2020 3:04 PM
Replying to Thomas Walenta
...
Joseph

happy if you found that useful.

Regarding change management, one option I saw in practice with a SAP implementation that everybody (including management) was fired and invited to apply to one of the new jobs.

As a result, much fewer people were lost during the process as usual, as it was seen as a fair process.
That was a nice alternative. Glad it worked out for some people.
Is not a matter of method, is a matter of architecture. I have experience in the field and just to comment the project I led time ago received one of the PMI´s awards, mainly because it was innovative at this time because it was "pioneer" in the use of some technologies and approaches. After the solution architecture was defined (solution is equal to "the thing" to be created plus "the way" to create it) we use a multi-method approach. And just to comment: do not fall in the mistake that some people do and understand that Agile is an approach and can be used with any type of life cycle (waterfall, iterative, etc). Our general approach was use Agile and keeping the life cycle which was more confortable for everything to make the job. For example, for people that work in AS/400 in RPG using waterfall life cycle they continue to do that but we add Agile based approach to leverage it. Just talking about technical issues we keep all the core active using SOA and Service oriented architecture to leverage it and integrate it with the new things to create.
...
1 reply by Joseph Newberry
Dec 21, 2020 8:31 AM
Joseph Newberry
...
What I understand you to be saying Sergio is to modify our approach depending on the comfort level of the service line performing the work or our customer. By the way, you mention "...active using SOA and Service oriented architecture to leverage...". Is SOA something other than service oriented architecture?
Dec 19, 2020 7:11 AM
Replying to Sergio Luis Conte
...
Is not a matter of method, is a matter of architecture. I have experience in the field and just to comment the project I led time ago received one of the PMI´s awards, mainly because it was innovative at this time because it was "pioneer" in the use of some technologies and approaches. After the solution architecture was defined (solution is equal to "the thing" to be created plus "the way" to create it) we use a multi-method approach. And just to comment: do not fall in the mistake that some people do and understand that Agile is an approach and can be used with any type of life cycle (waterfall, iterative, etc). Our general approach was use Agile and keeping the life cycle which was more confortable for everything to make the job. For example, for people that work in AS/400 in RPG using waterfall life cycle they continue to do that but we add Agile based approach to leverage it. Just talking about technical issues we keep all the core active using SOA and Service oriented architecture to leverage it and integrate it with the new things to create.
What I understand you to be saying Sergio is to modify our approach depending on the comfort level of the service line performing the work or our customer. By the way, you mention "...active using SOA and Service oriented architecture to leverage...". Is SOA something other than service oriented architecture?
...
1 reply by Sergio Luis Conte
Dec 21, 2020 8:43 AM
Sergio Luis Conte
...
Perhaps the best example about I tried to say is here in an article I wrote time ago and was published by PMI, IIBA and others as "best practice" (https://www.projectmanagement.com/blog-pos...ight-solution). At the end the key thing is to understand you will go to create a solution then you have to understand the environment to create the solution. In the case I wrote the solution was to transform a hugh bank institution (the number 5 in the world) which have different business additional to banking to put it in Agile based mode. The key was to do that at low cost (we used free software in some layers) and keeping the whole bank assessts as much as possible without "throw it away" (that is the reason we choose SOA architecture to keep AS/400, RPG/400, DB2 etc without modification) and driven by the systemic thinking (it does mean people, process, culture, values, structure, etc were involved too).
Dec 21, 2020 8:31 AM
Replying to Joseph Newberry
...
What I understand you to be saying Sergio is to modify our approach depending on the comfort level of the service line performing the work or our customer. By the way, you mention "...active using SOA and Service oriented architecture to leverage...". Is SOA something other than service oriented architecture?
Perhaps the best example about I tried to say is here in an article I wrote time ago and was published by PMI, IIBA and others as "best practice" (https://www.projectmanagement.com/blog-pos...ight-solution). At the end the key thing is to understand you will go to create a solution then you have to understand the environment to create the solution. In the case I wrote the solution was to transform a hugh bank institution (the number 5 in the world) which have different business additional to banking to put it in Agile based mode. The key was to do that at low cost (we used free software in some layers) and keeping the whole bank assessts as much as possible without "throw it away" (that is the reason we choose SOA architecture to keep AS/400, RPG/400, DB2 etc without modification) and driven by the systemic thinking (it does mean people, process, culture, values, structure, etc were involved too).
In my experience, this is a systems engineering problem, disguised as a software problem. You are trying to migrate functionality from a federated set of systems to an integrated system. The classic systems engineering approach is predictive, but also iterative in essentially a layered approach of Plan Do Check Act.

When I've done this type of thing with engineering systems, there was too much focus on a bottoms-up approach to converting all the data and then assembling it in layers, and not enough focus on delivering functionality.

By that I mean we spent more than a year converting underlying data (e.g. spreadsheets are converted to a database) before we learned the database wasn't structured in a way that fit HOW we used the data. We would have been better off working out the problems on a much smaller scale focusing on specific functions, and working out the bugs first, than focusing on all the data conversion first, and then having to fix it for all functions.

This was a case where a predictive schedule was needed to manage a multi year project, but more agility was required to ensure we didn't generate masses of rework at each subsequent stage of conversion.
...
1 reply by Sergio Luis Conte
Dec 21, 2020 1:33 PM
Sergio Luis Conte
...
@Keith let me say that is very good for me reading a person that make a distinction between system and software. This make the difference between fail or not. In this case is a clear system problem as you stated.
Dec 21, 2020 10:18 AM
Replying to Keith Novak
...
In my experience, this is a systems engineering problem, disguised as a software problem. You are trying to migrate functionality from a federated set of systems to an integrated system. The classic systems engineering approach is predictive, but also iterative in essentially a layered approach of Plan Do Check Act.

When I've done this type of thing with engineering systems, there was too much focus on a bottoms-up approach to converting all the data and then assembling it in layers, and not enough focus on delivering functionality.

By that I mean we spent more than a year converting underlying data (e.g. spreadsheets are converted to a database) before we learned the database wasn't structured in a way that fit HOW we used the data. We would have been better off working out the problems on a much smaller scale focusing on specific functions, and working out the bugs first, than focusing on all the data conversion first, and then having to fix it for all functions.

This was a case where a predictive schedule was needed to manage a multi year project, but more agility was required to ensure we didn't generate masses of rework at each subsequent stage of conversion.
@Keith let me say that is very good for me reading a person that make a distinction between system and software. This make the difference between fail or not. In this case is a clear system problem as you stated.
If you really have a choice in choosing a methodology (I would check with Primary Sponsor, HR, and Accounting), then I recommend hardware & system implementation in waterfall, while desiging, software development, testing, bug/fixing in Agile. Overall project management as waterfall, while product in Agile.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Managing senior programmers is like herding cats."

- D. Platt