Wayferry aims to help clients replace outdated enterprise software. This page is an overview of the 7 phases in the Wayferry process.

<aside> 💡 With very few exceptions, requirements on a Wayferry RFP are business requirements and not software requirements.

• Business requirements describe WHAT the software must deliver to provide value to the buyer and are used in the software selection.
• Software requirements describe HOW the software will be configured and are used in the implementation. </aside>

Phase 1: Business discovery & alignment analysis

Aim of this phase

• Identify the business goals that the new software must help achieve. This directly links the success of the software replacement project with achieving those goals.
• Verify the business goals are aligned and support each other.

Phase 2: Business process audit

Aim of this phase

• From a software perspective, any business can be thought of as a collection of business processes that, when executed, deliver certain outputs.
• The aim of this phase is to identify and document all significant business processes that should be executed in the new system, and the outputs delivered by those processes. The ultimate aim is to select replacement software that can best deliver those outputs.

<aside> 💡 We make every effort to write requirements that specify WHAT the software must do to create value for the client, i.e. WHAT business process must be executed and WHAT outputs must be delivered. We strive to avoid telling you HOW your software must operate. While requirement examples may describe HOW something is done, they are only examples and are not meant to specify HOW you might meet WHAT the client wants.

</aside>

Phase 3: Requirements

Aim of this phase

• To create a comprehensive list of prioritized requirements that adequately capture the new software's desired functionality. Potential software products will be evaluated against these requirements.
• Develop the demo script.

Phase 4: Evaluation

Aim of this phase

• Use an RFP to evaluate how well potential software products can meet the requirements developed in Phase 3.
• To verify the fit between potential products and the requirements from Phase 3.