Want to build software that delivers value on a reasonable budget, stays on track, and fits your business strategy? A thorough project Discovery Phase will give you the answers you need most.
According to McKinsey, 45% of IT projects exceed their budget, and 7% exceed planned time constraints. This signifies poor strategy development at the initial stages.
Intellectsoft’s expertise in conducting the Discovery Phase for system engineering and project management helps you avoid costly mistakes and achieve project success. Learn more about the benefits and deliverables in the article below.
What is the Discovery Phase?
Before learning the intricacies of the project Discovery Phase, you need to make sure you know which “neighborhood” you’re in. When looking for answers online, you can come across a range of various definitions that have nothing to do with the Discovery Phase concept that you really need to know.
Let’s just clarify that, in this article, we are going to talk about the Discovery Phase as part of the system architecture conducted by your software engineering partner, Intellectsoft. We will also look at the alternative definitions from the Project Management perspective so that you know the difference.
In the first case, the Discovery Phase encompasses the primary step of the Solution Architecture lifecycle (Lovatt, 2021) that creates a foundation for a successful solution. In this context, it typically includes three major types of activities:
- Fact-checking. Thoroughly studying all architectural inputs that are relevant to the problem area.
- Engaging stakeholders. Identifying people relevant to the solution scope and their responsibilities.
- Establishing Success Criteria. You’ll never know if the solution turned out well if you don’t set expectations, assessments, and success criteria beforehand.
Inputs to these activities: architectural artifacts, stakeholders register, business case. If some critical information is unavailable, the Discovery Phase has to be extended to cover investigation and modeling. Existing artifacts like business requirements are also subject to reformulation and modification if key stakeholders deem those insufficient.
Deliverables: technical approach outline, system design outline, project planning roadmap, wireframes, and prototypes.
Important Differences
In our customers’ internal business processes, the Discovery Phase in project management involves identifying the business value of some idea. Thus, the major deliverable is the business case. More often than not, we cover the system architecture concept of the Discovery Phase because customers prefer to create their business cases internally (since it depends on many organization-specific and sensitive data).
The primary role of the business idea justification is defining a dominant business objective. This could be a market demand, organizational need, customers’ request, technologically competitive edge, social responsibility, or legal requirements. Whatever the purpose, a project needs some rationale to begin with.
Deliverables: Business case/plan, current vs. future state, return on investment; list of prequalified vendors, predetermined clients, preexisting contracts, capital expenses (CapEx), and operational expenses (OpEx) plans.
In this scenario, the main deliverable (business case) outlines the scope, audience, and purpose of the proposed work and establishes the value it could bring. A well-researched business case can show that a project is worth the investment. It is a strategic document.
Consequently, here Intellectsoft steps in on the next phase (which traditionally could be called the Initiation phase), where we define success criteria, preliminary scope and requirements, high-level risks and assumptions, summary milestones, summary budget, and key technical stakeholders, create a stakeholder register, develop a responsibility assignment matrix, establish communication channels, begin records management, review existing artifacts, determine a solution design, define access requirements for project work, obtain charter sign-off, and perform kickoff.
How to Plan a Discovery Phase of a Project?
Discovery Phase planning at Intellectsoft is adjusted to every individual request. Instead of proposing cookie-cutter solutions, we emphasize quality and usefulness, even if it’s a preliminary system design outline. That’s why, after the initial internal discussion, we allocate resources to cover the full-scope Discovery Phase. If we are working with the existing client, the planning phase can be very fast because we already know the artifacts and the current state. However, if we are working with a new customer, the planning process may take up to a few weeks.
Of course, there is also a standard process at play; for example, our project Discovery Phase normally starts with activities like:
- Preliminary meetings with a customer,
- Interviews with stakeholders,
- Contextual research,
- Documentation study,
- Review of preexisting processes.
Once we have a general understanding of the scope of work, we are ready to dive deeper and work on discovering appropriate technological solutions to the project in question.
Sometimes, when technical stakeholders say planning, they also mean all the activities of the actual, ongoing Discovery Phase of a project. So, just to clarify, all the processes of brainstorming and creating supporting documentation throughout the already initiated phase can be referred to as Planning.
What Are the Discovery Phase Deliverables?
Below are examples of Discovery Phase deliverables that might be associated with software development projects. Note that it greatly depends on the customer and the particular objectives. For larger projects and sometimes for venture series startups, more paperwork is involved.
Existing Artifacts Review
Artifacts are tangible items, like documents or products, that were previously made and are available at the time the project Discovery Phase starts. For example, we might ask to review the business case, current project documentation or previous designs, and so on. Without understanding what you already have, we won’t be able to make informed conclusions and outline of what needs to be done next.
If we are to build a complex system, we might ask to clarify your relationship with current or future clients, vendors, etc. Preexisting contracts might affect how the system needs to be shaped, e.g., what business processes and logic to include.
You might supply such artifacts as a master service agreement (MSA), statement of work (SOW), or terms of reference (TOR).
Capital Expenses vs. Operational Expenses Assessment
Budget allocation is usually the customer’s call, but when we see room for optimization, we offer guidance. For instance, in heavy equipment facilities, projects often involve both operational expenditure (OpEx) for software, which doesn’t appreciate or depreciate, and capital expenditure (CapEx) for durable assets like equipment, which are taxed and appreciate/depreciate over time. In such cases, we suggest ways to leverage technology to increase the value of those durable assets and lower OpEx, ultimately boosting ROI.
Example
A client needs software for monitoring ice melting that might result in spring flood damage to a city at the foot of the mountain. The problem is that the visualization quality is poor, so the client is considering a multi-million dollar investment into cloud-based data processing architecture that improves quality with AI. We analyze their situation and point out that improving the physical layer (OSI Layer 1) by ensuring a clear line of sight between transceivers, along with minimum loss of local connectivity on Layers 2 and 3, could achieve similar, even better results faster and at a lower cost.
Therefore, we’d advise enabling VLANs to isolate network traffic throughput and introducing QoS routing. Then, we could suggest lightweight software specifically designed for handling interference, phase delay, and signal loss issues to avoid operational lags. We would also ask questions about how satisfied the client is with the current data processing algorithms because GIS is known to work with huge amounts of data, so before doctoring that with AI, it is necessary to make sure that we do not work with erroneous and poorly pre-processed data in the first place (which can be achieved by well-known mathematical algorithms and quickly done using existing libraries). This software might focus on key data points and visualization techniques optimized for the available bandwidth, delivering clear visuals more reliably.
Note: The low-level software solution will depend on various factors like the facility’s specific needs, the type of wireless system, and the desired data representation. This example aims to illustrate the principle of offering software alternatives that capitalize on improved hardware conditions instead of relying solely on “fashionable” cloud solutions that don’t necessarily address the core problem.
Because capital assets will benefit the organization for years after the project ends, they may be sourced from the organization’s budget, not the project’s. That is often a point that needs to be escalated to a higher level of negotiation.
Current State vs. Future State / Gap Analysis
Here, the analyst will create a contrast-and-comparison table of the current state of project solutions vs. the desired improvement. While these statements should be clear and concise, they should not focus on either the technical or implementation aspects of the issues.
For example, instead of mentioning the future state as “Sales team is migrated to This CRM Brand,” it is better to write “Sales leads are increased by 30%.” Particular solutions to the future state will be designed at a later stage of the project Discovery Phase.
This document can focus on gaps, bottlenecks, and weaknesses in current processes, such as lack of automation or missed revenue caused by outdated software. Growth of business operations might also go here, as it is an opportunity for improvement.
Interface Inventory, IT Asset Inventory
Naturally, any solution has multiple components at different levels of interaction and communication with each other. By creating an interface inventory, we are clarifying our understanding of the solution architecture and, therefore, can refer to it when deciding on the implementation roadmap priorities.
We document details like:
- Name of the interface
- Source
- Destination
- Rules and other events
- items exchanged, including any supporting information
- Workflows, itineraries
- Pre- or post-conditions.
Same goes for IT assets. We want to itemize all the physical and non-physical digital entities such as networks, servers, workstations, databases, and so on.
Project Charter
Usually developed by the PM during the Discovery Phase of project management, this document is the cornerstone of the project and its main point of reference. It defines the reporting structure for decision-making, as well as the project’s purpose, goals, objectives, requirements, high-level assumptions and constraints, high-level risks, success criteria, a summary milestone schedule, key stakeholders, a summary budget, and an initial key stakeholder register. The project success criteria, which serve as a benchmark for the quality of the produced outcome, are also included (Heldman, 2022).
Risk Assessment
Discovery Phase of a project also highlights possible issues and high-level solutions that are possible to suggest based on existing knowledge.
The basic version of the document is usually an executive summary that provides a top-level synopsis of the problem, the proposed solution, the justification, and the expected benefit, but it skips the analysis behind these decisions. That analysis, along with the estimates of financials, would be included in the more in-depth version of the risk assessment. Depending on the size of the project, it could include the following elements:
- Problem statement: Description of the issue.
- Analysis: A root cause analysis or any other analysis that predicts the outcome of the stated issue.
- Recommended solution: The solution that was analyzed as most likely to succeed
- Proposed solutions: Alternative approaches to the recommended solution, their strengths and limitations.
The initial risk assessment documents are typically reviewed, refined, and formalized in the project charter.
Preliminary Scope Statement
Outlines the tasks to be done and specifies what’s not part of the project. It’s often called the big-picture scope.
A PM looks at the charter’s requirements and makes a detailed scope statement during planning. This statement gets added to the scope baseline and lists the individual tasks needed for the project. However, the charter’s scope is preliminary until more analysis is done.
Usually, it describes the project, what needs to be delivered, how it will be accepted, important points in the timeline, and what’s not included in the project.
Solution Design Outline
Solution architecture is often the most anticipated part of the project Discovery Phase. Everyone wants to know the architect’s vision of how to build the solution to estimate what it would take to make it a reality.
Determining which solutions are needed and how they will interact with existing infrastructure is what our architects want to show. We also want to plan for the future, making this solution maintainable and scalable to support the business’s growth.
The solution design process has two main outputs: a high-level conceptual design and a low-level technical roadmap.
Technical Roadmap
Our tech team, including the architect, developers, UX designers, and more, are the main stakeholders for this document. They want to outline the low-level tech details, such that are specific enough to put into sprints and iterations.
Importance of the Discovery Phase
The Discovery Phase activities target a primary goal: developing a conceptual design for part or all of the project. The proposed solutions must align with our customer’s business requirements, therefore addressing business needs and opportunities.
It might be one of the most challenging parts of the solution design pipeline because we need to showcase the value of our proposed design without going into too much detail. It is important to keep an open mind and stay away from specifics because doing so might result in focusing on logical conclusions rather than premises. On the flip, more investigation and flexibility down the pipeline typically result in better working systems.
Importantly, the conceptual solution outline ideally holds the core logical reasoning, which can be extended into and connected to all further levels, down to the physical. Due to the nature of modern system architectures, the level of technological volatility might be high, so making a high-level solution outline ensures that we will not make premature decisions that will have to be redone further down the line. It is essential to acknowledge that the solution architecture life cycle exhibits a high degree of parallelism and iterative refinement based on accumulating knowledge.
Discovery Phase Best Practices
Adhering to industry-wide standards such as ISO/IEC/IEEE is considered the best practice in the project Discovery Phase. Some of the activities described in these guidelines include the following.
Gathering Architecture Inputs
A number of factors determine whether useful architecture artifacts are available at the start of the project Discovery Phase:
- Architecture maturity: whether architecture practice is established and working well in the organization or enterprise and if there is an efficient repository of artifacts that can be easily accessed and in which it is easy to find relevant artifacts.
- Overlap with current problem area: if the new problem to be solved is in an area or operational domain that has never been addressed before, there will be fewer relevant artifacts.
- Clarity of understanding of the current problem: if the focus of the problem is too broad or ill-defined, it is harder to distinguish relevant artifacts, and too many irrelevant ones may be included as inputs.
The main product of this activity is a catalog of relevant architecture artifacts for the operational domain of the solution vision. At this stage, it is not necessary to examine the artifacts in detail, but it is important to identify them and know they are available when needed.
If the artifacts are organized in a repository, then more details will be available, such as:
- Date of production and modification
- Version number
- Owner
- Business area
- Related artifacts that would be impacted by change, and any dependencies.
It is also useful to record the reason for selecting this artifact by linking it to an element or concept in the problem domain.
Defining Stakeholder Engagement
According to ISO/IEC 42010:2011 and TOGAF definitions, stakeholders are individuals, groups, or organizations having an interest or concern in a solution. They can be internal or external.
Beyond just listing stakeholders, we can also create a stakeholder communication plan that expands on the level of involvement in the solution architecture process, responsibility matrix, methods of communication, deliverables, etc. Usually, that level of detail is more important in enterprise projects and can be omitted in startups and SMBs or ongoing agile processes.
Refining Business Requirements
Project success criteria are not possible to draw without prior documentation of business requirements. The logic here is simple: if all the requirements are met – the project deliverable is considered successful. Alternatively, the success can also be judged from the perspective of project constraints like time and resources – in this case, their optimization would imply high-quality results.
Further down the line, business requirements also become a basis for us to create a solution design proposal and a roadmap outline. Keep in mind that if we are adopting an Agile methodology, business requirements might come and go as the project evolves.
The documenting process is sometimes more complex than writing something like “Ok so my idea for a project is this…” If we are taking the business value seriously, our business analysts need to go through several stages:
- Capturing: listing requirements, plus simple yet actionable explanations.
- Validating: checking for completeness and correctness.
- Verifying: testing requirements to see if they are the best option, checking for conflicts and overlaps.
The resulting requirements catalog might include:
- Name of the business requirement;
- ID;
- description;
- Justification;
- Category;
- Status;
- Change control details.
The requirements catalog is useful for tracing how business requirements become system or data requirements. It can also be used to check if the business needs to consider additional operational measures such as new SLAs.
To document business requirements, we might interview stakeholders, review existing artifacts, or even make new ones (such as use cases, user stories, data models, etc.)
Creating Solution Proposal
At this stage of the project Discovery Phase, we are approaching the most interesting part – describing and illustrating our vision for the solution. We need to focus on core models without swinging away into specifics that could potentially lead us astray. So here we are showing the essence of the design, not constrained by jumping to conclusions or step-by-step plans yet.
If there are several good alternatives, we might propose more than one solution for a customer to choose from. It is also important to come to an agreement between all the stakeholders at this stage.
Visuals
Complex tech solutions really come alive in stakeholders’ imaginations once they are presented visually. For that, we can use a variety of mediums:
- Diagrams, charts, graphs, maps
- Wireframes
- Design mockups
- And more!
Our objectives here are to abstract high enough from technical buzzwords, convey meaning, and, ultimately, obtain stakeholders’ approval.
Supporting Artifacts
Nice visuals are fun, but stakeholders want to understand how the solution addresses their area of business. For that, we dive deeper into supporting artifacts.
For example, a sample high-level architecture definition:
- Outlines the infrastructure layer that an application will be built on top of
- Depicts main components together and highlights proposed building blocks
- Specifies relations and interactions between subsystems
- Defines security boundaries and considerations
- Declares data types and their storage approaches
- Determines application resiliency and failover processes
- Highlights the insights of the middleware layer
- Illustrates the principles of scaling and load balancing of the system and its components.
- Indicates observability functionalities and toolset
- Marks out external interfaces and integration capabilities and approaches
Project discovery phase might result not only in the collection of information but in the true discovery of requirements that stakeholders didn’t know before. That is why, to clarify our solution ingenuity, it’s useful to maintain artifacts like traceability/cross-reference grids where we show the links between the initial idea and its evolution path, providing explanations for the variations.
Outlining the Step-byStep Plan
At this stage, we collect all the artifacts we obtained or produced before and go down the rabbit hole of the specifics. We are scoping the solution, analyzing interfaces and risks for smaller deliverables (like features), looking at the tech stack options, and offering a high-level step-by-step plan.
Scope Definition
After choosing a solution, we formalize its scope by detailing changes in each business area, specifying their nature (new, existing modification/removal/replacement), and linking them to relevant architecture documentation. This ensures clarity and avoids conflicting efforts throughout the solution’s lifecycle.
Building Block Analysis
Building block analysis helps identify reusable components within the organization and assess their suitability for the solution. It creates a solution-building block model detailing each component’s name, category, ownership, current state, and required modifications.
KPI Documentation
Before initiating the project, we need to formalize our acceptance criteria with stakeholders. What is considered successful? What is considered done? What are the key metrics that we are striving for? What is the logic behind deciding what’s good and what isn’t? All that needs to be described at the stage of documenting KPIs.
Most often, the KPI documentation types will depend on methodologies and stakeholders involved.
Examples of KPI documentation:
- Budget (cost performance, cost variance, planned value, etc.)
- Performance (schedule performance/value, resource capacity/velocity, stories in development, tasks reopened, changes accepted, burndown, cumulative flow, code coverage, etc.)
Wrapping Up
Discovery Phase is one of the most exciting stages in software development. It is the time to be creative and to attempt to save the world by visualizing how your solutions will positively impact the global landscape. Whether you are an aspiring startup or an international enterprise, Intellectsoft offers a variety of Discovery Phase packages to suit your needs.
We’ve built software for train passengers, enabled multilingual communications, streamlined investment decision-making, and even helped to build cities. With a diverse experience under our belt, we confidently scale ambitious businesses that want to embrace digital evolution in all of its beauty and power.
Create high-end software solutions for your company with Intellectsoft
Get in touch
Subscribe to updates
Source link
