Why are you running so fast when you don’t know where you are going? – German proverb
 |
Have you ever had a project where everyone is busy, busy, busy, but they are going in different directions? Months have passed, there have been countless meetings, there seems to be no real decision maker, volumes of requirements have been written, millions of dollars are spent, but it doesn’t seem like the project is even close to meeting the scheduled due date nor in meeting the expectations of the stakeholders. Such projects suffer from MAZE (Maximum Activity Zero Effect). |
All too often, software projects spin out of control. In many cases, one of the root causes is the lack of an agreed upon Product Vision (aka Vision or Product Requirements Document). As a result, the project team does not have a good understanding of the problem to be solved, the project may not align well with the business objectives and it may lack consensus from the key stakeholders. These are then manifested in common project failure symptoms such as: lack of direction or project churn, unknown business acceptance criteria, inability to measure progress, and budget/schedule overruns. Longer term, the lack of a Product Vision may result in poor planning, poor architecture and poor design decisions.
The reasons for skipping this crucial step in the process are the same reasons given for other project deliverables, which often include such comments as: “there isn’t enough time“, “the Business Case is good enough“, “the stakeholders don’t know what they want“, “it’s not my job“, “we can’t ask the users, we are too far down the road”, or “we’re doing Agile”. Although, there certainly have been software projects that have been successful without developing a Product Vision, the potential quality, budget, schedule overrun risk is greatly reduced by investing a little effort up front. The time and cost of developing a Product Vision buys stakeholder alignment, provides clarity of prioritized requirements at the highest level, and sets the team direction early on in the project.
In an Agile environment, even though the goal is to deliver the best value with minimal waste, it does not mean less software engineering. It means better software engineering with higher responsibility, authority and accountability, leading to a waste-free workflow while meeting the business objectives. Because Agile enterprises take a leaner approach, generally with artifact-light development practices, articulating the Product Vision to the agile development teams becomes even more critical since it communicates the strategic direction.
An even more costly problem is realized when the product that is developed does not align with the business needs or objectives. This often leaves IT arguing that they delivered a product, however, the business is not able to fully utilize the end product or it is discarded all together. As a result, the project ROI is not realized.
The remainder of this article will provide an overview of the Business Vision and the Product Vision and the reasons why they are both essential to successful product delivery.
Overview of the Business Vision and the Product Vision
 |
“Good business leaders create a vision, articulate the vision, passionately own the vision, and relentlessly drive it to completion.” – Jack Welch |
The Business Vision and Product Vision are both living documents that certainly have value beyond the scope of a project. They provide strategic direction, define needs, articulate desired outcomes and identify key stakeholders. There still remains a close relationship in that the goals and objectives found in the Business Vision may necessitate the inception of many projects over time to fulfill those objectives. In turn, one or more projects may drive features in a Product Vision. However, the author, scope, objectives, target audience, and level of abstraction remain significantly different between the Business Vision and Product Vision. The table below details some of the differences.
| Business Vision | Product Vision | |
| Author | Business Owner or Business Analyst | Systems Analyst or Requirements Specifier |
| Scope | 2-4 year business unit level | Single software application |
| Target Audience | Executive Management, Business Owners, Enterprise Architects | Solution Architects, Developers, Testers, Project Managers |
| Abstraction Level | Business level | Software application |
| Input To | Business Process Re-engineering / Automation, Project Inception: Business Case, Project Charter | Software application development |
The features of a software product, defined by the Product Vision, should align indirectly with the objectives in the Business Vision. Features delivered by a product should automate steps in the business, and therefore, should be in support of one or more business capabilities defined in the Business Architecture Document. The creation or enhancements to a product are driven by a project (funded effort) where the scope is defined by the Project Charter. Each tactic would require a business case to secure funding to execute on the tactic. The project is the execution of the tactic.
Business Vision
 |
