About us > Our work methodology > How we define what to do

How we define what to do

It is important for us to clearly understand what you want to do. We usually like to put this on a Project Vision document. Customers often think that, as we developers we are not interested in the business background for a project. Well, not only we are very interested but we strongly need to know all the aspects of the business related to a project in order to understand the project and to make key decisions in the design and implementation stage of the development cycle.

A Project Vision document contains all available thinking about what a project will be. It defines the goals of a project, why they make sense and what the high-level features, requirements or dates for a project will be.

The most important points to cover in the Project vision are:

• Vision Statement. This is usually a once sentence that describes this specific release of the project. This is also known as the problem statement because usually projects are planned to solve a specific problem.
• Project Goals. Describe how this project contributes to the goals of the organization, customer or final user.
• Business Opportunity. Describe what is the current business situation, what users' or customers' needs are not being satisfayed, what competitors are doing or offering and how we can change the world with our solution.
• Users Description. Describe who are the customers, what problems does this software solve for them and why they would use or buy the software.
• Stakeholders Description. Who are the stakeholders (people with power on the project but not necessary the users/customers) and what role they have in the project.
• Product Features. This section describes the high-level features for the system. We prefer not to employ use cases here because they are too detailed and usually people reading the Project Vision just want a short overview identifying the key functions. User stories could be a list too long to describe in the Project Vision. That's why prefer to write it as a list of features. It is important to differentiate between essential features (priority 1) and desired-but-not-essential (priority 2).
• Other topics could be Risks and Assumptions being made and Dependencies on other projects, companies or organizations.