In my experience, all-or-nothing cloning projects are often a trap companies fall into when they have a non-agile mindset. It often indicates an underlying struggle with process introspection, workflow adaptation, or acceptance of the trade-offs inherent in the iterative/incremental development model.
Don't allow the organization to fall into this trap blindly. Make the costs and the alternatives visible.
Analysis and Recommendations
"We need a new in-house-developed app to replace the 3rd-party app we currently use, which does this and this and this and ... The new app needs to do everything the old one does. We can't turn the existing product off until the new one meets our needs."
While the last sentence is probably true, the agile path to success lies in frame-challenging the assumptions. Since the company wants to move away from the current solution, it's a great time to evaluate how the existing product is being used, and what the desired future-state workflow looks like.
An MVP is really a validated learning opportunity, so you might think of it as a "product spike" to evaluate level of effort, cost, or market demand. What you really need here is a list of minimum marketable features (MMFs) that are truly essential for the to-be workflow. You might be surprised at how few of the existing product's features your various workflows actually depend on.
An organizational desire to clone a product is often covering up an X/Y problem related to:
- Total cost of ownership (TCO), e.g. licensing, support costs, professional services, labor, etc.
- Unresolved bugs or misfeatures.
- Tool/workflow impedance or mismatch.
- Other issues related to integration or support.
It's generally better to make the business decisions about what to build, and what features it needs to have to replace your existing solution, based on real data about each feature. For example, if you want to replace Word with an in-house word processor, you might say:
It's a bad idea; it literally took decades to refine Word.
What are the odds we can build a better mousetrap? Do we have the internal resources to recapitulate 35 years of software development by one of the largest companies on Earth? Is the juice really worth the squeeze, or are we just trying to avoid having to evaluate our cost structure or change our workflow?
We don't really need an editor with WordArt or OLE support, so we won't try to clone those non-essential features.
Maybe we just need a lower-cost editor that can be embedded into our web UI, or some other less-ambitious project. Likewise, do we really need to replace our widget embiggener with a homegrown version that also does turnip-twaddling? Is anyone in our company even twaddling turnips?
What's the "simplest thing that could possibly work?"
Maybe the cloned product truly has zero value unless it's 100% complete. In the real world, though, it's rarely that cut and dried. Chances are you could solve some pain points without solving all of them. Maybe leadership's all-or-nothing approach can be re-envisioned to fit an iterative or incremental development model.
These questions, and other pragmatic and solutions-focused frame challenges can help you identify the real why driving the effort. Without a solid understanding of why, it's hard to properly identify what needs to be done in a test-first or iterative fashion. And without a well-defined set of "what," it is nearly impossible to estimate the level of effort, schedule and cost, and sequential priorities for work packages. If everything is a top priority, then in reality nothing is.
By adopting a more iterative/incremental approach, the company acknowledges that the business objective (e.g. cloning Word) might not succeed. The benefit of an agile approach isn't that it's faster to do the unlikely; it's that it allows more frequent opportunities for the organization to evaluate whether the costs and level of effort involved remain sensible investments for the business. In this case, building the minimum viable product (MVP) consists of just enough effort/features to feed the project's inspect-and-adapt cycle, which then informs the executive sponsors' decision-making process to fish or cut bait.