“There is no more powerful engine driving an organization toward excellence and long-range success than an attractive, worthwhile, achievable vision for the future, widely shared.” — Burt Nanus, Visionary Leadership |
The Business Vision is a description of what senior management wants to achieve with the organization in the future. It is usually written for a medium to long term time frame, such as 2 to 4 years, and is often expressed in terms of a series of objectives. It captures the goals and objectives of the business.
The objectives provide input to the project-approval process so, therefore, should align with the Business Case as well as the Product Vision document. It communicates the fundamental ‘why’ related to the project and is a guide for future decision validation. The Business Vision should be updated as the understanding of the goals and objectives evolves.
The Business Motivation Model (BMM) describes the Business Vision as the future state of the enterprise, without regard to how it is to be achieved. The Business Vision is an overall image of what the organization wants to be or become. It usually encompasses the entire organization and is long-term in its perspective. [1]
During the 1980s and 1990s, many companies wrote mission or goal statements vowing to “meet or exceed customer expectations”. Unfortunately, few companies improved their understanding of the customer’s expectations or what the customer valued. Or, if it was done, it was only done once. How many customers have the same expectations as they did 5 years ago? What about from two years ago? For example, as a customer, have your expectations shifted when buying a cell phone over the last 5 years? How about over the last two years? The things that were ’customer delighters’ just a couple years ago are now ‘customer expectations’.
Business goals need to be relevant, actionable, and achievable. When using fuzzy goals such as to “meet or exceed customer expectations” or “improve efficiency” it is difficult to measure progress toward that goal without measureable objectives being defined. By tracking changes in customer needs and requirements a company can meet the on-going stringent demands of the customer.
Tragically, many business decisions are still being based on opinions, assumptions, and highly influenced by the most vocal of the business stakeholders. By clarifying what measures are key to gauging business performance, then applying data and analysis, you can build an understanding of key goals and objectives. By taking this approach you can optimize results and build products that meet the measurable business objectives and acceptance criteria.
Good business practices dictate defining goals, reviewing them frequently, setting clear priorities, and focusing on problem prevention versus firefighting. Being proactive is a starting point for effective change. Reactively bouncing from crisis to crisis makes you very busy, giving a false impression that you’re on top of things, when in reality, it’s a sign of a manager or an organization that has lost control.
To facilitate such a disciplined approach the OMG BMM provides a meta-model with which you can capture what the business wants to accomplish (vision, goals and objectives) together with how it will be accomplished (strategies and tactics). Definitions follow along with an example of how a consulting company might define their Business Vision.
| Definition: | Example: |
| Mission: Indicates the ongoing operational activity of the enterprise. The mission describes what the business is, or will be doing, on a day-to-day basis. A mission makes the [Business Vision] operative – it indicates the ongoing activity that makes the [Business] Vision a reality. A mission is planned according to strategies. | Provide skilled consultants that deliver superior quality results that meet or exceed customer expectations. |
| Goal: A statement about a state or condition of the enterprise to be brought about or sustained through appropriate means. A goal amplifies a [Business] Vision. That is, it indicates what must be satisfied continually to effectively attain the [Business] Vision. |
|
| Objective: is a statement of an attainable, time-targeted, and measurable target that the enterprise seeks to meet in order to achieve its goals. |
|
Definitions follow with examples of how a business unit may define their strategies and tactics to align with the goals and objectives of the Business Vision.
| Strategy: One component of the plan for the mission. A strategy represents the essential course of action to achieve ends, goals in particular. A strategy usually channels efforts towards those goals. |
|
| Tactic: A course of action that represents part of the detailing of strategies. A tactic implements strategies. |
|
Developing a clear Business Vision is key to balancing competing stakeholder priorities.
Using the BMM for business modeling along with traceability between the business requirements and the things that fulfill them will provide the information necessary to answer these important business questions:
- Which goals have no quantifying objectives?
- Which objectives are not supported by any strategy?
- Which objectives, strategies, tactics are affected if this goal changes?
- Do the goals align with the mission?
- Are the new goals and objectives realistic and possible to accomplish?
Product Vision
 |
