Unveiling Software Project Discovery: Methodology and Importance Explained
So far in this series, we have discussed the historical success rate of abysmal software projects and their causes and introduced the concept of project discovery to prevent software project failure.
Today, we wrap up this series by discussing in detail how we conduct project discovery at Solution Machine and how that information helps us minimize the risk of project failure. Let’s dive in!
But First, Some Perspective
Before we get into the details, however, we should talk about perspective. At Solution Machine, we believe that project discovery should be conducted by an outside party–someone who has not lived with your business problems daily.
“Hold on there,” you’re saying. “Of course, you think that. It means more billable hours for you. Why can’t I save some money by making my project discovery and then handing you the results so you can start working?”
Good question! First, it’s not about the billable hours. In fact, you will save money in the long run (not to mention time, trouble, and aggravation) by having us conduct your project discovery. We will cover that in more detail when we discuss the benefits of discovery later in this article.
But more importantly, because you are too close to the problem, so as hard as you try, you will introduce bias in both the questions you ask and the answers you give. On the other hand, we can see the situation with fresh eyes. If there is office politics putting pressure on the project, we won’t be influenced by it. We’ll ask the questions you’re avoiding. We’ll see the “red flags” that indicate an elevated risk of failure.
And, from our many years of experience with software projects, we know there’s little or nothing new under the sun. We know what made the difference between success and failure for other organizations facing the same problems you are, and we can apply that knowledge to your project.
With that out of the way, let’s get into the details of the process.
Who Is Involved in Project Discovery?
In the ideal case, when we conduct project discovery, we expect the following client stakeholders to participate, at a minimum:
- Project sponsor
- IT leadership
- Business process owners
We know that not every organization has specific people assigned to these roles. We want to discuss the project with decision-makers who have first-hand knowledge of the business problems, project objectives, IT environment, and budget.
How Discovery Is Done
Discovery is conducted as a series of sessions between the project team and client to understand the client’s business, goals, strategy, operation process, and other important information. It gathers essential project information to gain a high-level understanding of the project.
In most cases, we start with a set of basic questions, such as:
- ● What business problems (or problems) need to be solved? These should be stated concerning one or more business processes, not just complaints about the current software. “It takes too long to complete process X,” “Process Y is experiencing too many data entry errors,” and “We have too many re-work production orders because of quality issues” are all examples of business problems.
- What is the expected project outcome? This is the benefit the business hopes to realize by implementing the software solution, expressed best by reference to one or more key performance metrics. For example, increased revenue from a specific market segment, reduced user or customer complaints, shortened production cycle times, reduced employee turnover, etc.
- Who is the project sponsor? A sponsor is a person or a group that provides executive-level support and resources for the project. The sponsor can influence the project and should be included in the stakeholders’ list. It’s a big red flag if an enterprise software project has no sponsor with executive decision-making power.
- What is the project’s timeframe? The client may have a scheduled completion date, which may be dictated by legal or regulatory requirements. This constraint will determine the scope of the project in part.
- What is the project budget? This is another major constraint that will affect the extent to which expectations can be implemented. After the requirements are identified and prioritized, a cost estimate can be prepared and compared with the budget to determine the scope.
- Who is the project customer? A customer is a person or a group playing a vital role in the project’s outcome. They will be actively involved in defining the outcome and in approving it.
- Who is the end user? This may or may not be the same as the project customer. For internal software projects, the end users are the people who will use the software to do their jobs, and they must be involved throughout the project. For customer-facing software, we still expect end-user involvement—perhaps not as much as internal software, but any involvement and feedback by the actual users is better than none.
In general, these questions will involve follow-up discussions to obtain more detail. More detail (as long as it’s germane to the project) is always better than less.
Applying the Discovery Results
What do we, as a solution partner, and you, as our client, do with the information obtained in discovery?
From our side, organizing and reviewing the discovery results allows us to identify any significant risks to the project—that is, any of the causes of project failure we discussed earlier in this series. Then, we can work with the client to mitigate these risks.
In some cases, it’s clear that the organization is not prepared to embark on the proposed project. Whether it’s a lack of organizational maturity, unclear project vision or objectives, lack of executive support, or conflicting influences, we can document the issues for the client and tell them to come back to us when they’re ready. We won’t take on a project that is doomed from the start.
The parties will discuss and agree upon the project vision, objectives, and scope, assuming the significant risks are identified and mitigated. They will take the list of high-level requirements and prioritize them, usually with the most impactful items at the top. You will rarely be able to include everything you want within the constraints of the project budget, so some items will need to be deferred to a later project.
Outcomes and Benefits
At the end of the discovery process, the project team and client stakeholders should have a solid, documented understanding and shared vision for the project. They should also have a list of high-level product requirements or “user stories” that describe what the software solution should do in the ideal case. The deliverable from the discovery process is a document that guides the project.
The benefits of project discovery include:
- A comprehensive view of the project
- A clear product vision that all stakeholders agree on and commit to
- A bright-line distinction between what is and is not in the project scope
- A definition of “done”
- Documented project risks and identified mitigations to minimize them
- Clearly defined project priorities
- Detailed, optimized budget and resource estimates
- Reduced or eliminated re-work
- Elimination of scope creep
Too many projects fail because they don’t have these principles guiding them (or the principles aren’t enforced). Without them, projects go on forever (or until the money runs out), with items continuously added to the project scope and no definition of when the project is complete.
From a big-picture perspective, project discovery reduces the overall cost of success and increases your competitive edge.
How Solution Machine Can Help
Because project discovery doesn’t involve any actual software development work, it’s tempting to see it as an optional step that can be scrapped to save money. However, the risks of skipping or short-changing the discovery process are immense and echo the causes of project failure mentioned earlier in this series, including:
- Continual scope creep
- Out-of-control costs
- Missed deadlines
- Unmet expectations
Because the discovery process is essential to project success, it should not be left to chance. The team conducting the discovery should be well-qualified and have wide-ranging experience.
Solution Machine is that team. Our consultants have many years of experience leading software projects in various industries. Our tried-and-true discovery process has been sharpened by long experience. Project discovery is a foundational part of our project lifecycle; it guides everything we do in a software development project.
Contact us today to learn more about the importance of software project discovery and how Solution Machine’s discovery process can keep your project on track.