During the early days of a project, the project team needs to have a ‘compass’ guiding to the effective and efficient achievement of project objectives. It is imperative to create a binding document that defines the project’s stakeholders, and outlines their needs and expectations. Hence, this document becomes the baseline to estimate high-level schedule, effort, and money required to meet stated needs before indulging in detailed requirements. Ultimately, it helps keep the team’s effort aligned with customer requirements and project objectives. This is why a well-defined Project Vision is necessary in any software development project.
The project vision can be tailored to cope with variation in industries and different levels of complexity in projects, yet, all visions share a common purpose. To be effective, the vision document should address the problem to be solved by the project and the benefits reaped from the solution. Since it is customer-centric, it must define customers and stakeholders affected by the project along with their needs. Stakeholders’ needs guide the definition of product features and set the product boundaries (scope) which helps the project team prevent scope creep.
Generally, creating an effective project vision for a software development project involves the following steps:
Step 1: Define the Business Opportunity
Briefly, the project team needs to describe the benefits reaped from completing the project. The project may result in higher competitive benchmark, or the expected annual revenues may be doubled by selling the product of the project. This step is vital to get management’s buy-in and to authorize the project.
Step 2: Define the Problem Statement
The team needs to clarify the problem that the project is intended to solve. The key points to focus on when defining the problem statement are:
- Problem description,
- Impact of the problem
- Expectations of the successful solution
Step 3: Identify Stakeholders and Users
Stakeholder analysis is critical to the success of any project. In this step, the team needs to list all parties that are positively or negatively affected by the project outcome; referred to as Stakeholders. Every stakeholder should be identified along with his/her influence, role in the project, and the mechanism to leverage or mitigate his/her influence.
On the other hand, user groups should be identified in terms of their responsibilities with respect to the system (product), the stakeholder group they relate to, and how they define the success of the solution to be developed.
Step 4: Summarize Stakeholders’ and Users’ Needs
After stakeholders and users have been defined, their needs should be understood and documented. ‘Needs’ can be discovered by understanding key problems the stakeholders experience with the existing system. It is also important to understand priorities, as perceived by the stakeholders, to solve these problems.
Step 5: Develop a Product Overview
The Product Overview defines the scope of the system and its interfaces with external parties. I personally prefer depicting the product overview using the Context Diagram, in which you can define how the system as a unit interacts with external stakeholders and users, and how information flows in and out of the system, from and to external parties.
In addition to showing how the system is related to external stakeholders, the Context Diagram can be expanded to depict the relationships amongst internal system modules. For example, to develop an Accounting System, you can draw arrows between the General Ledger module and the Accounts Payable module to show interaction.
Step 6: Define Product Features
Based on stakeholders’ needs, the project team will be able to develop the high-level capabilities of the system that will meet these needs. Each feature should describe the functionality required in the system to meet one or more of the stakeholders’ needs. For example, a need to quickly approve accounting documents can be met by having a feature of workflow capability to route documents electronically for sign-off by authorized personnel.
Step 7: List Assumptions and Constraints
In this step, the team lists all project assumptions that if changed will alter the project vision. An assumption may state that a specific version of an operating system will be available at the time of installing the system. If this assumption proves false, the vision document may need to be revised.
Besides, the project team should identify all limitations affecting the project. Constraints may be design-related, time and budget-related, environmental, or regulatory.
Step 8: Define Documentation Requirements
Depending on system complexity and customer requirements, it may be required to provide supporting documentation as part of the project deliverables. Documentation includes user manuals, online help, installation guides, and Read Me files.
When the project vision is signed off, the customer and the project team should have a clear vision of the project’s product. This document is the starting point for the Software Requirements Specifications (SRS) in which detailed requirements are articulated to meet the product features. Hence, team members should refer to it frequently to ensure alignment with customer requirements and to prevent scope creep.