“If software developers built bridges, we’d show up at the site with some scrap iron and say, ‘let’s start building!’” – Reuel Alder, a manager at the STSC.
“Vision without execution is hallucination.” – Thomas Edison |
The Product Vision is developed in support of automating business capabilities. The Product Vision’s statement articulates a long-term view of what the product will accomplish for its users, captures very high-level requirements and design constraints, and gives the reader an understanding of the system to be developed. It should include a statement of scope to clarify which capabilities are and are not to be provided by the product. The Product Vision document(s) is created early in the project, and it is used as a basis for the first draft of the Risk List, and for the Use Case Model.
When all participants understand the shared vision and are working toward it, they can align their own decisions and priorities (representing the perspectives of their roles) with the broader team purpose represented by that vision. Without this product vision, the business value of a solution will lean toward mediocrity[2].
In the event that the Product Vision does not exist, it would be in the best interest of the systems analysts or requirements specifiers to remedy this situation. Doing so will help them to understand the product better and increase their own credibility, since then they will become business advocates rather than just a translator for system application specifications.
When a software project begins to go wrong, the first response is usually to demand extra effort from the development team to pick up the slack. Many of these teams manage to work wonders, working extremely long hours to deliver software to meet critical business needs. But the worst kind of problem, one that can cause a project to fail completely, is one that no amount of heroics can possibly fix. The worst problems occur when a project team is building the wrong product in the first place. The only way to avoid that problem is to make sure that everyone involved is in full agreement as to what is needed and what the project team is trying to build. The process of developing a Product Vision for a software application brings everyone into agreement as to what constitutes success for the project.
The contents of a Product Vision are illustrated below in an example.
| Stakeholders: Who are the users of the system? Who else will be affected by the outputs that the system produces? Who will evaluate and bless the system when it is delivered and deployed? Are there any other internal or external users of the system whose needs must be addressed?Who will maintain the new system? |
|
| Need: Describes the key needs that the stakeholders and users perceive the product should address. It does not describe their specific requests or their specific requirements, because these are captured in a separate stakeholder requests artifact. Instead, it provides the background and justification for why the requirements are needed. |
|
| Problem Statement: The outcome of the above needs assessment is the Problem Statement. Generally written as:“The problem of [describe the problem]affects [who are the stakeholders affected by the problem] the impact of which is [what is the impact of the problem] a successful solution would be [list some key benefits of a successful solution].” Search for root causes, or the “problem behind the problem”. | The problem of: untimely and improper scheduling of consultants affects: our customers, customer support representatives and service technicians.The impact of which is: customer dissatisfaction, perceived lack of quality, unhappy employees and loss of revenue.A successful solution would: provide real-time access to a resource management database to facilitate dispatching of the appropriate consultant to those locations which need their skill set. |
| Features: The features should align with the business goals and objectives. Features are the high-level capabilities of the system that are necessary to deliver benefits to the users. To effectively manage application complexity, it is recommended for any new system, or an increment to an existing system, capabilities are abstracted to a high enough level so that no more than 25-99 features result. These features provide the fundamental basis for product definition, scope management and project management. |
|
| Constraints: List all constraints that the business must operate under. These can include legal, regulatory standards, quality and safety standards. Constraints are not related to fulfilling the stakeholders’ needs; they are restrictions imposed on the project by external forces. |
|
Success criteria, or acceptance criteria, should be defined for the product. This is defined in measureable terms of what must be done for the product to be acceptable to the business, stakeholders, and end-users who are affected by it. The criteria may be derived from the Business Case or the customer’s quality expectations. The criteria needs to be realistic. For example: High quality, early delivery and low cost may be conflicting goals. Criteria that might be considered are things such as: target dates, major functions, capacity, accuracy, availability, reliability, appearance, development cost or time, security, or defects. Success of the product should be judged in relation to the objective and measureable criteria established by the stakeholder’s expectations soon after the project’s inception.
Developing a clear Product Vision is a key to balancing competing stakeholder priorities and will answer these questions:
- What is the “problem behind the problem”?
- Who are the stakeholders?
- What are the constraints to be put on the system? Are there any political, economic, or environmental constraints?
- What are the key features of the system?
- Will the features solve the problems that are identified?
- Are the features consistent with constraints that are identified?
- Will the features meet the needs of the stakeholders?
- How will product success be defined?
- Can the features be traced to the business capabilities in the Business Architecture Document?
Conclusion
If we understand that the vision of the business drives the automation of the business process, and that the vision for the software product defines the requirements necessary to automate the step in the business process, then we can see how the purpose and scope of the Business Vision and Product Vision differ significantly yet they provide strategic direction, define needs, articulate desired outcomes and identify key stakeholders.
End Notes:
Some wonder:
- If I have a Project Charter, do I need a Business Case?
- If I have a Business Case, do I need a Product Vision?
The Business Case and Project Charter significantly differ in scope from the Visions in that their purpose is to define a funded and time boxed effort to deliver a specific solution. The key difference between the Business Case and the Product Vision is that the Business Case considers all options for solving the problem, without delving too deeply into the specifics of any single solution, except for the advantages, disadvantages, and costs. The Product Vision assumes that you have decided to conduct the project, it also defines at a management level how the product mission has been accomplished. The following briefly describes the differences.
Business Case
The business case provides justification for business improvement efforts. It includes an analysis of business process performance and associated needs or problems, proposed alternative solutions, assumptions, constraints, and a risk-adjusted cost-benefit analysis. It is typically authored by a business owner. In a mature organization this solution would directly align with the business objectives that have been set forth in the Business Vision. Therefore, the Business Vision drives the business needs and the necessity to secure project funding to provide a solution for that need.
The Business Case answers:
- What overall problem would be solved by the project’s results?
- What would happen if a decision not to pursue the project were made?
- Are there other alternatives to spending funds on this project?
- Could the same solution be obtained from a Commercial off the shelf (COTS) product?
- How do the costs of the COTS solution compare to the custom solution?
Project Charter
The PMBOK describes the project charter as “a document that formally authorizes a project.” The project charter defines a consolidated and summary-level overview for a funded and staffed initiative to provide a solution to a business need. Often a collaborative effort between the business owners and project managers, the charter provides the purpose, objective, scope, assumptions/constraints, team roles, schedule and desired outcomes. The charter, developed at the inception of the project, serves as both a quick reference guide and an executive summary that the project team can reference as a guide throughout the life of the project.
The project charter answers the following questions:
- Who is the project sponsor?
- Why is this effort being undertaken?
- How much will the project cost?
- What are the key deliverables?
- Which roles and responsibilities are needed?
Resources:
Below are the sources referenced for this paper:
- OMG BMM Specification
- IBM Rational Software http://www.ibm.com/developerworks/rational/library and Rational Unified Process
- From Business Strategy to IT Action, Robert J Benson, Thomas L Bugnitz, Willliam B Walton
- Managing Software Requirements, A Use Case Approach, Dean Leffingwell, Don Widrig
- The Six Sigma Way, Peter S Pande, Robert P Neuman, Roland R Cavanagh
- CrossTalk, Delivering Quality Products That Meet Customer Expectations, Louis S. Wheatcraft
- Project Management with the IBM Rational Unified Process, R. Dennis Gibbs
[1] The Business Motivation Model (BMM) is an OMG Specification (www.omg.org/spec/BMM/1.0/PDF) for support of business decisions about how to react to a changing world.
[2] Microsoft Solutions Framework (version 3.0):
People Process Tools Blog 
Leave a comment