How do you integrate and reuse existing requirements and models from previous or similar projects or domains?

To integrate and reuse prior requirements and models effectively, start by assessing project objectives and scope. Identify similarities with past endeavors. Review existing resources, extracting relevant components. Adapt these to fit the current context while maintaining coherence. Utilize knowledge repositories for organized retrieval. Engage stakeholders, especially from past projects, for insights. Continuously refine integrated elements as needed. This approach boosts efficiency, consistency, and draws on valuable expertise, enhancing project outcomes through strategic integration.

Discover and formulate common patterns. Let me quote F.A. Hayek ("The theory of complex phenomena"): "The great strength of mathematics is that it enables us to describe abstract patterns which cannot be perceived by our senses, and to state the common properties of hierarchies or classes of patterns of a highly abstract character. [...] A theory will always define only a kind (or class) of patterns, and the particular manifestation of the pattern to be expected will depend on the particular circumstances [...] to which [...] we shall refer as 'data'). How much in fact we shall be able to predict will depend on how many of those data we can ascertain."

Integrating and reusing existing requirements and models from previous projects or domains is a strategic art of weaving experience into innovation. By meticulously dissecting these prior blueprints, I extract the essence of their success, adapt them to the evolving landscape, and infuse them with novel insights. This orchestration requires a keen eye for identifying common threads and a mastery of abstraction to harmonize diverse elements. Leveraging the synergy of past accomplishments, I foster a bridge between familiarity and progression, channeling the wisdom of yesterday into the innovation of tomorrow.

It is important to identify and filter the sources depending on the type of project and our previous exposure in the sector. The accurate data and flexible templates support us speeding up the development of deliverables and taking certain decisions. In case of SAP projects, in which I am mainly focused, the official documentation provides agile methodology with sample files that can be taking into account to define the project phases and main deliverables for each task. Also it is easy to implement Best Practices in the ERP system that serve as the basis to implement the solution. Then, it is time to adapt the system using our experience to meet customer requirements

High similarity, around 90%-95%, makes reusing existing requirements and models seamless, rendering the question of reuse moot. In contrast, moderate similarity presents a dilemma: opting for reuse could be less effective than crafting anew. This is because modifying may demand more time than building from scratch, considering the project's distinct objectives, context, and stakeholders when similarity falls short of the extreme. Moreover, a pertinent concern arises regarding project managers. They might adhere to a utilized but misfitting framework, potentially sacrificing the subjective processes that yield true project value in the pursuit of presumed savings.

Whenever a new requirement is required to be developed, the #lowcode and #outsystems COE team would assess the quality of current solution and conduct the function point analysis and arrive at the reusability and cost savings factor. Based upon the outcome, the IT team would be allowed to reuse and/or develop the application.

A quick tip here to save some time, because this process might take long: Rely on the stakeholders that were part of the previous analysis phase. Would be ideal to get the feedback from the previous project team that gathered the requirements, but this is not always the case, so it's most likely that the stakeholders that collaborate with the requirements are still around, so they can be helpful to validate the feasibility of previous requirements.

Building on what @Antonio Palacios suggested. 1) Identify people who contributed on similar projects and 2) if possible, have conversations with them that focus on CONTEXT. Today it is easier that ever to access project deliverables, but sometimes it's difficult to understand the WHY behind their creation.

For a new project you would still hold those requirement gathering workshops and adapt the existing process flow maps and requirements documentation/matrix which captures the outputs from the workshops and use those for a) customer sign off and b)supplier to confirm they are fully met within their solution and then you have a sound basis for supplier evaluations/gap analysis/risks etc

Gap analysis may identify three categories of adaptation: 1) vanilla (none needed) 2) configuration (setting parameters, defining values, etc.) and 3) customization. Generally whichever solution is selected should minimize customization, but it can't always be avoided. Customization is a dangerous box - it can be tempting to overscope a "one ring to rule them all" solution that addresses every possible permutation of the core business requirement. Balance the need to deliver against the core requirement while providing flexibility to address potential future user stories.

CYA = Clarify Your Assumptions. Think beyond the status quo & FUD factor (fear, uncertainty & doubt) to find the space in-between where clarity shines. Simply put, follow the necessary steps of defining/documenting the Who, What, When, Where, Why, How with a lens focused on inputs, processes, outputs. Build your matrix & communication channels surrounding those tangible & actionable elements to drive gap analysis between the “as-is” vs the “to-be”. Leverage existing documentation (if there is any) or build your own through interviewing power players. Never underestimate complexities w/ M&A in processes & systems & focus QA efforts to test for success as well as break. There are golden nuggets in each.

Define and agree WHO validates requirements from the beginning. For large, complex projects with many stakeholders it may be helpful to create RACI charts so everyone clearly understands their roles (and everyone else's). Define and agree acceptance criteria, processes and timelines from the outset.

For large, complex projects the level of effort required to manage and maintain models, throughout and beyond project lifecycles, is often significantly underestimated. Budget, staffing and systems resources should be set aside for these ongoing responsibilities. Different teams may be responsible for development / delivery and maintenance / support, so continuity of knowledge is important.

Best part of using similar logic and integration model is that once project goes live support team will not find it difficult to support and same team can be leveraged to support new project.

Lessons learned are a must before closing a project. They help us avoid repeating mistakes, improve business and IT processes, and make better-informed decisions in the upcoming projects. During that phase the key takeaways are identified and documented. Then, it is analyzed their impact and the lessons learned are shared with relevant stakeholders.

Why opt for reuse? Is the goal solely time efficiency? If that's the case, it's a misguided objective. Each project's fundamental aim is to create value aligned with its specific purpose. Prioritizing time-saving isn't the initial focus. Project efficiency in execution is relevant, but it's grounded in operations management, which sets it apart from the core nature of a business analytics project.