Tantalising Project, Vision Document

What, Why, How.

​A 1 ​to 2-page document, describes the high-level objectives. 

Strong project definition focuses upon users and or customers and helps avoid project creep. The vision is the bases for team alignment as to the effort and resources required and the possible trade-offs if the project is to be delivered.

Project vision crystallises the justification, schedule, costs and implementation assumptions. A strong vision can be the difference between success and failure as the document describes what has been agreed and why. In effect its becomes the basis for a contract.

​Example template

  1. ​Business Requirements. Talk to stakeholders. Those who have a clear sense of ​​why the project is being undertaken and the ultimate value it will provide, both to the business and to users. ​

​a.    Background rationale. A brief description of when and why the project became recognised as a necessity.

b.    Business Opportunity. Describe the opportunity that exists or the business problem that is being solved. What are the alternative solutions and why the selected choice is attractive?  Identify the problems that cannot currently be solved without the project, and how the solution fits in with organisational objectives.

c.    Business Objectives (quantitative and measurable) for example, revenue or cost savings and measurable success criteria. Internal and external factors likely to have the greatest impact on achieving success.

d.    Customer needs, problems that are not yet met or solved by existing or market alternatives. Identify how the product would be used with current hardware, software. The required interface or performance requirements. List functional requirements.

e.    Business risks associated with developing this product against adopting a market solution such as timing issues, user acceptance, implementation issues, or possible negative impacts on the business. Estimate the severity of the risks and identify any risk mitigation actions that could be taken.

2. A vision of the Solution. Define a long-term vision as to why the system is to be built and what business objectives are resolved. This vision will provide the context for making decisions and shouldn’t include detailed functional requirements or project planning information.

a.    Vision Statement summarises the purpose and intent and describes what the world will be like. It should be grounded in the realities of existing or anticipated customer markets, IT architectures, organisational strategic directions, and cost and resource limitations.

b.    Major features list the major features of the new product, emphasising those features that distinguish it from previous or competing products. Specific user requirements and functional requirements.

c.    Assumptions and Dependencies identify and document assumptions that were made when conceiving the project. Note any major dependencies the project must rely upon for success, such as specific technologies, third-party vendors, development partners, or other business relationships.

3. Scope and limitations (features and requirements). Define the concept, range and limitations proposed by the solution. Inevitably during development changes will be proposed. This document can be used to evaluate whether changes are within scope. If changes are agreed then budget, schedule and or resources may need to be reconsidered.  

a.    The scope of initial release describe major features and quality characteristics that will enable the solution to provide the benefits intended. Focus on those features and product characteristics that will provide the most value, at the most acceptable development cost, to the broadest audience.

b.    The scope of subsequent releases identifies features to be deferred to later releases.

c.    Limitations and exclusions categorise product features or characteristics that a stakeholder might anticipate, nonetheless are not planned to be included.

4.    Business context summarises business issues, for example, include profiles of major stakeholder categories, assumptions that went into the project concept, and the management priorities for the project.

a.    Stakeholders are individuals, groups, or organisations that are actively involved in a project and are affected by its outcome or can influence its outcome. Segment stakeholders. Identify the segment interests in the product. What value or benefits they seek. Their attitudes and any constraints that must be accommodated. Doing so reduces the likelihood of unexpected requirements arising.

b.    Example of stakeholder value include:

i.    improved productivity

ii.    reduced rework

iii.    cost savings

iv.    streamlined business processes

v.    automation of admin workflows previously undertaken manually

vi.    ability to perform entirely new tasks or functions

vii.    conformance to current standards or regulation changes or improved usability or reduced frustration level compared to current applications.

Stakeholder

​Main Value

​Attitudes

​Major Interests

​Constr​aints

Executives.

​Increased revenue

​See solution improving room turnaround times by 25%

Integrates with Office 365; minimal training if any.

​Maximum budget = £50k.

​Departmental heads.

​Fewer delays in room turnaround.

​Highly receptive, but expect high usability.

Automatic work assignment; ease of use; high reliability.

​Must run on low-end multiple devices.

​Employee.

​Quick access to data.

​Resistant unless product is finger stroke-compatible with current system.

​Ability to easily report maintenance issues; or pass room to reception; easy to learn.

​No budget for retaining.

​c.    Project Priorities. Define the project’s, priorities, requirements, schedule, and budget. Identify key drivers (top priority objectives), constraints to work within, and dimensions that can be balanced against each other to achieve the drivers within the known constraints.

Dimension.

​Driver (state objective).

Constraint (state limits).

Degree of Freedom (state allowable range).

​Schedule

​Release 1.0 to be available by 1/Jan, release 1.1 by 1/Dec.

​Features

​70-80% of high priority features must be included in releaese 1.0

​Quality

​90-95% of user acceptance test must pass for release 1.0, 95-98% for release 1.1

​Staff

​Maximum team size is 2 developers + 4 testers.

​Cost

​Budget overrun up to 5% acceptable without executive review.

​5.    Operating Environment. Describe the environment in which the system will be used. Define the major availability, reliability, performance, and integrity requirements. This information determines the system’s architecture. Consider questions such as:

​a.    Are the users widely distributed geographically or located close to each other? How many time zones are they in?

b.    When do the users in various locations need to access the system?

c.    Where will the data be generated and used? How far apart are these locations? Does the data from multiple locations need to be combined?

d.    Are specific maximum response times known for accessing data that might be stored remotely?

e.    Can the users tolerate service interruptions or is continuous access to the system critical for the operation of their business? What access security controls and data protection requirements are needed? Does head office require remote access?

Read part one linked article 

​click here...

About the Author Christopher Bird

Building your own Power App, BI solution, or automated workflow can be a mind-blowing experience. It can also be a nightmare. Particularly when you begin with a blank screen. My advice, get professional help as and when you need it. That's what successful people do.

follow me on:
>