Envisioned Solution

Posted on December 4th, 2021

Part of Notes on Project Management

Because project management in IT can be volatile, the envisioned solution for a project must be clear, not only to guide future progress but also to provide an initial impression upon the end-users and stakeholders.

An envisioned solution should cover the project's goal, which asserts whether it solves the business need; and clarity, to ensure the client understands what the end-product will look like.

From this, project management can then identify what is to be done and how the work is to be accomplished, specifically:

• What is the customer's product vision?
• What is the scope of the project and its constraints (including the business case)?
• Who are the right participants to include in the project team?
• How will the team deliver the product (approach)?
• What are the high-level requirements for the system?

The What

Initial requirements envisioning is particularly important for scaling agile software development techniques to larger, more complex, or globally distributed development efforts.

The goal is to understand the requirements at a high-level, as opposed to a detailed requirements specification early in the lifecycle, i.e., the traditional and risky 'Big Requirements Up Front' (BRUF).

The Why

One reason to address the top-level requirements is to answer fundamental business questions, such as what the vision for the solution (scope), how long do you think it's going to take (schedule), and how much is it going to cost (expected budget).

Another reason is to reduce business risk, as the project requirements can be produced later (and potentially iteratively).

Lastly, any critical business issues can be clarified early on. For example, if the project team is unsure whether to implement a complex aspect of the system in-house, the requirements can document the uncertainty and address it after other aspects of the solution have been built.

The How

Usage models explore how users will work with the system, which is critical to understand what they need. These could be user-case models or user stories.

Alternatively, a domain model demonstrates the main business domains of the system and how they relate. As such, it should be a simple model, only containing the main entities in the system. Relationships should include cardinality and optionality.

User interface models are very helpful to stakeholders, as they represent how the end project could look. If they can envision the solution using it, the remaining work is simply to implement the business functionality behind it.

Regardless of the chosen model, the tool used should be the easiest. Simple models can be drawn up on whiteboards/paper, but using a more capable tool is fine if it makes life easier.