Poorly conducted Discovery phases can greatly damage the relationship and trust between a client and their technology partner.
Why it can spell disaster for a project
When companies attempt to streamline or abbreviate the discovery phase in their legacy app migration projects, they often experience the opposite outcome: missed deadlines, delays, and disputes with contractors.
The second issue concerns the budget. Consider a scenario where a project was initially budgeted at $30,000, and this price was locked in through an agreement. However, as the project progresses, the actual cost doubles. This presents a substantial risk of breaching the contract, particularly if unforeseen expenses arise. Imagine the difficulty faced by both top managers and department heads as they try to justify to their superiors why a team accepted a deposit but failed to complete the project.
Without sufficient details, any cost estimate becomes an uncertain guess. Clients who request pricing without providing necessary documentation often encounter significant discrepancies between quotes from different vendors. For instance, one firm might suggest $1 million, while another proposes $100,000, leaving the client bewildered by the substantial difference.
Most vendors aim to narrow this cost estimation gap by requesting technical documentation. However, it is often missing, making it impossible to retrieve or consult developers about software or features, especially if they have left the company many years ago.
This scenario presents a challenge, but there’s no need to panic. A precise Discovery Phase, along with the tips below, has the potential to reduce the estimation gap to 20%.
Schedule complimentary meetings
Beginning with 1 to 3 complimentary meetings is recommended. During these sessions, a business analyst (BA) must work closely with the customer to grasp the concept and the desired outcomes of the product.
Pose the appropriate questions to establish priorities
One of the best practices is to utilize the Value vs. Complexity Quadrant. When deciding which legacy applications to begin upgrading, prioritize those with high business value and low complexity. This implies they demand minimal effort and resources for implementation. Systems with high value but requiring substantial effort should be earmarked for future scaling. Conversely, applications with low business value and high modernization effort are likely to fail.
Utilize insights gained from similar projects
Modernizing legacy software presents numerous options. For example, you may contemplate migrating to the cloud. To implement this strategy, you can either rewrite your applications from scratch, integrate specific modules that interface with existing databases, or develop new modules to enhance the current system.
As a vendor, if you already possess similar case studies, you’re fortunate because you can save your client considerable time in projecting the necessary resources.
For instance, the need for modernizing an in-house ERP system is quite common. As a contractor, you may already be aware that the forthcoming OS update could render the ERP system non-functional due to its outdated architecture, which inhibits the integration of modern features. Drawing from past experiences with similar projects, you can swiftly offer an initial budget range.
Get ready for and initiate the Discovery Phase
First, collaborate with stakeholders to develop a Proposal for the Discovery Phase, which should include estimates and specify the anticipated duration. Once stakeholders approve the proposal, kick off the Discovery Phase. Its duration usually ranges from 40 to 160 hours, depending on the project’s complexity. This timeframe enables a thorough yet efficient data-gathering process.
Design a Vision and Scope Document
The Vision and Scope document keeps everyone on the same page. It translates software needs into simple terms for all engineers. It sets clear project limits, so stakeholders know what’s included and what’s not.
This document also contains important subsections like User Roles, Security and Configuration Module, Owner Administration Module, Client Module, and any other necessary project-specific details.
Recommend a minimum and maximum budget
Based on the Vision & Scope document, offer thorough Optimistic and Pessimistic cost estimates for the client.
An acceptable gap should not surpass 20%, yet there are instances with heightened risks where this difference can widen further. In such projects, combine the optimistic value with a risk percentage to derive the pessimistic value. When risks exceed the 20% target, identify the reasons and suggest mitigation strategies. Throughout this process, the project manager must involve the client, emphasizing risks and proposing alternative approaches.
This method ensures the customer remains informed and can make important decisions with real-time updates.
Take into account the Time and Material Pricing Model
In a time and material contract, the total cost of the project is not predetermined initially. You hire a contractor who supplies specialists at a fixed hourly or monthly rate, and the final project cost is determined by the actual hours worked.
This approach is flexible, adjusting project requirements and scope, fitting Agile project management principles. The development process iterates, each cycle delivering a specific result like a new feature or integration. It enables quick development start. You pay for the actual hours worked, while the vendor manages sick leave and holidays.
In software development, this pricing model provides consistent rates, simplifying budget planning. As a client, you can tailor your level of managerial involvement and stay in regular communication with the vendor’s project manager for updates and issue resolution.
In the complex process of software development, a single mistake can result in costly errors. While it’s impossible to eliminate all risks, a thorough discovery phase offers a clear roadmap. You perceive potential obstacles along with a systematic approach to surmount them and achieve your objective.
