Skip to main content
Project Management

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

9
  • 1
    IME this doesn't work. If your system is, say, a system to fill out tax forms--then you need to fill out all the tax forms before the users will use it. If you try to tell them to fill out some forms in system A and some in system B then they will probably revolt (not to mention you may not be able to properly fill out the forms anyway, if the forms are reliant on data that goes across forms). Requirements to upgrade systems are often coming from the top of the organization down, as in "we no longer want to pay for the mainframe, all software on the mainframe must be re-written". Commented Dec 8, 2022 at 19:36
  • And "full set of requirements" is just a joke. The full set of requirements is that the new software must fill all the functionality that the old software had, but better and faster. You can try leaving off some stuff that seems to be not used, but then you find out that it was only used by one group during the end-of-year accounting and it's absolutely critical during that time or something. Commented Dec 8, 2022 at 19:40
  • 2
    @user3067860 I never said that you could go live and fully replace the old system in a couple of iterations. Building iteratively and incrementally would let you get feedback from key stakeholders. At some point, the stakeholders will either terminate the effort or they will say that they can start using the new system. Perhaps they will use both systems in parallel, for different groups of people, even. But what I've described is a good way to replace a legacy system. Commented Dec 8, 2022 at 19:58
  • We did that. What happened was that even though the new system was up running in parallel as it was built out feature by feature no one used the new system until the legacy system was shut off (after 6 years! spent developing the new system) and then they suddenly had a lot of problems they "found" in the new system. Commented Dec 8, 2022 at 20:53
  • And we're also currently doing this with a different system and management is angry with the technical teams since everyone keeps finding features in the legacy system that need to be added to the new system which of course pushes out the completion date (and features get released and then have to be turned off/rolled back since some important thing was missed, etc.). Commented Dec 8, 2022 at 20:57