The Business Value-Oriented Principles©
(BVOP^™)

Business Value-Oriented Principles (BVOP) is a modern extension for managing organizations, projects, products, and people.

Business Value-Oriented Principles (BVOP) can be followed directly or modified according to the needs and general awareness of the management roles of organizations. BVOP enhances organizational practices and human culture, and trains people on productivity and responsibility.

BVOP's primary goals are to add business value to products, services, or processes, to optimize waste and to improve and develop people’s skills and organizations continuously.

Introduction

People, processes, priorities, and products are valued equally, and no subject matters more than the others. Adding, modifying, adapting, removing processes, roles, or practices is accepted, but the main focus on people, processes, priorities, and product equality remains. Focus on people and products, for example, should not be sacrificed for profit, priorities, and processes. People, in turn, need to follow organizational priorities, understand all the risks, and develop responsibility and proactiveness.

How can BVOP help organizations, people, products, and projects?

Following BVOP can produce the following benefits:

• Increased productivity
• Increased levels of customer satisfaction
• Increased motivation and satisfaction of employees
• Respect between roles and people
• Transparency of organization and processes
• Sharing knowledge
• Improved skills
• Improved organizational image
• Improved internal culture of the organization
• Shorter time-to-market cycles

The four dimensions of the Business Value-Oriented Principles

BVOP’s four dimensions are people, processes, priorities, and products.

People

People are a major resource for organizations. They are the fuel for the business engine and affect the image of organizations. They have needs, lives, emotions, and beliefs that can fluctuate.

BVOP states that people need to be open and responsible and understand what they do very well in detail.

Regarding the employees, there are certain personal and work matters that need to be satisfied. In order to do so, the organization provides the necessary resources to ensure motivation and productivity rates.

People need to have self-awareness and constantly develop their personality and skills. They embrace guidance, training, teaching and respect time, resources, plans, and strategies.

People are collaborators. They value organizational support and, at the same time, are ready to contribute with their skills and knowledge to process improvement, product quality, skills, or information sharing. They have answers to the following questions:

How can I help the others around me?

How can I support the whole organization?

Processes

All processes (within an organization) can be considered as formal events that follow predefined and planned steps.

Processes can be beneficial and, at the same time, can endamage the organization if they are not optimized enough or their performance is poor. Damage may be invisible for the organization if key roles in the departments and teams aren’t sufficiently aware of potential losses in matter of productivity, efficiency, financial resources, or quality.

An organization may waste time, financial resources, or suffer from high turnover rate. Processes can cause damage if not analyzed, optimized, and appropriated for the business model, production line, culture, internal and external environmental factors, customers, products, contracts. If employees disagree with certain processes this could cause them to quit. Overwhelmed or poorly executed processes can even push clients away.

Organizations following the BVOP should periodically inspect their processes and modify them if the need for change is identified.

People at all levels within the organization may need to monitor and evaluate ongoing processes in which they participate and identify gaps so that corrective actions are implemented promptly.

Excessive process overload can lead to wasted time, resources and general stress, while failure to control processes can lead to chaos and productivity deflation.

Priorities

Priorities are essential for every organization. Organizations following the Business Value-Oriented Principles define their priorities carefully considering the other dimensions.

Everyone in the organization may need to understand its priorities.

Some of the priorities of the organizations may include:

• Market expansion
• Territorial expansion
• Band image improvement
• Employee satisfaction
• Customer satisfaction
• Third-party satisfaction
• Increase in profit
• Products usage increase
• Social impact
• Political impact

Products

The classic understanding of a company's products is public services or products promoted, and internally acquired or developed assets not released to the market or intended for internal usage.

Products are usually the main source of income for many organizations and are major assets that require investment. 

Product development can be a complex and time-consuming process that involves many experts and skills, and requires efforts in areas such as markets and customers (users) research, testing, development, marketing, sales, procurement, supply, legal, financial operations.

The process of developing a product usually meets the needs of the business, the resources, the time available, the customer’s needs, the technological constraints and the high-quality standards. There is a need for trade-offs in terms of investment, constraints, quality, and customer expectations.

The product must generate enough revenue for the organization. The time and resources for its development are planned and limited, but at the same time, it must meet the expectations of the users.

BVOP advises products’ development to meet the most important consumer needs before investing in additional features. This approach aims to deliver products quickly to real users so that early result analysis can be done, and future planning is more realistic. Parts of products that are of no value to customers should not be developed.

BVOP extends the understanding of organizational products to include valuable resources, possessions, or tools used by the organization. Software, databases, tools, or anything that brings business value to the organization can also be considered products.

Organization-owned products that add business value may have been intentionally or unintentionally created by third-party organizations or may have been developed by employees for their own use.

Examples of internal organizational products may include:

• Automated software or tools that speed up the process, production, or development.
• Databases used by the organization for administrative or other business purposes.
• Documentation used by employees or other related parties.
• Open-source software created by employees.
• Other acquired products or services used by the organization that add value.

Products that produce business value for each dimension may need additional support if they are beneficial for long-term use, or if the products can add more value in terms of efficiency, productivity, cost, and quality.

Products and Projects

Products and projects have a common understanding in the context of BVOP. The result of continuous efforts on a project is the actual development of a product that is intended to be used by an audience.

A project consists of all the initiatives and activities necessary to develop, improve, or adapt a product or multiple related products that have a common goal.

Product management in the context of BVOP is all the effort, all the activities, and processes required to create a product intended for use by an audience.

The main objectives of product management roles in the context of BVOP are:

• Establishing research, design, development, and test practices tailored to available resources, people, materials, time.
• Collect realistic data for the intended audience of the product.
• Validate all collected data, test prototypes and products for the needs of the audience.
• Creating the most valuable product features in the early stages and then focus on less important features if the audience or other parties need them.

Understanding project management in the context of BVOP is the overall related effort, all the activities and processes required to create a product and deliver it to the intended parties.

The main objectives of project management roles in the context of BVOP are:

• Completing the workload in the given time frame.
• Finishing work and product delivery with estimated financial and material resources and available workforce.
• Meeting quality expectations upon product delivery.
• Supporting products and delivery teams.
• Optimizing processes and practices and eliminating waste.
• Delivering potential business value to all project activities.
• Prevention of project risks.

Business Value is a common and widely used term covering many topics related to the general well-being of organizations, economic factors, products, customers, projects, and management models.

The business value in the context of Business Value-Oriented Principles (BVOP) refers to adding positive effort to:

• Organizational culture
• Human Relations
• Relationships between business and people
• Employee attitude, skills, and maturity
• Human Resources
• Work processes
• Contributing
• Time-to-market
• Reducing waste
• Shortened production processes
• Usability, utility, and value of products
• The satisfaction of users and clients
• Innovation

The BVOP states that adding an effort to any of the topics listed may positively affect others, therefore increasing the overall value of the organization and its products.

Business value can be added by anyone involved in organizations, their products, and projects.

Major examples of added business value

• Organizational culture provokes people to be proactive, contribute, share, and be aware of the business goals of the organization.
• Modernization and innovation.
• People in the organization respect each other and work productively.
• The high turnover rate is limited to a minimum
• Conflicts and negative environments are minimized.
• The organizational brand image grows.
• Everyone in the organization continually improves their personal and professional qualities.
• Team members seek and eliminate impediments without waiting for management to do so.
• Management and team members work together in optimizing processes and speed up development time.
• Costs are managed and carefully planned.
• Tools and environments are improved continuously.
• Unnecessary documentation, processes and communications are avoided.
• Root causes of issues, defects, and impediments are analyzed, tracked, and eliminated.
• Quality standards are followed and met without a significant waste of time and resources.
• Overwork is managed, and teams do not spend too much time on trivial tasks.
• Documentation and requirements are created and maintained in an easy and comfortable style, so everyone understands them with ease and saves time from unnecessary discussions and misunderstandings.
• Meetings and discussions do not lead to a waste of time and always lead to desired results.
• Product development focuses on the most important goals and needs.
• All outcomes, concepts, and product versions are validated with real users, and the risk of an undesired product is limited.
• Customers' and users' satisfaction continuously grows.

Waste

The BVOP focuses on eliminating waste in all offices, products, projects, and processes within the organizations.

The Business Value-Oriented Principles include the following areas:

• Business Value-Oriented Program Management
• Business Value-Oriented Project Management
• Business Value-Oriented Product Management
• Business Value-Oriented People Management
• Business Value-Oriented Priorities

Business Value-Oriented Program Management (BVOPGM) is a set of activities and a style of planning, evaluation, and management that focuses on adding business value to the organization, project management, and people.

Activities of the Business Value-Oriented Program Management

Activities of the Business Value-Oriented Program Management (BVOPGM) Office may include:

• Program definition and evaluation
• Defining program benefits
• Analyzing projects dependencies
• Program planning
• Program risk management
• Program stakeholders management
• Program resources management
• Choosing management and development methodologies and practices (realizations sets)
• Modifying or combining realizations sets
• Presenting realizations sets
• Training other roles
• Observing efficiency
• Adjusting realization sets
• Maintaining a knowledge database of lessons learned
• Sharing knowledge with other roles
• Supporting other roles
• Monitoring and controlling program execution

Program definition and evaluation

As an initial step, program definition may include listing and describing all projects included in the program. Afterwards all projects must be evaluated on criteria such as:

• Organizational goals
• Ethical standards
• Cultural specifics of the organization
• The attitude of organization’s members
• Third parties interests
• Political factors
• Legal issues
• Authorities regulations
• Economical factors
• Social acceptance
• General feasibility

Evaluation may require information requests from different stakeholders, sponsors, internal and external parties, or authorities. Concerns from key personnel and particular departments are taken into account. Research and analysis of market climate, competition, potential users, financial, and economic factors may also be required for valuable program evaluation.

Defining program benefits

The benefit of the program is an abstract understanding of the overall benefits of all projects within the program. Any project planned for development (development or acquisition) should be potentially valuable to the organization or other financial or non-financial stakeholders.

The basic understanding of a financial benefit is when all investments in the project are returned, and the organization also expects additional profits. Another financial benefit may be obtaining funds or minimizing costs.

If non-financial benefits are obtained, then the organization might not have returned their investment but gained other benefits such as:

• Improving organizational image
• Political impact
• Social impact
• Stakeholders satisfaction
• Satisfying customers
• Increased employee engagement
• Technology improvement
• Improved performance indicators
• Productivity improvement
• Process improvement
• Future risk reduction

Dependencies amongst the projects need to be identified, described, and understood by the entire BVOPGM office and the Business Value-Oriented Project Management (BVOPM) office if they need to be aware of them. Major dependencies may include:

• A sequence of projects-realizations
• A sequence of external activities not related to actual planned work
• Utility of materials and tools
• Stakeholders availability and involvement
• Workforce availability
• External parties availability

A sequence of projects-realizations

The realization (development) sequence of each project may be crucial for the success of the entire program. If project “Y” really needs project “N” to be created first and depends on it, logically project “N” is created before project “Y”

If projects do not depend on each other, and the organization has enough resources, they may be simultaneously developed.

A sequence of external activities not related to actual planned work

Important external project activities that define projects’ dependencies may include:

• Hiring professionals 
• Training sessions
• Materials and tools supply 
• Maintenance
• Sales and marketing activities
• Procurement
• Logistics

The sequence of all activities may be important.

Usage of materials and tools

Teams and parties may need materials and tools at the same or at different times.

Stakeholders availability and involvement

The availability and involvement level of stakeholders may differ. Different parties may be interested in particular projects and be available at specific times.

Workforce availability

The availability and the schedule of internal and external teams, consultants, or contractors may need to be considered in defining projects dependencies.

External parties availability

The availability of external parties like authorities, suppliers, providers, and supervisors has to be considered when projects dependencies are defined.

All defined constraints and dependencies between projects need to be taken into account in the program planning activities.

Considerable program planning activities may include:

• Prioritizing projects for realization by business value and dependencies
• Defining the high-level scope of the projects
• Analyzing and planning resources
• Projects realizations planning
• Planning milestones
• Communication planning
• Escalations planning
• Projects release planning

Prioritizing projects for realization by business value and dependencies

Based on the dependencies between projects and their business value, prioritization is the first needed step.

Prioritization ensures clarity on the projects’ importance of implementation and requires planning, investment, and general focus.

Defining the high-level scope of the projects

The scope of each project needs to be described as high-level, which sets the basis for a more detailed assessment of further project management activities.

Analyzing and planning resources

The status* of the current materials, resources, tools, and people need to be identified.

*The status is an abstract term defining the condition, quality, capacity, availability, motivation, skills, attitude.

The current availability of materials, resources, tools, and people needs to be identified.

If the program requires additional resources or workforce, the organization defines them and plans the necessary provisions.

Projects realizations planning

May include high-level planning of estimated resources and the time needed to complete projects.

Planning milestones

Important events may need to be defined, described, and scheduled. Such events may include:

• Gathering requirements
• Scope finalizations
• Approximate time for project initiation
• Design phase initiation and completion
• Development phase initiation and completion
• Releases of product samples
• Testing or validation phase initiation and completion
• Repairing defects initiation and completion
• Acceptances initiation and completion
• Major Releases
• Deliveries
• Marketing campaigns

The planning of project realizations, resources, budget, and milestones should take into account phases that may go beyond predicted time frames such as testing, validating, defects repairing, and acceptances. These considerations are valid for both program and project management activities, and as a result, buffer time may be needed between different phases and milestones.

Communication planning

The communication process is critical during the entire program planning and its realization.

Program communication planning may include:

• Defining communication needs
• Establishing a communication channel for program and project management
• Communication needs with other roles of the organization
• Escalations planning
• Planning communication needs and channels with external parties

Defining communication needs

Defining communication needs may include:

• Defining all communication topics like meetings, status reporting, tests, risk discussions, resources, projects release planning, etc.
• Defining, and concurring on the importance level of topics.
• Agreement on communication frequency and details.

Establishing a communication channel for program and project management

Program and project management roles have to discuss, agree, and establish their communication channels, which include the physical environment, software, or technologies.

Communication needs with other roles in the organization

May include defining and planning communication needs with roles outside of the program and project management offices.

Escalations planning

Emergent issues and incidents may need immediate attention and actions. Escalation planning may include:

• Defining parties and roles that may be involved in emergent issues.
• Training parties and roles of the importance of the escalation process.
• Training parties and roles in proper and fast reacting.
• Preparation of potentially needed instructions and references required for different types of issues.
• Preparing potentially needed environments, tools, software.

Simulations or potential scenarios may also be conducted if such may be predefined as part of the escalation planning and training.

Planning communication needs and channels with external parties

All external parties interested in the program need to be involved in the communication. Channels and frequency of communication need to be defined and agreed on between all parties.

Projects release planning

Projects release planning may include:

• Defining all roles involved in project releasing and their responsibilities.
• Defining and describing the steps needed for every project release.
• Defining resources, materials, and tools needed and planning their provisions.
• Testing and analyzing the status of current tools, environments, and materials.
• Notifying all potentially involved parties of the plans, procedures, tools, environments, and materials.
• Potential training.
• Preparing all documentation templates that may be needed.
• Defining and planning post-release needs and activities.

Program risk management may include:

• Risk identification of all projects
• Risks prioritization
• Potential project risk influencing other projects
• Risk avoidance planning
• Risk owner assignment

Risk identification of all projects

High-level or detailed risk identification for all projects in the program may require the prediction of possible risk occurrence during and after project realization.

The risk may be detailed with the participation of all project management roles if there are multiple roles assigned to the program.

The risk can be divided into separate themes (risk items) and added to a common project risk list for the entire program.

Risk identification for all projects can be carried out in advance, and if multiple teams work on multiple projects simultaneously.

If teams work on projects consecutively, detailed risk identification can also be carried out in sequence. Still, initial and high-level risk factors (items) need to be identified in the early stages.

Project risk management details are included in the Business Value-Oriented Project Management (BVOPM) section.

Risks prioritization

Risk items may be prioritized, so that the most likely to occur scenarios (items) are placed on top of the program risk list. They require more observation, discussions, prevention planning, and efforts during the realization of the project.

Potential project risk influencing other projects

The BVOP states that if a risk may have an impact on other projects, it needs special attention. Such cases need to be identified, emphasized, and prioritized in the risk list (the collection of all risk items).

Participation of all teams (and their management roles) that work on projects potentially affected by the same risk is required for risk avoidance.

Risk avoidance planning

Every risk needs an avoidance plan. The avoidance plan for each risk item is defined by the management roles assigned to the project with the participation of team members who have direct relevance to the risk item.

Risk owner assignment

Each risk item needs an assigned owner that is usually an individual or multiple individuals working on the project or specific tasks of the project. They have the needed competence and knowledge about the subject related to the risk.

Risk owners observe early risk symptoms of their assigned risk items, avoid occurrences, collaborate with project management roles, other key roles, and stakeholders in order to avoid or minimize the risk impact.

Multiple risk owners are assigned when a risk influences a number of projects.

The Business Value-Oriented Project Management section introduces detailed Project risk management principles and practices that may be applied on a program level as well.

Stakeholders are considered to be individuals, a group of individuals, and all other internal and external parties of the organization that may influence the program or be influenced by its realization positively or negatively.

Stakeholders generally expect a positive result from the program, its projects, or parts of the projects.

They may provide valuable input for the program and projects at the early stages or during the program realization.

Stakeholders may be the primary source of defining program and projects' scope and requirements.

Stakeholders can be investors or their representatives, other external parties, clients, partners, authorities, internal organizational members.

Program stakeholders management may include:

• Identifying stakeholders
• Analyzing stakeholders
• Stakeholders engagement

Identifying stakeholders

Identifying stakeholders may include collecting stakeholders' names, contacts, information, and predicting the influence they might have on a program.

Analyzing stakeholders

Analyzing stakeholders may include understanding their needs, expectations, interests, competency, and concerns.

The BVOP suggests that the validity of the stakeholders' input during stakeholder engagement should be analyzed. The information they provide may not be valid to the organizational, business, or market needs. Program, project, and product management roles are responsible for validating stakeholders' input.

Stakeholders may have different interest levels towards a program, project or initiative. Their willingness for collaboration may also vary.

Unmanaged and dissatisfied stakeholders or such with low interest may be considered as a major risk for disturbing the program or projects' success.

Stakeholders engagement

Stakeholders engagement is important for the program and project realizations, and it may relate to:

• Establishing trust between stakeholders and program and project management
• Establishing and maintaining transparency about  information, risk, and outcomes
• Persuading them to provide accurate, adequate and timely information as well as assistance
• Communicating the right information
• Consulting or interviewing
• Presenting information and projects outcomes
• Negotiations

Resources may relate to finance, environment, safety needs, professional human skills, materials, information technology, tools, databases, and other physical or nonphysical assets needed for the realization of the program.

The Business Value-Oriented Program Management (BVOPGM) office estimates and allocates resources during the entire program realization, which may lead to involvement in:

• Planning, estimating and requesting financial resources
• Planning, estimating and requesting physical or nonphysical resources
• Planning and requesting new personnel recruitment
• Planning and requesting training
• Withdrawing resources from a project or entire program
• Allocating resources across projects

Program, project, and product management roles collaborate for proper resources planning, as well as estimate and eliminate waste.

Cross‐functionality of the teams

The BVOP focuses on the general cross-functionality of the teams working on a single project. Cross-functional project teams are a major factor for the successful project realization. Such teams usually include people with different expertise and work together for accomplishing common objectives.

If a project consists of a team with the entire needed skill sets, the general productivity may be higher than the ones often relying on external support.

Team members of the cross-functional teams need to share information, collaborate, work together, and support each other.

Program and projects continuous assessment

Periodically all projects and the whole program need to be evaluated. If the entire program or its projects require significant resources and time to complete, market, user, and business needs may change as the projects are completed.

Once any changes have been identified, projects and the entire program need to adapt.

Resources supply 

Projects may need an additional supply of resources over time. If initiatives are assessed as successful and teams or tools need additional resources, the BVOPGM office usually plans and requests more specialists joining the teams, as well as financial resources, technologies, tools, or software.

The BVOPGM office chooses management and development methodologies and practices (realization sets). Choosing realization sets is collaboratively consulted with stakeholders, project management roles, and project team members.

The BVOPGM office may rely on project and product management roles and development, quality assurance, operations, as well as and other teams to choose realization sets. In such a scenario, the BVOPGM and BVOPM offices, all teams, departments, and parties involved in the projects need to agree and understand the benefits of the decisions.

Different projects may follow different realization sets if this does not harm the goals and strategies of the BVOPGM office.

Realization sets (project management, product management, product development practices, etc.)

Realization sets may include practices related to:

• Project management
• Product management
• Marketing
• Design
• Usability
• Development
• Quality assurance
• Deployment and delivery
• Support

Requesting support, advice, and knowledge from different professionals assigned to a project or from external parties interested in the project increases the transparency and the efficiency of the custom realization sets and helps to fill in gaps. Different parties may share valuable information about their work, problems, and needs. 

Modifying or mixing realizations sets

When realization sets are discussed and agreed upon, the Business Value-Oriented Program Management (BVOPGM) office needs to apply changes before the project starts.

Presenting realizations sets

Modified realization sets need to be clear and comprehensible to everyone involved in the program. Presenting and discussing the modified realization sets to all involved parties and teams is a method for their validation. Feedback is expected, and non-efficient topics and potential modifications need to be discussed.

Training other roles

All changes and modifications of the realization sets need to be shared with all involved parties and teams.

For example, if risk management is excluded from the project management practices because it is defined as time-consuming, everyone that might be affected should be aware of its removal. They need to know why this is done, what process could replace it, and what are the potential negatives.

Full understanding of practices and realization sets may improve the overall teams' productivity.

Observing efficiency

Observations of realization sets and the actual outcomes are important activities during the realization of the project.

Subjects of observation

Observation needs to be a valuable activity, and waste should be avoided. The exact subjects of observation need to be defined.

Subjects of observation may include:

• Productivity
• Time-to-market
• Defects
• Product feedback
• Attitude
• Interactions
• Third parties

Productivity

Team productivity is not a fixed and standard value that may be easily measured and tracked. Setting objectives and analyzing results may be an approach for measuring the relative and general teams' productivity.

Setting objectives for projects, teams, and individuals and comparing them to actual results may reveal topics for analysis and discussions.

The amount of completed work for a defined period of time may be a simple approach for tracking teams' productivity.

Team members who encounter issues with their productivity should report the potential reasons to management roles.

Time-to-market

Time-to-market may reveal organizational and teams' maturity and the efficiency of current realization sets. 

Defects

Fluctuations in the number of defects and their types over time may reveal an improvement or downfall in current realization sets.

Product feedback

During approval sessions or demonstrations, feedback from clients, end-users, and different stakeholders is collected. These parties are a source of valuable information that may be used for analyzing and inspecting current realization sets.

Attitude

The general attitude among people inside the organization is another source of valuable feedback about realization sets.

Interactions

Observing the interactions between people inside the organization may provide information about general knowledge sharing, operations, speed of processes, and outcomes.

Third parties

Observing third parties and their position on the current realization sets, principles, practices, and culture may be a valuable asset.

Adjusting realization sets

Adjusting realization sets after certain periods of observations may be needed in order for their efficiency to improve. Adjustments are based on the results from observations and discussions with all key roles involved in the program or in specific projects.

Maintaining knowledge

Valuable information and lessons are collected after every observation, modification, and adjustment of the realization sets.

The BVOPGM office needs to document, collect, store, analyze, and share valuable lessons regularly. 

Spreading knowledge

The BVOP suggests that the lessons learned should not be withheld. Sharing them with all teams and individuals is necessary, so that methodologies, practices, processes, and people evolve together.

Supporting other roles

Supporting other roles may increase the general organizational and program’s business value. That may be accomplished by answering important questions on time, by providing information, training, education, coaching, advise, or any other activity that may have a positive impact on teams, processes, and projects.

The BVOPGM Office regularly monitors the transparent board of project issues that is accessible to all project members and contains regular updates on issues, people, tools, and processes. The BVOPGM Office supports the solutions for the issues and directs them to other offices, roles, or parties.

Monitoring and controlling program execution may need the following activities:

• Identifying deviations from initial planning
• Prevention of current and potential issues
• Controlling costs
• Teams’ management
• Teams’ motivation
• Risk observation
• Change management
• External parties management

Identifying deviations from initial planning

Milestones, estimated cost, quality expectations, and others may deviate from the initial plans over time. The Business Value-Oriented Program Management (BVOPGM) office needs to identify all deviations that occur in the projects throughout the entire program.

Project management roles are actively involved in project deviations identification.

Prevention of current and potential issues

Prevention of existing and potential issues is an important activity related to eliminating waste. 

Key factors for the prevention of current and potential issues may be the regular discussion of project risks, high communication activity, team responsibility, and stakeholders’ involvement.

Controlling costs

Programs and projects may be tied to estimated budgets. Expenses that do not add business value to the projects are identified, discussed, and their potential reduction may be planned and executed.

Teams’ management

During program realizations, project teams may face a variety of difficulties like:

• Personal conflicts
• Team members leaving the organization or the project
• Organizational issues impacting the teams
• Team members initiating disruptive actions
• Communications issues
• Environmental or technical issues
• Inadequate or insufficient information 

Team behavior, work, communication, productivity, ethics, and interactions need to be monitored and controlled, and current or forthcoming issues need to be resolved.

Teams motivation

Teams may face a drop in motivation based on different factors. The BVOPGM and BVOPM office representatives need to track fluctuations in motivation and take action. These activities may need to be accomplished with the assistance of the Business Value-Oriented People Management (BVOPPM) office.

Risk observation

The entire program’s risk and the risks of all projects need constant observation. Early symptoms are monitored and discussed. The potential risk needs to be prevented with the assistance of the BVOPGM and BVOPM offices, and the key roles of each project team.

Change management

Program and projects needs, scope, and requirements usually evolve with time, based on different factors like:

• Changed organizational needs
• Changed business needs
• Changes in organizational members, stakeholders, and other internal and external parties
• Changed authorities regulations
• Changes in markets and competitors
• Changes in users needs, behavior and expectations
• Technical feasibility
• Project team members skills
• Obsolete and unnecessary requirements
• Previously incorrectly defined requirements
• Defects that occurr in realization stages

The BVOPGM office needs to have a clear picture of all factors that may cause potential changes. Corrections in scope, requirements, configurations of teams, planned resources, schedule, and realizations sets need to be applied at the early stages.

All required changes in projects need to be analyzed, discussed, and assessed against the validity and real needs. Identified changes in scope, requirements, and estimates are documented, prioritized, and planned for realization if they are assessed as valid and needed.

All parties involved and interested in the projects are informed of the changes and updated plans.

External parties management

External parties that are not involved in the program may need to receive information about milestones, the overall realization of projects, and financial status frequently. They are also required to provide information, assistance and/or feedback.

Agreements, contracts, services, and specific events may be important for the fast and reliable realization of the projects.

All activities of the BVOPGM office may be applied on a project level by representatives of the Business Value-Oriented Project Management office.

Combination of offices and activities

For any number of reasons, an organization may choose not to maintain the program management office, as a result, the BVOPM office executes the needed activities. Under these circumstances, the BVOPGM and BVOPM office are considered as one combined office.

Strategies of an organization may include maintaining only program management roles, where program managers are responsible for multiple projects and all project management activities.

Depending on the organizational portfolio, missions, strategies, structure, and other specifics, the Business Value-Oriented Product Management (BVOPDM) office may also be included in the combined office. In this instance, management roles should be able to perform program, project, and product management activities and need to possess the knowledge and skills to do so.

Mixing and merging offices, roles, and activities may be part of the strategies when organizations have limited resources, and classical management roles are obscured. Such roles in the project realization process are replaced directly by organizational executives or other multifunctional figures. 

Organizations may try to accomplish maximum results with minimum resources and roles involved. The BVOP supports the idea of combining roles and suggests that multifunctional and advanced figures inside organizations need to understand all activities and principles of the business value-oriented program, project, and product management.

Business Value-Oriented Project Management (BVOPM) is a set of activities and a style of project management with a focus on adding business value to the project management processes and practices, general productivity, outcomes, and waste reduction.

The BVOPM office may be independent, part of the BVOPGM office, or both may be considered as one, depending on the organizational structure and strategy.

Activities of the Business Value-Oriented Project Management

BVOPM accentuate on the following major activities:

• Documentations management
• Product management
• Scope management
• Planning
• Project risk management
• Time estimation
• Waste management
• Decisions making
• Execution
• Business value points measurement
• Attitude management
• Defects analysis
• Observation and optimization
• Program management participation
• Support
• Project closure
• Management of the Transparent board of project issues

Documentation management may include creating and maintaining documentation and ensuring its quality.

Documentation creation

Depending on the projects, organizational, legal, or structural requirements, the Business Value-Oriented Project Management (BVOPM) office may need a different set of documents.

Project management documents

A project may need different documents, reports, templates, logs, analysis, and many other extensive preparations, activities, and tools. Some of the popular traditional project management documents are:

• Project Charter
• Project Plan
• Project Status Report
• Work Schedule
• Work Breakdown Structure
• Gantt Chart
• Timesheet
• Communication Plan
• Change Management Plan
• Change Request Form
• Stakeholder Management Plan
• Human Resources Management Plan
• Cost Management Plan
• Risk Management Plan
• Project Budget
• Statement of Work
• Stage end Report
• Project Team meetings log
• Lessons Learned log
• Daily log
• Post Implementation Review
• Project Closing documents

Project Charter

In general, this is an outline of the scope, objectives, business needs, high-level budget, high-level risk, and participants in a project. This document outlines in advance the roles, responsibilities, and objectives of the projects. It also identifies key stakeholders and defines the authority of the project manager.

Project Plan

The project plan presents planning assumptions and decisions, facilitates communication between project stakeholders, documents approved scopes, costs, and schedules.

Usual topics in the project plan may include management of:

• Scope
• Requirements
• Schedule
• Finances
• Quality
• Resources
• Stakeholders
• Communications
• Project changes
• Risk
• Procurement

Project Status Report

It is usually used to regularly update the project team, sponsors, stakeholders, and customers on the current status of the project. It may contain general information, costs, finished and unfinished tasks, issues, resolutions, risk, further plans, etc.

Work Schedule

It may present standard workdays, holidays, non-standard working times, tasks, and assigned resources.

Work Breakdown Structure (WBS)

Hierarchical decomposition of the entire project into small components, tasks, goals, phases, and deliverables. It is usually a tree structure that shows a subdivision of the effort needed to reach a goal. The WBS is a useful tool for visualizing the needed work and may facilitate budget, time, and resources planning.

Gantt Chart

It is a type of bar chart that illustrates a project schedule and shows the dependency between activities. The Gantt Chart presents the tasks of the project on a vertical axis, and the time required to perform each task is visualized on a horizontal axis.

Timesheet

Usually contains the amount of a worker's time spent on each task.

Communication Plan

May contain information about communication channels, participants in planned communication, common topics for discussion, and frequency of events conduction. It may be a part of the general project plan.

Change Management Plan

Lists activities or roles that will require additional focus during the implementation and control phase of a project. It may contain plans for a change of any kind, procedures for responding, and integrating change.

Change Request Form

May contain the desired changes in the current scope, process, product, and the involved in the change roles, resources, needs, risks, etc. This form can be filled by external parties, internal teams or project management roles and delivered to others for approval, review, or planning.

Stakeholder Management Plan

Describes how stakeholders will be involved in the project. It may include their needs, concerns, limitations, the ability to influence the project, contact information, role, and other specific information. It usually contains only stakeholders with a high interest in the project.

Human Resources Management Plan

The Human Resource Management Plan usually sets out how human resources for the project should be defined, controlled, and managed.

Cost Management Plan

The cost management plan is an outline of the project estimation, allocation, and control of the costs of the required resources, so all project activities are eventually implemented.

Risk Management Plan

Possible risks, causes, and consequences may be included in this plan. Various responses to different risks are usually pre-defined.

Potential responses to risk may be:

Avoiding – The management and teams change plans to avoid a problem.

Mitigate – The management and teams try to reduce threat impact.

Accept – Accepting the negative impact.

Transfer – Outsource risk to third parties that can manage it.

Project Budget

It may include a breakdown of all project costs, potential future costs, eligible costs, etc.

Statement of Work

Statement of work is a document that may present legal relationships and may serve as a contract between a client and a service provider. It may contain a scope of work, a period of providing a service, deliverables schedule, applicable standards, acceptance criteria, etc.

Stage end Report

It contains information about the progress of the project up to a date and topics requiring discussion or approval, as well as recommendations for the next steps that may also need approval. It may also include a review of the business case, achieved benefits, expected future benefits, deviations from plans and agreements, review of team performance, etc.

Project Team meetings log

Key points of team meetings, decisions, and topics may be documented for future reference.

Lessons Learned log

In the course of the project work, teams usually learn important information that can be documented and used for future projects.

Daily log

It is usually an informal document containing significant events, problems, decisions, and other topics from the current day.

Post Implementation Review

Describes the status of the project and whether the objectives have been achieved. It is usually created in the final phases of the project and may include feedback from independent parties.

Project Closing Documents

Collection of documents or a single document containing a list of points that should have been executed. The project sponsor, project manager, quality manager, and other roles can participate in completing and signing the document.

The BVOP recommends a careful approach to the creation and maintenance of documentation of all kinds, as these can be heavy and time-consuming processes that can cause waste. The BVOPM office defines which documents need to be maintained and their exact use, formalities, and details.

Creating and maintaining customized documentation may be a flexible and advisable approach to documentation management. Adherence to classic and traditional documents can bring both advantages and disadvantages. The BVOP suggests that creating and maintaining a large collection of documents may cause waste if they are not used or do not add any business value to the project. Their content needs to be clear and short enough and at the same time cover important topics. They have to be understandable by everyone that may require, read, maintain, and use them.

Poor quality documentation may cause waste in different areas of project delivery, product management, and development, such as:

• Time waste
• Costs waste
• Development waste
• Delivery and implementation waste

Time and costs wastes are usually obvious and logical, but development and delivery waste is a topic that needs attention.

Poor documentation is considered to be:

• Not well readable
• Contains very long content that is not helpful and requires a lot of time for processing
• Outdated and misleading
• Not related to the project needs
• Missing

Poor documentation may lead to not needed or incorrect development outcomes. If development teams do not fully understand the documentation or if it is confusing, they may spend time developing unrequired or incorrect parts of the product. It can also be a cause of a poorly executed project or an inaccurate product as a whole.

Documentation management also includes creating, maintaining, requesting and sharing documentation intended for research, development, support, marketing, and for all other teams, departments, and parties involved in the project, and product.

The BVOPM office facilitates and supports documentation practices, as well as evaluate them based on business value and status.

Project management and product management in the context of the BVOP are related and overlapped subjects and activities. 

The term “project” refers to all activities and resources that are needed for creating, implementing, or supplying a specific product or multiple products. The “product” is a material, virtual, or any other beneficial outcome that is used by an audience, or parties who may benefit from it in any way.

The product life cycle and the project life cycle may share common timeframes, resources, and goals. The development of a product may be bound to the project cost, time, resources, and quality variables. Delivery of a project in this context may mean that a product is being developed.

For successful project management, a tight connection and participation between product management and product development may be required.

The Business Value-Oriented Project Management (BVOPM) office needs to understand all activities of the Business Value-Oriented Product Management (BVOPDM) office and to have in-depth knowledge of product management. Additional competencies are required for adequate decision making, supporting, optimizations, and any other activities of the BVOPM office.

Major product management activities of the BVOPM office may include:

• Product stakeholders and users management
• Product risk management
• Participation in decisions
• Product support activities
• Adjustments in product management

In the early stages of planning the entire product, its vision, and features, defining stakeholders and searching for proper potential users or customers who may provide valuable information about what needs to be developed may be an extensive and challenging process.

Careful analysis and filtering of the stakeholders and user input is a critical initial stage for the entire future development.

Stakeholders and users management activities may include:

• Defining stakeholders and users.
• Management of research sessions.
• Management of remunerations.
• Management of tools and environments.

Defining stakeholders and users

The Business Value-Oriented Project Management (BVOPM) office collaborates with the Business Value-Oriented Product Management (BVOPDM) office in defining and evaluating stakeholders and users.

Management of research sessions

Collecting information, conducting interviews, surveys, focus groups, or other activities requires time and attendance for anyone involved in the research process. Plans, schedules, and agendas may be needed. The BVOPM office supports these activities.

Management of remunerations

If the participants in the research sessions are external individuals or organizations, their remunerations may need to be calculated and planned.

Management of tools and environments

The collected information or the process of information collection may require special needs. Planning and providing the appropriate tools and environments according to the current organizational resources is needed for optimized and productive initial stages of product research and development.

Product risk management is different from project risk management. In many organizations and initiatives, the product risk is not in focus, not managed at all, or key roles are not even aware of it.

While the classical project risk management usually focuses on the scope, cost, legal, time, incidents, management support, and communications issues, the product risk management in the scope of the BVOP focuses on what exactly is being developed and its public presentation to the intended audience.

If the product is weak or failing, this may be considered as a more negative outcome than poorly planned and managed project risk. Defective, hard to use, or not needed product may consume much more time and resources than delays and issues in project delivery.

The BVOP suggests an integration of product risk management, which the Business Value-Oriented Project Management (BVOPM) office participates in managing.

Product risk management may include:

• Defining the product risk
• Product risk monitoring
• Product risk-avoiding

Identifying the product risk

The BVOPDM and BVOPM offices collaborate on defining product risk items.

Major product risk topics are presented in the Business Value-Oriented Product Management section of this guide.

Major product risk may include:

• Not satisfied audience needs and expectations
• Poor usability levels
• Cultural or social non-acceptance or resistance
• Poor performance measurement
• Poor cost estimate
• Poor pricing plans
• Poor quality
• No return on investments
• Inadequate marketing and sales strategies

Product risk monitoring

Monitoring product risk is a long-term initiative throughout the entire product development process and is a responsibility of all product and project teams.

Product risk items are observed and discussed during the research and development stages. Team members need to report to product management and project management roles if a risk symptom is noticed.

Product risk-avoiding

Avoiding a product risk issue is critical and needs to be directed immediately and proactively by the project or product team members.

The BVOPM office assesses product risk-avoiding, agrees on its execution, and may participate in this activity directly, technologically or administratively.

The Project risk management section of this guide contains details about defining and prioritizing risks and assigning team members to risk items.

The product risk may be a separate list of risk items or may be included in the list of overall project risk.

The Business Value-Oriented Project Management (BVOPM) office participates in fast and reliable decisions making. This may prevent slow decision-making from different stakeholders at different stages of project delivery and product development.

Various individuals, teams, and external organizations may need answers to questions about every aspect of the project. A frequency of response and solutions may eliminate waste and speed up the work of entire teams and organizations.

The BVOPM office major strategies for fast and reliable decision making are:

• Preparation
• Training
• Professional knowledge
• Communication

Preparation

The preparation strategy includes initial preparation of different possible decisions to make, which may include consulting at early stages with different teams, individuals or other parties, recall on previous documented decisions, create questions and answers databases, guidebooks, or any other helpful resources.

The preparation strategy may require a significant amount of time, and it is used with caution in order to avoid waste.

Although preparation may be a resourceful strategy, the created information, documentation, and tools may be useful for future use and reference.

If initial preparation is not an appropriate strategy for the organization, all important decisions during the project phases can be documented for future reference, and any future decision making may require less time and resources.

Training

Training is another decision making strategy that requires time and resources. Although it is resourceful, knowledge may be beneficial in future decision-making processes. If the planned projects require a significant amount of time and budget, training may be an acceptable strategy.

Professional knowledge

A common strategy for fast and reliable decision-making may be establishing a Business Value-Oriented Project Management (BVOPM) office with professionals already possessing extensive knowledge and experience in many project, product, and business themes related to the planned activities.

Communication

The communication strategy is often used as the easiest one, but it requires the regular involvement of higher management or individuals from different departments.

A mix of different strategies may be an optimized approach for the BVOPM office decision making.

Product support activities

Product support activities may include many research and development practices. Product support is not a quick and easy stage and may require the involvement and knowledge of the BVOPM office and its rapid intervention and decision-making.

Product management adjusting

Adjusting processes, practices, and tools is strongly recommended by the BVOP. Тhe BVOPM and BVOPDM offices may work together in adjusting product management and development practices.

The BVOP suggests that the scope of a project is not fixed and may often evolve.

Understanding the scope as a fixed list of goals should not be a perception of organizations interested in the project. In many real-world situations, scope constantly changes, and this does not necessarily have to be seen as something to be avoided at all costs.

Many interested parties and individuals may be involved in the scope definition, and this may lead to an extensive list of demands. The scope of the project may need to change with time. 

Scope management may include the following activities:

• Gathering initial information
• Scope definition
• Scope validation
• Scope change management

Gathering initial information

Gathering initial information may require collaborative work between the stakeholders interested in the project (any parties interested in the project, their representatives, or such with knowledge about the project needs). 

This process is planned and conducted with the presumption of productivity, and each party has to follow this presumption.

Group sessions to define the scope of the project where more than one stakeholder is present can provide validation of the discussed needs. 

Scope definition

Scope definition details the collected information into a more organized and formal list.

Scope validation

A single project may end up with an extensive list of scope items, and they all may be requested as important or critical for the project.

Classic project management practices present the term "Not in scope," which usually means that a topic should not be seen as something to be included in the project. 

As the scope of the project can be extensive, the business value may not be clear. The BVOP suggests that, instead of "Out of scope" themes, prioritization of all the items of the project scope may be applied instead.

If an interested party has mentioned a topic that can be considered as Out of scope, it can still have some value, that's why it should not be ignored, but assessed prioritized.

Scope prioritization

Each scope item has a priority attribute which may have the following values:

• Definite
• Very likely
• Likely
• Possible
• Unlikely

The scope of the project, in the form of prioritized items, can be useful after certain ideas evolve and the need for these items increases. It makes project teams and stakeholders aware of what can be implemented later on in the project.

The collected formal list of scope items needs to be double-checked and agreed upon by all interested parties.

Fast and on-time realization of projects depends on the stable and non-variable scope. Classic project management understandings teach that the scope of the projects should not be changed once it is defined, or the scope should accept minimum modifications. Changes in scope are often related to causing delays, re-work, and a waste of resources.

Under real-world conditions, the scope of projects usually changes after its initial definition and approval. The frequency of modifications may depend on factors such as changes in user and business needs, technical feasibility, and other topics described in the Business Value-Oriented Program Management section.

Changes in the scope of the project are generally considered to be important, especially in dynamic, innovative, and complex products where real users and stakeholders provide frequent feedback on early versions of the product.

The following practices may be applied to minimize the damage of future scope changes:

• Initial detailing of needs
• Creating and evaluating sketches, diagrams, prototypes and other materials that may represent the expected product clearly
• Assessing the emerging changes of the scope, so project teams are focused on the high-prioritized change
• Ignoring changes if they are not critical for the project

The low frequency of the project’s scope change may depend on factors such as:

• Defined clear goals
• Understanding and applying prioritization practices
• Understanding of Minimum viable product principles
• Dedicated stakeholders
• Competencies and skills
• Mature management roles

Changes in project scope should not always be considered as negative events. When an early version of a product is released to real users, valuable feedback about the business value of the released version may be provided by the users. 

The current version may not cover usability and accessibility levels or it might have gaps in important functionalities, which could have been developed in a way different from the users' expectations. The current version of the product can be a source of new ideas and needs for the users.

Any requested changes to the scope of the project may be processed by following the steps below:

• Assessing the requesting party
• Assessing the importance of the change request
• Assessing the impact on the project
• Documenting the change request
• Approval or denial of the change request
• Planning for implementation
• Communicating the plan with the requesting party
• Implementation
• Validation

 Assessing the requesting party

The requesting parties may be from different departments, stakeholders representatives, or organizations. 

Assessing the importance of the change request

Understanding the importance of the request is a needed step in order to process the change request. If it is not assessed as important, its processing may be delayed.

Answering basic questions at this stage may be helpful for assessing the importance of the change request such as:

• Who needs this change?
• Will this change affect the product or project positively?
• When does this change need to be fulfilled?
• What are the expected results if this change is not implemented in the project?
• Have the project participants been informed of this change request and its expected results?

Assessing the impact on the project

If the change is expected to impact general project parameters negatively, although it is important, the request for change can be discussed with program managers, project sponsors, and eventually rejected. If the impact is assessed as positive, the change may be approved as usual.

Problems that may occur after a change in the project parameters:

• Technical or development complication
• Negatively affecting other unexpected parameters as usability, product features, marketing, and sales strategies
• Negative feedback from other customers, users, and parties
• Increased cost and project completion time

The competence, experience, and skills of the project management roles may affect the needed time for assessing the change request.

Documenting the change request

Documenting the change request may be formal or informal practice based on organizational needs.

Maintaining a register of all requests may be a valuable source of information, needs, and requirements at later stages or for other and future projects of the organization.

Each registered request item may contain:

• The requested party (Name, team or department)
• Contact details for future communication
• Answers to the questions introduced in “Assessing the importance of the change request” step

Approval or denial of the change request

Actual formal approval or denial of the change request may be needed based on the organizational practices.

The BVOP suggests that if the organization has formal approval or denial process, the time needed for the decision need to be minimized.

Planning for implementation

Planning may include when exactly the change can be integrated, by which team and with what resources. Other change requests, project tasks already planned, and resources are considered. Adaptation of the current project plans may be needed.

Communicating the plan with the requesting party

Communicating the plan back to the requesting party may be needed, and feedback to be expected.

Implementation

The actual implementation of the change.

Validation

The outcome of the implemented change needs to be validated and agreed upon as satisfactory.

Stakeholders, project team members, and other parties may participate together in prioritization, estimation, and planning of the changes.

Planning a project in the context of the BVOP is focused on the following major topics:

• Product research planning
• Major deliverables planning
• Product development planning
• Product validation planning
• Time planning
• Cost planning
• Project release planning
• Product support planning
• Project support planning

Product research planning

Product research planning may include:

• Collecting all databases or resources from previous projects and initiatives related to user research practices and analyzing the information.
• Finding proper users for user research practices.
• Scheduling research sessions.
• Preparing tools and environment needed for the product research.

Major deliverables planning

May include planning of the product features or modules, their dependencies, and stages of development.

It may also include a plan of possible sub-products, services, external products, and other related initiatives that may be included in the scope of the project.

Planning includes high-level definitions of the deliverables and approximately their desired or estimated completion time presented as quarters of the year, months, or other relative time units.

This plan may be helpful for scheduling other activities related to the product, such as marketing campaigns, establishing other parties' relationships, or estimating high-level cost.

The use of work breakdown structures and other similar tools should not be taken as a method of helping accurate estimates of resources and time needed for project completion, as it may lead to errors.

Detailed delivery, time, and cost plans need to be considered as an estimate by all stakeholders, and everyone must be aware of a high probability of inaccuracies.

Product development planning

Product development planning may include:

• Choosing development methodologies
• Planning teams
• Planning meetings
• Planning resources 

The product development planning characteristics

The planning of the development is recorded in brief documents, which may need to be introduced, discussed, approved, or used for future reference.

Planning documents should be easy to edit and maintain when needed.

All plannings are brief and understandable by anyone involved in the project. 

Standard and accessible terms and language are used in plans. If team members involved in the project do not understand a term, they should quickly get familiar.

All teams and key roles read all documents.

When new team members join the project, they become acquainted with the planning documentation.

Teams are informed about planning changes.

Teams have quick access to all plans.

Product validation planning

Product validation planning includes an overview of how and when the product development process will be validated, as well as by whom.

Any idea, wireframe, feature, already developed functionality, and the entire product needs validation.

Time planning in the context of the BVOP is a continuous process. For detailed estimates of required completion time of a given effort (task, item or initiative that needs work) multiple factors are taken into account:

• Previous time consumption of a similar activity
• Current knowledge of scope and requirements
• Relational effort points
• Teams velocity

Previous time consumption of a similar activity

If a similar effort or activity has already been done, its time consumption may be a base for future time estimations.

Current knowledge of scope and requirements

When effort is already planned, the estimated development time may no longer be correct as scope and requirements may have changed.

Re-estimating the required time for an effort to be executed is recommended before development starts. This can be done by checking all current known requirements and scope.

Re-estimation of an effort may reflect on the total time estimation of all other known and defined efforts.

Relational effort points

Relational effort points are recommended by the BVOP when an effort is being estimated.

For example, instead of putting an estimate of 3 days for a task, giving it 10 effort points would be a better relative estimate that is not strictly bound to an exact required amount of time that, in some cases, may not be accurate.

Story points and T-Shirt sizes are popular measurement examples of relational effort points.

Teams velocity

Team velocity is a popular term that means an approximate amount of work a team can produce for a defined timeframe.

Using team velocity is a helpful tool for estimating the completion time of a collection of planned efforts (work).

Conversion of relative points to a real time estimate

Conversion of relational points to real-time is possible but should be used with caution, as this conversion gives approximate values and not the exact needed time for an effort.

The basic conversion of relative points to a real time can be based on the current team’s velocity, the fixed time interval, and the total effort points of all planned efforts.

Cost planning may include:

• Predefined costs 
• Costs for development

Predefined costs

The predefined costs may consist of all project costs that are not related to its development or maintenance.

These may include costs for:

• Staff hiring
• Marketing
• Sales
• Acquisitions
• Operations
• Legal
• Taxes
• Tools and environment

Predefined cost planning is implemented at the earliest possible stage of the project.

Costs for development

Costs for development are applied in early stages, after planning the major deliverables, where each deliverable (item, module, feature, service, or any other related activity) may be roughly estimated.

Detailed cost plans at this stage can be considered as a forecast, and all stakeholders should be aware of possible changes.

Detailed and more accurate planning can be done when project development begins, and real data is used to predict the time to complete efforts.

Updating development costs can take place over specific periods if the organization needs timely updates and calculations of the estimated costs.

Release planning is helpful for all stakeholders involved in the project who are interested in the release date of deliverables or of smaller achievements. This interest is usually driven by tracking costs, external events, or contractual relationships.

Release planning is a widespread project management practice, but in the context of BVOP with some modifications, this can be a method of adding extra business value to projects.

Analyzing current issues and preventing future ones is the main focus topic in BVOP practices.

Release plans contain lists of planned efforts and their release time. If planned work is not released within the planned time, it is a symptom of a problem inside the organization, teams, or other parties.

The BVOP suggests that the reasons for unreleased items from the list should be investigated and recorded. If patterns or obvious reasons for release failure are observed, the BVOPM office focuses its attention on resolving these issues on time.

Resolving issues as soon as they occur is a valuable activity that the Business Value-Oriented Project Management (BVOPM) office does for the entire organization, teams, and all parties involved in the project.

Project release planning may also include concepts, prototypes, updates, and versions of the product, so that the immediate validations activities guarantee to provide a desirable, valuable, and usable current outcome.

Product support planning

Product support planning may include planning of possible actions, stages, and practices for the future.

Main subjects of the plan may include:

• Type of work
• Amount of work
• Periodicity of support
• Period of support
• Costs

Type of work

The essence of the work required has to be determined. Identifying the professionals and their skills needed to support the product is also beneficial.

If the team working on product development is unable to participate in the product support stage, a new team is assembled. Environment and tools are planned and eventually provided.

Amount of work

Although the product support may require significant effort, the Business Value-Oriented Project Management (BVOPM) office decides and plans the amount of potential work based on available and foreseeable resources and current product strategies.

Periodicity of support

The periodicity of support needs to be determined in order to plan and distribute resources over time.

Costs

All product support plans are closely related to costs. Product support costs may be a proportion of the total budget for the product or other planned amount.

Project support planning

Planning of project support includes activities not related to product development and support. It may be related to:

• Legal Aspects
• Logistics and transport
• Deliveries
• Implementation
• Operational
• Communications
• Other Events

Project risk management requires awareness and involvement of key roles from management offices, development teams, implementations, support departments and all parties interested in the project.

Project risk management is a major activity with high importance in the context of the BVOP. 

The Business Value-Oriented Project Management (BVOPM) office needs to stand by the following ideas:

• A risk may be obvious or hidden.
• An unrealized and unmanaged risk may cost a lot of time and resources.
• An unmanaged risk may be a reason for the failure of a project.

The obvious risk relates to topics, which are expected, known, and previously experienced by individuals involved in a project.

The hidden risk is related to topics and events for which project participants and stakeholders have no awareness or knowledge.

Project risk management may include the following activities:

• Collecting risk items
• Evaluating the risk (analysis)
• Risk prioritization
• Observing the risk
• Discussing the risk
• Avoiding the risk
• Updating the risk items
• Sharing the risk
• Willingness to share and participate

Collecting risk items

Risk items are risk topics that can be defined and described separately. They are usually collected in a common list that contains an indefinite and unlimited amount of risk items.

The collecting of risk topics includes the naming and description of all possible events and factors that may negatively affect the project in any way.

Extensive knowledge about risk items is required in the process of their collection. Pointing out the possible realistic situations of their occurrence is also needed. All offices, departments, and key roles involved in the project contribute to the risk collection through their knowledge and experience.

Evaluating the risk (analysis)

Each risk item needs evaluation and detailing for easier general risk management.

Risks items attributes

The risks items may have multiple attributes like:

• Category
• Description
• Impact
• Probability
• Symptom
• Loss size
• Action plan
• Owner
• Proximity

Category

The categorization of the risk items helps with their organization into general groups. Categorization may include areas like:

• Management
• Users
• Requirements
• Technology
• Team
• Organization
• Documentation
• Supply

Management

Risk items in this category usually include issues that may arise from the organization's senior and middle management. Issues may be related to the low engagement of senior management, lack of communication, unrealistic budgets, and more.

Users

This category may include risks that are closely related to product users. That may include negative opinions, lack of commitment, low user satisfaction, and more.

Requirements

These risks may be related to:

• Constantly changing requirements

• Changing requirements at late stages

• Unclear requirements

• Misunderstanding the requirements

Technology

Technological risk can lead to significant time-to-market if teams use unfamiliar technologies. This risk usually affects time, costs, and pre-planned events.

Technical debt is another risky topic that needs focus. Massive technical debt can lead to eventual product re-work and negative development direction.

A technical risk may cause a negative impact on external teams, which can lead to difficulties with using parts of the product. Support and integration may be difficult.

Team

A team risk is associated with people who develop or maintain the product. Possible risks are inadequate experiences, not enough personnel, team conflicts, low motivation, and other aspects of human behavior and interactions.

Organization

An organizational risk may be related to the organization's inability to manage the entire product, staff, supplies, support, events, resources, policies, and legal aspects, etc.

The culture and maturity of the organization, unstable environment, resources, and restructuring can also be major risk issues.

Supply

Supply may include providing materials, resources, external and internal needs, content, data, tools, environments. Not supplying any of these may be considered as a project risk.

Description

Description of the actual expected risk item. Items are described briefly in a comprehensible language.

Impact

The impact is the potential damage caused by each risk item. It describes shortly what eventually may happen if the risk occurs.

Probability

The likelihood of the risk occurring. It may be a numerable value from 1 to 10, other quantitative units, or a term item like “Unlikely”, “Likely to occur”, “Certain to occur,” etc. 

Symptom

Any potential risk may have a documented symptom of occurrence. Depending on previous experience and skills of the teams and parties involved in the project, the symptoms can be predicted and described clearly.

Symptoms should be clear to all involved in and developing the project.

Loss size

Loss size is a relative unit that represents possible material losses such as hours, days, or money.

If a risk item has a Loss size of 10, this may mean a 10-day delay in the project. If the result is multiplied by the total money consumption per day, this may indicate the number of total losses caused by this risk.

The entire project risk collection has a Total Loss Size number, which is the sum of all loss size values of all risk items.

If the project risk collection contains 100 risks items with an average loss size value of 10 for each item, then the Total Loss size for the entire project will be 1000. If the Loss size unit represents days, and if the entire risk described in the collection occurs, the entire project will be delayed by 1000 days. If one business day costs $ 1000 for the organization, including fees, wages, and any expenses, the total loss for the organization will be $ 1, 000, 000.

The BVOP focuses on project risk management and Loss size for each risk item as an important topic that is associated with serious damage to organizations.

The visualization of possible losses may help raise the level of responsibility and commitment of all key roles in the project.

Action plan

Defining and collecting risk items is not enough to adequately manage risks. An action plan is needed. If a risk factor or event arises, the management offices, development teams, and all key project roles and stakeholders must be prepared and aware of possible response actions.

The BVOP suggests that all offices inside an organization and all teams and individuals should do their best to avoid all potential risks.

Owner

The owner is an individual, team, or an entire office responsible for risk avoidance. The owner is always known, defined, and needs to be competent in the risk category. The owner is proactive and acts independently to prevent the risk. Proper guidance and support from other offices, teams, or individuals are recommended if this would increase the chances of risk avoidance.

Proximity

Proximity is an estimate of the most likely time for a risk to occur. Owners can concentrate their efforts and observations within a reasonable time before the risk emerges if the proximity is realistic.

Proximity types may be upcoming, within a stage, within the project, beyond the project.

The risk items may also have other attributes like ID, Name, Date, Status, or any other that provides convenience for general risk management.

Risk prioritization

Prioritization of all the risk items is a helpful practice that ensures focus on highly important possible issues and optimizes the effort needed for risk management. A popular practice in the classical project management is the risk items to be prioritized by their risk probability or by values of several multiplied attributes.

The BVOP suggests that prioritizing by one attribute or result of attributes is not enough, and the project risk needs more attention and focus. The risk may be hidden and unexpected. Project risk management requires the collaboration of all offices, departments, and individuals. The project risk is dynamic at different stages of the project, therefore the prioritization should also be dynamic.

Each office or department can filter the risk items to their needs by using the available categories, owners, and attributes of the items. Filtering can provide focus and easier monitoring and risk management.

For example, the design department can track the risk items from the Design category and prioritize and focus on the risks associated with the entire design department. Management offices can filter the risk collection according to Management category or Loss Size to focus on potential management issues or to calculate total potential losses.

Observing the risk

Observing the risk has a crucial role in risk management. All risk owners need constant awareness of the risk items assigned to them and proactively track symptoms and statuses, observe situations, behaviors, and occurrences that may cause a certain negative event to implode. 

Discussing risk

Offices, departments, or teams need to discuss the project risk at the early stages of the risk definition, as well as at the regularly held discussion sessions throughout the entire project.

During the sessions, each department can define new risks and provide other departments with information (status, updates, issues, needs) about the risks already identified.

Conclusions and information from the sessions held are shared with all the offices and departments interested in the project.

Discussion sessions are quick and focused on essential topics and productivity.

Avoiding the risk

Avoiding the risk is the main subject and activity of all parties involved in the project. It requires collaboration and proactivity.

Avoiding the risk may include actual work to be done at the early stages or during the project. It may be scheduled as regular tasks for internal or external teams as a part of the entire product or project development or delivery.

Updating the risk items

Updating risk items takes place over the entire project cycle and may be a method of revealing hidden risks. 

Risk items updates are based on the newly provided information, discussions, resolutions, or new issues.

Sharing the risk

Risk-sharing involves providing the entire risk collection to all offices, teams, key roles, and stakeholders. It is a way to prevent potential risks and to improve their collection.

Willingness to share and participate

The BVOP suggests the participation of as many key roles as possible in risk management. Some departments and individuals may avoid participating in this process intentionally. The unwillingness to participate in risk management and avoidance may have different roots. Still, key role participation in the entire project risk management process is a worthwhile activity that can prevent many risky events and factors.

The BVOPM office spreads a culture of cooperation and points out and highlights the benefits of involving key roles in risk management.

All offices should understand that making estimations by using a fixed time may not always be accurate. Teams can estimate the time required for development in relative units.

Detailed time estimation practices and the term “velocity” are introduced in the Business Value-Oriented Product Management section.

Estimation of effort (the work that needs to be done) requires a collaboration between teams that are closely related to development or delivery.

They share their best assumptions about the time it will take to complete the effort in relative points. The estimation is based on a number of factors such as:

• Experience
• Skills
• Understanding of the product
• Understanding of the technology
• External dependencies
• Internal dependencies
• Difficulty level

Reasons for time estimation in relative units may be:

• The exact time required for the effort is unclear.
• Additional information may be needed to estimate the required time for development (realization) in the next stages accurately.
• Team preference to follow popular techniques to estimate time in relative units.
• Reducing overall stress among teams.

The time estimation topic is sensitive

The time estimation topic is sensitive, as, in real situations, the project sponsor or management roles may require delivery time for a project that is shorter than the estimated period. At the same time, teams can not promise delivery of the project within the required timeframe.

Unrealistic requirements for work completion can cause stress, and at some point, the teams could estimate their work incorrectly. Teams may also start adding hidden buffer time to their estimates. If they would normally give 5 time points to an effort (task), they can add two more in secret, so the overall estimate becomes 7 points.

A recommended scenario to avoid this case is not to press the teams for a short time estimate, but rather optimize and speed up other processes as far as possible with the help of all management offices.

This optimization can be accomplished by providing a better working environment, larger and more capable teams, timely resources and information, and any other factors that can positively affect development and delivery periods.

On the other hand, development teams must follow the organization's priorities and understand that any delays cost a lot of resources. Deliberate delay in work can harm the organization and other external parties.

All departments and teams may need to define deadlines for efforts in order to help them to focus.

Any activity that does not return business value, valid outcome, desired results, or requires too many resources can be considered as waste for products, projects, organizations, and other external parties.

Major causes of waste

Major waste may include:

• Too much planning
• Incorrect or not validated planning
• Non-productive research
• Wrong sourcing and recruiting
• Inadequate analysis and processing of data or information
• Poor communication
• Wrong production
• Poor production
• Poor testing
• Supply or delivery delays
• Overwork or perfectionism
• Poor or excessive documentation
• Rejection of completed work that could be approved

Too much planning

Planning and attempting to plan unforeseen situations and events that are not subjected to detailed and accurate planning.

An approach to avoiding this situation is to plan resources and time in detail only for activities and productions, which require it. The rest may only need high-level planning. Phased planning can also be applied.

Incorrect or not validated planning

Incorrect planning or planning that is not validated by teams, project participants, or other stakeholders.

The participation of stakeholders in the validation process can lead to more accurate estimates of resources or events.

Non-productive research

Non-Productive research may lead to mistakes in the future.

Avoiding this problem may require all research topics and desired results to be pre-defined, discussed, tested, and validated by internal and external stakeholders, potential or actual users, and other interested parties.

Wrong sourcing and recruiting

Inappropriately formed teams and hired personnel.

To avoid this, involving representatives from development teams in the process of forming and expanding teams and recruiting staff may be necessary. Defining accurate, clear, and understandable criteria for sourcing and recruitment may be helpful.

Inadequate analysis and processing of data or information

May include incorrect and inadequate data analysis from surveys, statistics, processes and work results, misinformation, and any misunderstood information.

Requirements for adequate data analysis may be proper structuring, presentations, clarity, training, and accuracy of the presented information.

Poor communication

Slow communication, lack of communication, and inefficient communication can be considered as major waste.

Following communication plans and procedures, tracking speed and communication effectiveness are ways to prevent waste caused by poor communication. The Business Value-Oriented Project Management (BVOPM) office may need to mentor and coach teams, departments, and stakeholders about the importance of communication. 

Wrong production

The wrong production may include defects, abnormal development caused by misunderstood specifications, or improperly developed parts of the product.

Methods to prevent a wrong production may include validated and understandable specifications, prototyping, and regular product validation by users and stakeholders.

Poor production

Poor production may be intentional or unintentional. It may be caused by factors such as time-pressured teams, inaccurate timeframes and resource estimates. It can also be a result of insufficient workforce, materials, tools, and poor environments.

Careful planning and provision of project needs may minimize such negative consequences.

Poor testing

Inadequate testing may cause re-work, defects in a real environment, or lead to users' reluctance to use the product if it does not meet their needs.

Avoiding these undesirable consequences can be achieved with a detailed definition of testing methods, test scenarios, desired results, and other necessary plans.

Supply or delivery delays

A common reason for different types of waste.

Overwork or perfectionism

Overwork in the context of waste means taking too much attention, time, and effort for tasks that are practically complete, but teams are unaware of it and continue to work on them.

Perfectionism in the context of waste defines the denial to cease work on certain assignments due to personal dissatisfaction with the results.

Overwork or perfectionism may be a major waste if they are not appropriately controlled. While avoiding defects at any cost may be of particular importance to the product, overwork and perfectionism can cause hidden waste of resources and time.

Observing the quality and duration of work, assessing, testing, and validating the results achieved and finishing work on time can prevent overwork and perfectionism.

Poor or excessive documentation

Inaccurate, incomplete, or incomprehensible documentation may result in delayed or incorrect development. Excessive and heavy documentation may cause difficulties, which can lead to extensive information searches and frequent assistance may be needed.

Balancing documentation can be carried out by regularly discussing the needs of the documentation parameters, the needs of internal and external teams, and the teams’ actual participation. Maintaining comprehensibility, brevity, and ease of use should be a priority in document management.

Rejection of completed work that could be approved

Rejection of completed work that could otherwise be approved may lead to re-work and loss of resources and time. Rejection does not always have to be considered as an accurate judgment by the approval and accepting parties.

If teams and stakeholders accept the quality and adequacy of the work done while approval and accepting parties reject it, negotiations, quality tests, and analyses may be carried out in order to determine the work’s readiness and quality.

Such activities, negotiations, and retests may be resource-intensive, so all project stakeholders have to keep that in mind and be prepared for different scenarios.

Waste reduction

The Business Value-Oriented Project Management (BVOPM) office should consider any possible waste, monitor its occurrence, and take the necessary elimination measures quickly. Waste needs to be a regular topic in risk management. 

Each identified waste may need a specified reduction approach or multiple approaches. The Business Value-Oriented Program Management (BVOPGM) and BVOPM offices collaborate and agree on ways to deal with different waste situations.

All possible waste may be added to the project risk list and may be assigned to an owner, and be subject to monitoring, discussion, and prevention practices.

The BVOPM office may need to entirely remove a wasteful process or activity if it does not provide any value.

Educating teams, individuals, or other parties may be needed for reducing waste.

All organizational offices make decisions, and the decision-making process requires different competencies and skills. Decisions need to be made regularly, and their adequacy and speed are essential.

Typical topics requiring decisions may include:

• Prioritizing work
• Allocating resources
• Accepting or rejecting outcomes
• Changing standards or processes
• Suspending activities
• Starting new initiatives

The Business Value-Oriented Project Management (BVOPM) office makes decisions based on data, expertise, urgency, resources, observations, and analysis.

Executing includes all activities between planning and closing the project. Executing is not a specific activity. It is a mix and groups of activities that are needed to complete the project and add business value.

During the entire executing phase, the Business Value-Oriented Project Management (BVOPM) office focuses on its activities, paying specific attention to:

• Waste management
• Decisions making
• Defects analysis
• Observation and optimization
• Support

These activities are the most essential for providing speed, quality, and covering the scope of the project.

The BVOP introduces the measurement Business Value Points as a practice and tool for evaluating the current overall business value of the product that’s being developed and its business value fluctuations over time.

The total value of the product’s business value points is the sum of points of all planned developments (all functionalities, modules, parts).

All efforts (tasks, user stories, planned work) planned to be developed as part of the product are evaluated individually using business value points.

Total Business Value Points for a Time Period

Total business value points over a period of time is the sum of all business value points obtained from all the developed efforts for a specified period.

Example: All planned tasks for a given month are 100 in total. The first 10 planned tasks are rated with 20 business value points (BVP) each. The next 30 tasks are rated at 10 BVP each. The remaining 60 tasks are rated at 5 BVP each.

The total BVP is 800, which can be considered as the total business value points for the period.

Prioritizing development by business value points may be a transparent method of prioritizing Product Backlog items or task planning based on real value.

Product evaluation based on business value points

The measurement of business value points can show the rise and fall of the total business value of the product.

If the total business value points for a given period are more than the total business value points for a previous period, this may indicate an undesired prioritization of the development in the prior tasks. This way the management offices can detect mistakes in management and take corrective measures.

An optimistic reason for a higher number of business value points per period can be improved research practices or acquired new knowledge from stakeholders or users.

Normally, each subsequent period should have a lesser total sum of business value points, as work is prioritized by the business value points of each task.

In theory, at some point, the expected business value points for a period will be 0, as there will be no more valuable development work.

Tracking the fall in total business value points over periods may be a decision-making tool to close a product or project development.

If total business value points for the past few periods are very low, project sponsors or other stakeholders may make the decision to close the development or estimate its eventual closure, based on the decrease of business value points per period.

Assessing business value points of planned efforts

If any planned work (effort) has been assigned business attributes such as importance, urgency, attractiveness, etc., and each attribute has a numerical value, the business value points (BVP) of each planned work is the sum of all attributes’ value.

Example

If a planned effort titled "Uploading a profile photo" has business attributes as follows:

Importance: 5

Urgency: 3

Attractiveness: 10,

This planned effort has 18 BVP.

Another planned effort, titled "Forgot password", has business attribute values:

Importance: 10.

Urgency: 8,

Attractiveness: 2,

This planned effort has 20 BVP.

In this example, the planned "Forgot password" effort might be scheduled for development before the "Uploading a profile photo" effort because it has more business value points.

The Business Value-Oriented Project Management (BVOPM) and Business Value-Oriented Product Management (BVOPDM) offices create the business attributes and their value according to the product, project, organizational needs, and other factors. 

It is of particular importance that the planned efforts are evaluated against the same business attributes so that accurate business value points can be calculated, therefore making those procedures easier and more transparent.

More details about the business attributes of the planned work are presented in the Business Value-Oriented Product Management section.

A positive attitude is a major factor in constructive communication and collaboration between teams, offices, and professionals, which in turn can improve the overall productivity of the project, the teams, and the organization.

This activity may include attitude management of:

• Project and product teams
• Organizational offices
• External parties

The BVOP suggests that a representative of the Business Value-Oriented Project Management (BVOPM) office should be among the teams as much as possible.

The presence of Business Value-Oriented Project Management (BVOPM) roles needs to be positive. They support, motivate, and inspire teams who should be positive and focused on their work.

The BVOPM and Business Value-Oriented People Management (BVOPPM) offices may need to work together to manage attitudes.

The BVOPM and BVOPPM offices may organize events and provide resources related to:

• Group sessions involving teams for discussing existing issues.
• Individual sessions for discussing existing issues.
• Planning of training programs.
• Emphasizing the importance of the success achieved by teams and individuals.
• Personal and professional development programs.

The BVOP presents defect analysis as a practice and tool for analyzing problems in development teams, organizations, management practices, or the environment.

A defect may refer to issue, bug, incident, error, flaw, failure, malfunction. The common understanding of a defect is an incorrect or unexpected result or behavior of the product.

The BVOP suggests defining categories for all defects, investigating the root causes for their occurrence, and adding each one to a suitable category.

Defects categories

Defects categories may include:

• Time pressure
• General Stress
• Scope misunderstanding
• Scope change
• Poor requirements
• Lack of communication

Time pressure

Time pressure may be a reason for the occurrence of defects. When deadlines press teams, they may miss important details, or work quality may drop.

If defects in this category are predominant, this may be an indication of too short deadlines.

Corrective actions to reduce future defects in this category may include rechecking and negotiations of deadlines.

General Stress

Stress may be the cause of defects. When people are under stress, productivity, proactivity, and confidence decline. The defects in this category must be distinguished from the Time Pressure one.

Causes of general stress may vary, but common ones may include:

• Management attitude
• Personal conflicts
• Cultural differences
• Organizational policy
• Organizational stability
• Environment

Representatives of the BVOPM office are the main initiators to involve all the offices and their representatives in solving the problems.

Scope misunderstanding

If the scope of the project is not communicated extensively at early planning stages or details are missing, this may lead to many defects categorized in this category at later development or implementation stages.

Another reason for the defects in this category may be insufficient technical or business knowledge among the key roles involved in the project.

Corrective actions to reduce the defects in this category may include revisiting the details of the project scope, technical training, and familiarizing key roles with the business logic of the project.

Scope change

Defects in this category may reveal problems in multiple areas such as:

• Clients or users are not completely aware of their needs.
• Development or implementation progress is slower than the users' demand.
• Lack of resources or newly introduced optimizations have changed the scope of the project.
• Additional requests from users or stakeholders that may not be needed.

Poor requirements

Defects in this category may be caused by a deficiency of:

• Detailing
• Quality documentation
• Technical or design expertise
• Documented verbal agreements

Corrective actions to reduce the defects in this category can be sessions between team members discussing the requirements before starting the actual work and potential improvement of requirements.

The sketches, diagrams, animations, or functional prototypes that product developers create, present the work needed to be developed. They can be used by demanding parties for validation.

Lack of communication

Communication is essential for any project, development, and business initiative. Lack of communication may relate to:

• General slow communication
• Intentionally ignoring important topics
• Missing important contexts
• Virtual or distant teams
• Low employee morale
• Conflicts

The BVOPM office investigates the core reasons for the problems and makes efforts to resolve them. The categories with the highest number of defects should be given closer attention.

Specific activities, processes, and practices may be needed at different stages of the project, and their efficiency may vary. The Business Value-Oriented Project Management (BVOPM) office observes and optimizes work, processes, practices, interactions.

Observing

Observing and analyzing the efficiency of:

• Work progress
• Work status
• Management practices
• Design, development or implementation practices
• Validation, approval or test practices
• Communications and interactions

Optimizing

If a nonoptimal work, process, practice, or interaction is observed, the BVOPM and Business Value-Oriented Program Management (BVOPGM) offices optimize its efficiency to avoid waste and to improve weak links.

The optimization may include:

• Modifying teams
• Modifying management practices
• Providing tools, databases or software
• Adding formal processes or suspension of such
• Controlling interactions

Optimizations should be implemented carefully only after repeated observation of inefficient factors.

Participation in program management

The Business Value-Oriented Project Management (BVOPM) office may be part of the Business Value-Oriented Program Management (BVOPGM) office, or they both may be considered as one.

Participation in program management may include:

• Assisting in defining project management methodologies, practices, or frameworks.
• Requesting support, advice, and knowledge from other roles.
• Assisting in modifying or combining project management methodologies or practices.
• Presenting decisions, pros and cons to interested parties.
• Assisting in training other roles in the modified methodologies or practices.
• Assisting in maintaining a knowledge database of lessons learned.
• Assisting in spreading knowledge across other roles.
• Supporting other roles, offices, and interested parties.

Supporting

The BVOPM office participates in various supporting activities planned by the BVOPGM office and follows its strategies, objectives, and guidelines.

Supporting is presented in the Business Value-Oriented Program Management section.

Closing projects is a classic, standard, and needed phase in the project management area that usually includes major activities like:

• Assurance that all the work has been completed.
• Assurance that all agreements are met.
• Agreements between each involved and interested parties that the project is completed.
• Reviewing contracts.
• Validating the completion of the defined goals, objectives, and benefits defined at initial project phases.
• Maintaining lessons learned.
• Dismissing internal or external resources and involved parties.
• Delivering the project outcomes to internal or external customers or other operational teams.

Some of the activities are formal, administrative, or legal, and can’t usually be skipped when different parties are involved in a project.

BVOP suggests additional activities that provide more business value for all project participants. Such activities may include:

• Sharing and discussing lessons learned
• Creating plans for improvements
• Actual improvement

Sharing and discussing lessons learned

Learned lessons usually relate to collecting information about the well carried out aspects of the project, and the dissatisfactory outcomes with suggestions for their future improvement.

Lessons learned in real-world situations are often ignored or barely noted. If they are prepared carefully in detail and contain useful information, they may be a very valuable resource for organizations and teams involved in the projects.

Creating plans for improvements

Based on information from the lessons learned, organizational offices, departments, and teams discuss and plan improvements of practices and processes, steps for their implementation, and the eventually needed resources.

Actual improvement

The improvement plans for the lessons learned are shared with other offices and get scheduled for execution.

Executing may include training, skills improvement, environmental improvements, or acquiring tools.

The Transparent Board of Project Issues is a dynamic list, accessible to all management roles and development teams involved in the project. It contains a regularly updated list of issues and concerns about the project, the involved people, the used tools, and the processes. The Business Value-Oriented Project Management (BVOPM) office records the issues, manages their resolution and, if necessary, directs them to other offices, roles, and parties.

Business Value-Oriented Product Management (BVOPDM) is a product management style, approach, and an initiative that aims to incrementally and continuously add a business value to a product. Adding business value is foreseen through the use of practices that guarantee the quality of the product and its adoption by the target audience. At the same time, the processes of development and the end-result are optimized.

Activities of the Business Value-Oriented Product Management office

Typical activities of the Business Value-Oriented Product Management office include:

• Participating in creating business plans 
• Product risk management
• Product research practices
• Product backlog management
• Product development practices
• Product optimization practices
• Product support activities
• Observing and adjusting

A business plan is usually an official document containing specific product-related business objectives of the organization, timeframes for implementation, plans, and strategies for achieving targets and defining financial needs. Except for the usual funding application or for presenting plans to the board of directors and other stakeholders, BVOP suggests it also serves as a guide for internal teams comprising further steps and implementation guidelines. 

The business plan may be a source for creating non-formal documents and resources like product visions, initial high-level roadmaps, project plans, etc.

A business plan may contain the following information in details:

• Executive summary
• Mission statement
• Business description
• Business environment analysis
• SWOT analysis
• Industry background
• Competitor analysis
• Market analysis
• Marketing plan
• Operations plan
• Management summary
• Financial plan
• Milestones

The Business Value-Oriented Product Management (BVOPDM) office representatives may participate in the creation of formal business plans, which may be a time-consuming activity. The main focus of the BVOPDM office representatives is creating clear, concise, and straightforward documents containing rationalized topics. An example of such a document may be the popular Product vision.

Product vision may be a simple document, chart, table, spreadsheet, or a graph that should contain at least 3 required information categories regarding the product:

• Target group
• User needs
• Business goals

These three categories of information at least provide who the target audience is, what its needs are, and how the organization will benefit from the realization of a product in that respect.

The Business Value-Oriented Principles (BVOP) require, at a minimum, these groups of information to be collected and validated before any teams start any further research and development processes.

The product vision information may be collected from product management roles, internal organizational teams, third parties, or any other source of information that may be valuable.

Expanding the product vision is the next logical step. More information categories may be included in the product vision, such as:

• Initial product description
• Competitors strengths and weaknesses
• Cost factors
• Detailed users analysis
• Channels of distribution
• Value proposition

The product vision serves as a reference to all teams and stakeholders. All initiatives, additional research and development activities, and finalized productions need to be assessed according to the information collected in the document.

Any new, valid, and useful information about the product should be reflected in the document on time.

Major product risk topics (items) are presented in the Business Value-Oriented Project Management section, chapter Product risk management. 

Representatives of the Business Value-Oriented Product Management (BVOPDM) office participate in the definition of project risk and play a major role in the prevention of possible product risks.

The BVOP recommends describing negative scenarios for potential undesired directions that the product may take after it is released to the intended audience. Defining action plans is also recommended.

Major scenarios may include:

• Users do not accept and use the product at all.
• User adoption is below the estimated minimum levels.
• User adoption is higher than the estimated levels.
• Product features do not satisfy the users’ and market’s demands.
• Product support is slower than the velocity of the market and the users' demands.
• Usability issues.

Other risk topics and scenarios may relate to:

Operational processes, price, quality, regulations, users' cultural and behavioral specifics, etc.

Users do not accept and use the product at all

Not accepting the product is the worst possible scenario. In this case, the organization may need to create strategies to withdraw the product from the market and eliminate certain procedures in order to reduce losses.

The BVOPDM office and key roles at the organization plan such strategies and prepare for such possible scenarios right from the very beginning of the product planning.

Estimated losses should be defined, and all key roles in the organization must be aware of them.

Users adoption is below the estimated minimum levels

User adoption can be considered as the general acceptance of the product by users and their willingness to use or pay for it.

If the users' adoption is below the estimated minimum, a potential action plan may include immediate product improvement, increasing sales activities, improving marketing strategies, or expanding the intended audience (target users).

Users adoption is higher than the estimated levels

If the quantity of the product does not meet the users' demand, this can lead to negative effects. The quantity of the product may be physical or non-physical.

If the product is physical, its quantity is usually considered to be the number of manufactured items.

Rapid production at a higher, non-optimized price can be the easiest and quickest action plan for this scenario. Rapid production should be applied as a temporary solution until production cost and velocity are balanced.

If the product is non-physical (for example, virtual), an example of insufficiently satisfied users' demand may be reaching its limits quickly or facing technical constraints.

Users may expect higher limits and fewer constraints in both physical and non-physical products.

Product features do not satisfy the users’ and market’s demands

Product features may be unsatisfactory, less attractive than expected, or users can expect more features, product capabilities, or higher overall emotional satisfaction.

In this case, innovative and attractive functionalities, which were pre-documented and not developed, may be planned for further development if required resources are available.

Product support is slower than the velocity of the market and the users' demands

Users can expect new functionalities, modules, and parts of the project to be developed faster than the organization's capabilities.

Usability issues

Usability issues can be associated with low levels of accessibility, poor affordance, or negative user experience.

Usability issues should be the lowest possible product risk, as they are usually fixed during product development and testing phases.

Every product may face usability problems in a real environment among users. Acceptable levels and negative usability related scenarios need to be defined.

Although this is a rather unlikely risk, critical points of usability issues need to be defined in the initial stages of product planning.

Defining and managing the product risks

Products typically encounter different types of risks and negative situations in a real environment.

Product risk may include unlimited topics, and the BVOPDM office creates simulations, scenarios, and realistic and feasible risk mitigation actions for situations that are most likely to occur.

Defining and managing the product risks may require the participation of all organizational teams or individuals that may give a realistic and valuable risk definition and plan mitigation actions.

At the very beginning of product development or at any other stage, choosing and defining research practices may help product teams to organize and plan their upcoming work.

Depending on the organizational policies, available resources, constraints, or and any other factors, the Business Value-Oriented Product Management (BVOPDM) office chooses the product research practices. They may include:

• Collecting information from third parties.
• Collecting information from internal organizational assets.
• Development and implementation of research tools.
• Organizing research events and practices.

Collecting information from third parties

Third parties may share valuable information and knowledge related to users, customers, markets, or already collected statistical data that may provide a direction for future development.

Collecting information from internal organizational assets

An organization usually collects significant data and information about its markets, users, customers, and current products that may be used as a valuable source for product development initiatives. Departments, teams, and individuals with different competence may share valuable knowledge that may be used during the product development stages.

Development and implementation of research tools and practices

The BVOPDM office develops and implements research practices and tools that provide efficiency for the product being developed.

One tool or practice may not be appropriate for all products developed by the organization.

Depending on product type or its material form, research and development practices may vary.

The BVOPDM office identifies the most appropriate approaches for each product, team, market, and target audience.

Organizing research events and practices

Research events and practices may have a different format, duration, and periodicity. They can be organized and implemented in the initial phases of product development and run periodically throughout the entire product development and maintenance cycle.

Product research events may include:

• Interviewing internal or external stakeholders.
• Conducting competitive analysis, marketing analysis, interviews, surveys, focus groups. 
• Analyzing collected data
• Conducting periodic sessions for collecting new user needs, problems, and benefits.

Modern markets and consumers are dynamic. Therefore, the periodic format of the research sessions is essential to ensure and maintain the business value of the product.

The product backlog is a popular term in product management and is considered as a list of items (user stories, requirements, or activities) needed to create the product. The entire product management office, product teams, and other organizational departments have access to it.

The product backlog may be considered as an alternative to detailed documentation in project management practices where it doesn’t exist as an artifact. Many modern product-oriented organizations, which do not need to document scope and detailed initial requirements, and have no formal approval of documentation phases, rely entirely on the product backlog as a source of information and requirements about the product’s needs. In this case, the product backlog may serve as a guide for both product teams and business stakeholders.

Product backlog items

Product backlog items types

Types of product backlog items may be:

• User story
• Change request
• Defect
• Research activity
• Technical improvement
• Use case
• Business requirements
• Functional requirements
• Non-functional requirements

User story

An informal and brief description of needs that may be part of the product. It is usually a written form representing the perspective of a potential user of the product regarding functionality or a feature. The user story describes the user who needs functionality or a feature, their contexts, and goals. A user story may match the following format:

As a (role), I need (capability), so that (receive benefit).

(role) - defines who needs something.
(capability) - the exact need
(receive benefit) a positive outcome for the requesting party (the user).

Example using this format:

As a customer, I need a solid package so the product can be transported safely.

Adding more context to user stories usually is useful for the product teams to define detailed product specifications. 

Example of adding more context to user stories:

As a user who has forgotten their password and does not remember the registration email, I need my account to be restored via phone, so I can continue to use it.

Product teams may use user stories as a source for detailed product specifications or create prototypes, sketches, graphics, and concepts.

Change request

If a change to the current product has undergone a change request process, the modifications may need to be added to the product backlog. 

Defect

Defects found on the product.

Research activity

Specific needs and functionalities may require preliminary research before real development. The research may cover technologies or development approaches.

To be adequately written down in the product backlog, the research activity should describe what exactly should be learned and the expected outcomes. “Spike” is one popular term for a research activity of this kind.

Technical improvement

Technical improvements can be executed if technical teams have previously developed rapidly parts of the product at the expense of technical quality.

“Technical debt” is one popular term for such cases. It regularly arises when the product needs to be delivered to an audience quickly or when deadlines are being met. Once the demonstrations have passed, technical improvements can be planned and added to the product backlog for further implementation. 

Use case

The Use case is usually a list or scheme describing the steps and events needed to complete a process. It can describe how functionality or parts of the product work or are supposed to work. The use case can be part of particular product backlog items or can be added to the product backlog itself as separate items.

Business requirements

Business requirements describe the high-level needs of business stakeholders related to a product. They can be considered as a more abstract concept than user stories.

Depending on their format and content, business requirements can be the equivalent of user stories if product teams and business stakeholders can operate efficiently using them (instead of user stories).

As a result, the business requirements describe a high-level presentation of business needs. Good practice when writing business requirements is adding a brief description of why a need is required and what value it adds to the product or organization. This addition is a good alternative to context and benefits detailing in user stories.

Product teams can use business requirements as a source for detailing product specifications or creating prototypes, sketches, graphics, or concepts.

Functional requirements

Functional requirements are created and used by technical teams. They typically describe the activities of a system or part of a product that needs to be implemented, so business requirements are satisfied.

Non-functional requirements

Non-functional requirements are often related to product quality. They do not describe behaviors, systems, functionalities, but rather requirements of quality, usability, efficiency, and other parameters.

Major product backlog items attributes

Each product backlog item may include the following major attributes and contents:

• Name
• Content
• Type
• Acceptance criteria
• Definition of done
• Size
• Priority

Name

The name describes the item in short.

Content

The actual content of the item. It may be a text, graphic, sketch, animation, or any other format depending on the item type and the needs of product teams and business stakeholders.

Type

The type can be useful for differentiating and filtering different kinds of product backlog items.

Acceptance criteria

Acceptance criteria is a popular term in software engineering and is closely related to acceptance testing procedures where parts of the product undergo different types of testing.

Acceptance criteria may be considered as a scope description of a particular product backlog item and of the exact created and tested needs in the context of the item.

They are usually created for teams that develop and test the product and are used as strict guidance. Informally, the acceptance criteria explain when the work on a product backlog item may be considered as completed.

Definition of done

The definition of done is a written description that formalizes that a product backlog item is really done in terms of development, testing, deployment, delivery, or formally accepted by stakeholders or customers. It may include particular steps, activities, and roles involved in the actual acceptance of the work.

Size

Describes the approximate amount of work needed for a product backlog item to be fully completed.

Priority

Shows the priority of a product backlog item.

Additional product backlog items attributes

Product backlog items may have many and unlimited attributes. Additional attributes can be “Status”, “Feature”, “Release”, “Start date”, “Completion date”, and many others, depending on the needs of the organization and teams.

Too many attributes, however, can make it difficult for teams to work and use the product backlog.

The BVOP suggests using business attributes that describe the business value of each product backlog item. Details are introduced in the Product Backlog Prioritization section.

Characteristics of the product backlog items 

The content of the product backlog items and all their attributes must be understandable to all teams and stakeholders involved in the product.

Incomprehensible content and attributes may result in product delays and cause misinterpretations and wrong implementations of parts of the product.

Too specific terminology may only be used if all participants in the product development are aware of it, and if this terminology usage will not lead to any loss of any kind.

Too long and complicated documentation or product backlog items may lead to delays in the work of the teams, as can insufficient information, which may also be the cause of waste, and wrong implementations.

The accuracy of the information is also of particular importance for fast and optimized product development.

The Business Value-Oriented Product Management (BVOPDM) office, together with development teams and business stakeholders, decides the attributes of the product backlog items, their types, and content.

Adding items to the product backlog

Backlog items are added in stages when new needs are identified as opposed to initially creating complete documentation or an extensive list of product backlog items.

New items added to the product backlog contain short content that only describes the needs briefly. Item attributes may also be skipped initially.

Details to documentation and product backlog items are added in stages when business stakeholders or development teams need them. 

Providing details when they are needed achieves speed and flexibility of the product development, while obsolete requirements and unnecessary work are avoided.

Adding items to the product backlog is recommended only as a result of the following activities and circumstances:

• Agreed and defined requirements in project management stages.
• Defined product requirements (user stories, business requirements, functional requirements) as a result of already discussed users or business needs, or other product research events.
• Requests from users with high product knowledge.
• Logical dependencies between user needs and business requirements.
• Requests from key stakeholders.
• Identified innovative breakthroughs.
• Functionalities and features, defined after competitive analysis.
• Collected needs, defined as important, after testing the product with users.
• Found defects.

If functionalities or product features are required by teams, offices, or stakeholders that do not have sufficient product knowledge, the requirement needs to be discussed with the requesting party repeatedly until the business value of the required functionalities or features is apparent.

The number of items in the product backlog should have a reasonable count in order to avoid chaos, lack of order, and massive product backlogs containing nonvaluable items.

The items at the top of the product backlog are considered to be the most important, meaningful, and have significant business value for the product or organization, and are usually developed before the tasks that are down the list.

Prioritization of the product backlog is an important activity executed by the product management office. Items order guides the upcoming work on the product and focus the attention of all teams in a given direction.

Product Backlog Prioritization is a part of the Product Backlog management activity.

Business attributes of the Product backlog items

The BVOP suggest that for transparent and accurate prioritization, each product backlog item needs business attributes like:

• Importance
• Urgency
• Attractiveness
• Long term
• Profit
• Cost-saving
• Time-saving
• Innovation

Attributes can have a numeric value and are taken into account when prioritizing the product backlog.

Importance

The importance level of the item. Presented with a numerical value (from 1 to 10, for example).

Urgency

Indicates how urgent the item is. Presented with a numerical value (from 1 to 10, for example).

Attractiveness

It presents the level of attractiveness for users. Presented with a numerical value (from 1 to 10, for example).

Long term

Represented with a boolean (yes or no) or a numeric value, for example from 1 to 10, where 1 does not mean a long-term benefit, while 10 registers a very long-term value or opportunity for the product or organization.

Profit

It symbolizes whether users or organizations will gain a profit from the realization of the item. It can be presented as a boolean (yes or no) or in a numeric value, for example from 1 to 10, where 1 can mean a very low-profit rate, or none, while 10 indicates high or guaranteed profit.

Cost-saving

Will the organization, users, or other parties save cost if this item is implemented? Presented as boolean (yes or no) or numerical value, for example from 1 to 10, where 1 means insignificant cost-savings, while 10 means very serious cost optimizations.

Time-saving

Is the item providing a time-saving opportunity for the product users? Presented as boolean (yes or no) or numerical value, for example from 1 to 10, where 1 means a minimal amount of time saved, while 10 means that users of other parties may benefit from substantial time saving opportunities.

Definition of business attributes

Each product backlog item may have more business attributes like “Speed level”, “Team enabling”, “Difficulty level”, and more.

The Business Value-Oriented Product Management (BVOPDM) office creates the business value attributes, decides their count, usage, and names.

The values of all the business attributes are validated with users with product knowledge. Best guesses for each attribute should be given. The initial given values may be changed later if new information about the users, product, or other factors is collected.

Business value points of the Product backlog items

All items in the product backlog need all their business attributes filled out, so calculations of total business points for each item are made easy.

Business attributes may be added or removed at any stage, but this may seriously harm the business points calculations, and all the product backlog items would need recalculations.

The total points of all business attributes of an item give an abstract representation of its business value.

For increased transparency and accuracy, the numeral values of the attributes may be based on questions and answers, where each answer represents actual value (from 1 to 10 or yes or no).

Example

Defining “Urgency” attribute

Product teams ask stakeholders a question like:

"What will happen if we do not implement this product backlog item this quarter?"

and provide predefined answers:

• Don't know (Represents numeral value 1)
• Nothing significant (Represents numeral value 2)
• Product, in general, may be harmed (Represents numeral value 3)
• The product will definitely suffer (Represents numeral value 4)
• Severe business losses (Represents numeral value 5)

Defining “Importance” attribute

Product teams ask stakeholders a question like:

"What is the expected users' adoption of this e item’s outcome of this item?"

and provide predefined answers:

• Don't know (Represents numeral value 1)
• Some of them will notice it (Represents numeral value 2)
• Some of them will use it (Represents numeral value 3)
• Most of them will use it (Represents numeral value 4)
• It is crucial for the entire product (Represents numeral value 5)

Providing predefined questions and answers for all business attributes to the stakeholders may return a clear total business value (business value points) of a product backlog item when all numeral values are summed.

In some cases, if stakeholders are not aware of the predefined answers they might provide more accurate and transparent information.

Product backlog items prioritization based on business value points

The total business value points of the items in the product backlog may be a criteria for prioritizing them. Ordering by business value points is a fully transparent backlog prioritization method where each item has a specific position in the backlog based on multiple business attributes and is validated by stakeholders.

Product backlog items arrangement based on business value attributes

Based on the users' and/or development needs, processes, resources, and other factors, the product backlog items may be reordered or filtered by any of the business attributes at any time. This allows the BVOPDM office to focus on specific items at any time.

For example, the arranging may be based on items with high “Urgency” and “Importance” values, which makes apparent the most important items that need to be developed as soon as possible. Ordering or filtering may be based on items with high “Innovation” and “Attractiveness” values, which gives more significance to items that may amaze the product users. If the order is based on items with high “Cost” and “Time-saving values”, the current product development effort is spent on optimization and profit-oriented functionalities.

Product development practices in the context of BVOP are focused on crafting concepts, designing prototypes, testing results, creating artifacts and final usable end-results.

Whatever practices are used for product development, the BVOPDM office needs to implement practices that ensure valid and actual end-results. Recommended steps include:

• Creating concepts.
• Validation of the concepts by users with product knowledge.
• Creation of functional prototypes.
• Users with product knowledge testing the prototypes.
• Creation of a usable end-result.
• Users with product knowledge testing the end-result*.

Users with product knowledge may be considered:

• Real users already using or intending to use the product or using a similar product
• Potential users
• Representatives with extensive product knowledge

*End-result: feature, part of a product, module or current version

Creating concepts

The concept in the context of the BVOP is not a functional prototype or any other piece of work that requires extensive time or resource consumption. Concepts may be drawings, videos, sketches, paper prototypes, wireframes, charts, explanatory text materials, or any other materials that can present an early idea and vision about the future product or parts of the product. 

The sources for the creation of the concepts are the product vision, the previously gathered information from internal organizational assets and external third parties or other users and sources with product and market knowledge.

Concepts have to be created fast to avoid time wastes and their ideas have to be presented clearly.

They present realistic user needs, solutions, and values.

Concepts validation by users with product knowledge

After a concept is created, a validation process needs to confirm its value and authenticity or reject it.

Users with product knowledge evaluate the concept during a validation session. Users point out the weak and strong features.

Validation session requires the participation of more than one individual because rejecting or accepting the concept is a group process.

If a concept is fully rejected, a new concept, presenting a clear idea, should be created as soon as possible. 

If a concept has some value, its positives are documented, and the following concepts are based on them.

Creating functional prototypes

After a concept is validated and approved, creating a functional prototype may provide a more valuable and precise vision of the end product or some of its features.

A functional prototype in the context of the BVOP is the result of a concept, which has been validated, accepted and includes a more realistic presentation of the product. It may be a physical model or very early-stage version of a software or other digital product.

The product features are usually only visually presented, simulated where applicable, or implemented at some working level with minimum efficiency and quality.

Prototype testing by users with product knowledge

Testing the prototypes ensures a level of confidence in the future development. After a functional prototype is built on some satisfactory level, it should be validated against the real user needs, experience, expectations, and usability issues.

Users with product knowledge test the functional prototype, and their feedback is recorded for future use in the prototype improvements and development.

Testing the prototypes for usability issues may be conducted with any popular user testing protocol, such as “Cognitive walkthrough”, “Think-aloud protocol”, “Wizard of Oz”, or any other suitable method.

Modifications, combinations, and creating custom testing protocols are also recommended.

After the test sessions, some issues are usually documented, and improvements on the prototype may be implemented.

Creating a usable end result

After the prototype is validated and agreed upon as satisfactory, the teams develop the real product or parts of it. At this stage, all the product concepts and prototypes are evaluated as accurate and reliable. The product development continues to the end-goals.

This stage is usually the longest and requires massive amounts of time, resources, communications, a collaboration between many teams inside the organization.

End-result testing by users with product knowledge

Just like the prototypes, the end-result needs to be tested regularly against real user needs, experience, expectations, and usability issues.

A test and validation session after every major update of the end-result prove that the product is being developed according to the precise needs and business direction.

It is good practice to create and maintain a brief record during product development that can help with all testing and validation in the future.

When the end-result is released, and it is in a real-world environment, it is strongly recommended to track, record and analyze the behaviour of a large number of real users.

Optimization practices are needed in every developing product and even in a complete and ready-to-use product.

The meaning of optimization in this context is changing. It can be understood as either adding new or removing existing parts of the product. In most cases, this usually means that the entire product development process requires more work and resources.

The product optimization practices in the context of the BVOP are:

• Pre-release optimization practices
• Post-release optimization practices

Pre-release optimization practices

During the development process, the entire product or its parts may be tested, validated, and agreed to be produced based on the users' and different stakeholders' feedback.

Depending on the general practices and goals of the BVOPDM office, repetitive analysis of the end-results may be applied.

The BVOP advocates that the users' feedback is not always correct or entirely valid. Human factors, cognitive biases, and other typical and natural occurrences may often come up during sessions of validations, testing, and providing feedback.

Careful users observations can be a tool to differentiate between the users’ feedback and their real actions to gather more realistic data.

Misalignments between users' feedback and their actual behavior should be recorded and may be used for future optimization.

Typical misalignments between users feedback and their behavior may include:

• Users request important features, but they are not used or barely used.
• The defined and validated at early stages tasks and needs of the user do not provide a satisfying outcome.
• Users provide positive feedback on product usability values when in reality, they experience difficulties.

Before an optimization action takes place, the BVOPDM office discusses the misalignments with the users who provided the feedback to find common points with their feedback and the observations.

If the communication is not possible, the optimization actions should be taken with high caution, so wastes and product degradations are avoided.

Post-release optimization practices

Once a product is in a real-world environment, expeditious statistics and feedback gathering are very important, so everything planned during the development stages can be matched against a real-world situation where significant access to real users is available.

If pre-release optimization actions take place and the product or some parts of it are improved and defined as satisfying, the real-world environment provides fast, and extensive knowledge about the way users use the product. Misalignments between the prognosis and the real usage may get identified.

The Business Value-Oriented Product Management (BVOPDM) office may plan and execute post-release optimizations if the noted misalignments get evaluated as harmful for the product, the users, the organization, the profits, or for other third parties.

Typical post-release optimizations may be implemented based on the following major reasons:

• User tasks and needs defined and validated before the product release don’t provide a satisfying outcome.
• Users are experiencing difficulties using the product.
• Harmful users' actions.
• The product is consuming too many resources.

Decisions making for optimization activities

Both pre and post optimizations may be applied if the Business Value-Oriented Product Management (BVOPDM) office decides that they are needed, and they do not damage any dimension of the BVOP.

Every decision for applying optimizations should always be based on predefined values.

All BVOPDM office members have to agree with the optimization but an acceptable rate of misalignments is always considered.

After a product is released to the market, and active users adopt it, its existence depends on the users' demands and the changes in different aspects like: 

• New or changing user needs.
• Different users' perceptions of the product.
• Users’ behavior changes.
• New skills accumulated by the users.
• Comparison of the product with competitive ones.

These dynamic variables require product support in many areas like strategies, marketing, sales, business, research, and development. 

New or changing user needs

With time products may change their target audience or their users may change their needs. 

For example, a user’s need may transform from “I need my bottle of water to be very light when I am jogging” to “I need my bottle of water to be very sturdy when I am jogging”. Or “I need my bottle of water to be very light and sturdy when I am jogging”. A single need may transform, but this may require extensive investments.

The Business Value-Oriented Product Management (BVOPDM) office keeps track of the changed or new user needs. There the decisions to improve the product or some parts of it are made, based on the magnitude of the users' demands and the estimated resources needed for applying the changes.

A typical question that occurs amongst the BVOPDM office members before making any changes should be “Can we change or adapt the product with minimum effort but fulfill the users demands to the maximum?”.

Different users’ perceptions of the product

Humans change their perception about the world and their surrounding environment regularly.

One event or object may be perceived differently over time. This characteristic of humans reflects on the emotions users feel towards a product and the periodicity of using it.

It is natural for people to feel disappointment towards a product or parts of it.

The BVOPDM office needs to be aware of these fluctuations and face them maturely.

Changes in users (behavior, opinions, perceptions, vision, needs) may be analyzed carefully as they may be a reason for unnecessary investment in product support activities.

Temporary and permanent changes have to be differentiated to avoid waste.

The BVOPDM office should invest in permanent changes before the temporary ones.

Users’ behavior changes

Users may change their behavior while using the product based on factors like:

• Usability issues
• Users’ needs leading to functional workarounds and hacks
• Disappointment
• Context and environmental changes

Usability issues

If the users are experiencing difficulties using the product, they may have a different than expected behavior.

If users cannot operate with some functions of the product with ease, they may stop using or find a different way to utilize it than desired.

User needs leading to functional workarounds and hacks

Some users may require a different or faster way to do something than the product is designed for. This distinction of users can make them look for other ways to accomplish a task. They may start searching for weak areas or forcing some functionalities to do something different than designed.

Disappointment

The disappointment of users is unpredictable and a hard to track variable. In most cases, it may cause a drop in product usage, but it may also provoke users to do harmful actions.

Context and environmental changes

Users may completely change the context in which a product is used or the environment they use it in.

Switching from desktop to mobile or wearable technological products is a typical example.

Users may change their entire surrounding environment. Swapping from work to the gym or from at home to the mountains are typical examples that can lead to a complete change of behavior.

New skills accumulated by the users

The longer users are exposed to the product, the more skills they accumulate. They gain knowledge, which may lead to different use of the product.

Comparison of the product with competitive ones

It is natural for users to compare the products they use with other ones. Users have their feelings and emotions about the products around them, and their final decisions are based on multiple factors like:

• Emotional factors
• Cognitive factors
• Functional factors
• Practical factors
• Social and other beneficial factors

Emotional factors 

Emotional factors include the way users feel about a product at a given time. These factors may be unpredictable and may be based on:

• Users’ past experiences
• Current emotional state
• Surrounding environment
• Cultural specifics
• Influences by others 

Cognitive factors

A simple definition of cognition is the process of humans learning, remembering, and using new information. Every person learns with different velocity, intensity, depth, and understanding. 

Users may compare products based on their cognitive abilities.

Functional factors

The functional capabilities of a product may be crucial for positive users’ impressions. What the product has to offer is very important in deciding whether users “like” the product or are ready to use it.

Functional factors are also related to the affordance and the usability state of the product.

Practical factors

After assessing the functionality of a product, users can envision its incorporation in their own lifestyle.  Some may find more practical applications than initially designed ones. If they discover more value in a product, they may change their behavior and try to adapt it according to their own needs. Users see this adaptation as a benefit, and they gain their general positive impression of the product.

Social and other beneficial factors

Users may compare products based on how they affect their social status. Any additional benefit for them may be considered as a positive and may also be included in the comparison process.

Tracking, observing and analyzing users

Product support activities need to implement tools, procedures, or any other practices that help the BVOPDM office in making decisions on what, how, why, and when to support.

Tracking the behavior of a significant enough amount of real users is the most realistic and valuable mechanism for collecting data about the status of the product and its users.

Observing and adjusting

The BVOPDM office may have a large number of activities. A lot of practices, procedures, and tools may be involved in product research, development, and support. A lot of interactions between organizational assets and third parties are often required.

The entire product lifecycle is usually a time and resource consuming process.

Observing the processes and practices for wastes is an important activity that saves the organization time and resources.

Business Value-Oriented People Management (BVOPPM) is a management style and a set of activities focusing on managing all people across an organization at all levels.

BVOPPM office needs an understanding of the general problems, responsibilities, and activities of all other offices, departments, teams, and individuals because the activities of the office may be more productive and efficient.

Activities of the Business Value-Oriented People Management office

Major activities of the Business Value-Oriented People Management office include:

• Establishing a people-and-business-oriented culture
• Spreading culture across the organization
• Aligning people with organizational strategies
• Mediating standpoints
• Motivation management
• Commitment management
• Personal development management
• Emotions management
• Conflicts management
• Fear management
• Workforce status analysis
• Organizational attitude analysis
• Candidates management
• Onboarding
• Offboarding
• Leaving and dismissal reasons management

Establishing people-and-business-oriented culture

The Business Value-Oriented People Management (BVOPPM) office develops a people-and-business-oriented culture in which everyone in the organization is perceived and treated as a human being and a business partner at the same time. The culture supports formal and friendly relations equally because this helps people to relate to each other openly and positively. At the same time, all responsibilities are taken seriously.

The BVOPPM office creates cultural and behavioral rules and suggestions or modifies them when needed. The modifications are based on the perception and adoption of the culture by the people.

People-and-business-oriented culture may include:

• Treating everyone as a person and a business partner at the same time.
• Respecting others' emotions, feelings, and peculiarities.
• Respecting others' time and responsibilities.
• Accepting and following organizational strategies and missions.
• Business etiquette.
• Positive and supportive attitude. 

Spreading culture across the organization

The culture of the organization needs to be spread across all offices, departments, teams, individuals, and even to external interested parties that may need to understand it and align their interactions with the requirements.

A culture that involves personal and business relations may not be easy to establish and understand. 

Accepting and understanding a specific culture may need time and effort. Some people may not comprehend the ideas and goals of the organizational culture, which is normal.

People usually perceive and accept ideas and behavior when they experience them first. Accepting new ideas needs time.

The organization is a group of people, and the understanding of the organizational culture may depend on many factors like experience, skills, culture, age, or cognitive perceptions.

Different persons may have different perceptions about the organization, its priorities, processes, and even their attitude towards others may vary. These differences may be a reason for conflicts, low motivation, productivity decline, information loss, and may cause delays in communication.

Aligning people with organizational strategies may be considered as initial risk management at every organizational level.

Organizational strategies may include:

• How the organization makes its profit
• How the organization expands
• Why specific approaches are chosen
• What the organization expects from all involved parties and individuals
• What the organization gives in return
• Management styles
• Specific custom culture
• Branding and image
• Short term and long terms goals and plans for achieving
• Investments
• Acquisitions
• People management
• Product management
• Project management
• Service delivery
• Finances
• Marketing
• Public Relations
• Sales strategies
• Research and developments
• Technology

All fields, topics, and areas may have a specific organizational vision, plans, approaches, and styles.

Awareness, agreement, and commitment from the entire organization, offices, departments, teams, or individuals may be essential for achieving the organizational goals.

Mediating standpoints

The organization is a mixture of the knowledge, expertise, skills, and personalities of all its people. This variety is usually helpful for organizational activities, but it should be kept in mind that people may have different points of view, needs, and visions.

Sensitive topics may need the involvement of the Business Value-Oriented People Management (BVOPPM) office. Disagreements, remuneration discussions, and any different standing points that require the involvement and attention of the BVOPPM office need to be processed with attention and understanding of each side, so optimal solutions are found, presented and agreed upon.

Motivation may be considered as a general willingness for involvement in activities and an emotional state. It may fluctuate, and different factors may influence that.

Motivation may also be considered as a total result of someone's perception, self-confidence, beliefs, emotions.

The Business Value-Oriented People Management (BVOPPM) office participates in improving the perception and self-confidence of individuals inside the organization, discusses beliefs, and supports individuals in managing their emotions.

Additional factors influencing people's motivation may be external subjective negative or positive events, in an organizational context.

Negative events and factors may include:

• Low wage
• Poor working conditions
• Comparing to others
• Rumors
• Reprimands
• Harassment
• Abuse
• Discrimination
• Overwork
• Inadequacy
• Lack of development opportunities

The Business Value-Oriented People Management (BVOPPM) office needs to be aware of these and all other possible factors and events that may cause drops in people's motivation and try to improve it.

Positive events and factors may include:

• Spreading a noticeable people-oriented culture
• Organizational stability
• Meaningful work
• A general sense of stability
• General sense of purpose
• Clear responsibilities
• Realistic objectives
• Professional and personal development
• Acknowledgment
• Recognition
• Announcing of achievements
• Positive management style
• Transparency
• Clear bonus system
• Social packages
• Healthy working environment
• Modern working environment

The BVOPPM office participates in supplying these factors or organizes events with other organizational offices.

Commitment management

If people’s motivation is at some satisfactory level, this does not mean that their commitment automatically increases.

The commitment may be considered as a habit and as a part of a person’s personality.

Some people are more committed than others. Those with low commitment may cause waste for the organization.

Motivation is a factor, which enhances work, speed, communication, and participation in activities. Still, the BVOPPM office may need to train people or organize their activities, so the desired level of commitment can be achieved with time.

The BVOPPM office participates with other organizational offices to define clear, measurable objectives and comprehensible outcomes of the commitment or its low levels.

Personal development is essential for both people and organizations, and its outcomes may include:

• Increased self-confidence
• Improved or new skills
• Increased motivation
• Increased productivity
• Improved behavior
• Increased commitment
• Improved communication
• A better understanding of processes and management
• A better understanding of objectives and missions
• Applying knowledge and expertise
• Developed mature reactions and adaptation to changes
• Maintaining mental state
• Supporting initiatives of others

The Business Value-Oriented People Management (BVOPPM) office creates plans for personal development that contain clear objectives, definitions, and instructions.

Personal development management may include:

• Improving self-awareness
• Identifying weaknesses
• Improving skills or learning new ones
• Identifying and developing strengths or talents
• Improving social or health status
• Improving work-life balance

Before initiating personal development activities, the BVOPPM office teaches people inside the organization why this is important and how it can be accomplished.

Emotions are related to the subjective perception of people’s surroundings and their behavior and opinions towards it. They may change based on the current context of the environment or past experiences.

The basic emotions of humans may be listed as happy, excited, tender, scared, angry, and sad. They can be split into positive and negative.

People make decisions based on their emotions all the time, and there may be a case where these decisions may not be positive, productive, or lead to a common good.

The Business Value-Oriented People Management (BVOPPM) office establishes emotions management strategies for situations like:

• Emotions cause a drop in productivity.
• Emotions may cause bad decisions making.
• Conflicts between people that lead to negative outcomes.

The BVOPPM office may organize staff training practices and sessions, as well as similar activities that can deliver positive and productive results within the organization.

While conflicts may result in improved outcomes, they may be a reason for drops in motivation, waste of time and resources, people leaving the organization, or negative organizational image.

The Business Value-Oriented People Management (BVOPPM) office needs to manage the conflicts, reduce their negative aspects and create a positive outcome to some degree.

Conflict management activities may include:

• Identifying the parties
• Identifying the issues that cause the conflict
• Sharing concerns
• Cooperation
• Conceding
• Agreements
• Accepting
• Post-conflict support

Identifying the parties

Identifying the parties may include:

Which specific individuals are involved in the conflict

Conflicts may involve more than two individuals. All of them need to be identified and informed about the conflict, and a session with the BVOPPM office representatives needs to be scheduled.

The roles of the individuals in the organization

Identifying the roles, positions, responsibilities, skills and other attributes that may provide information about the parties involved in the conflict

The context of the individuals

The context (reasons for conflict, concerns, etc) of the parties may provide an initial understanding of the conflict.

Identifying the issues that cause the conflict

Identifying problems may require interviewing the parties directly and investigating problems, emotions, tasks, or events. The root cause of the conflict must be understood.

Sharing concerns

Sharing concerns needs the participation of everyone involved in the conflict. Concerns and feelings are clearly stated. BVOPPM office representatives listen and collect the shared information.

Cooperation

The BVOPPM office representatives need to define the steps necessary to ensure the cooperation of each party and make a statement of the way it may assist in the collaboration between parties.

Each party shares their needs, demonstrates possible outcomes, or requests specific support from the other party. All parties cooperate on finding possible solutions.

Conceding

Each party needs to understand the possible solutions, their advantages, and disadvantages, the way the conflict affects the other parties, the organization, and the common business goals. Comprehending the conflict, mistakes, and the emotions felt for the particular issue is required before the parties agree on a specific solution.

Agreements

Everyone involved in the conflict has to officially agree on the solutions.

Accepting

A more in depth approval of others' solutions, skills, competence, and emotions is a slow process that may require time. The parties and the BVOPPM office representatives may schedule further sessions where the general acceptance is discussed.

Post-conflict support

If needed, the BVOPPM office monitors the topics and individuals connected to the conflict after it has been resolved and interferes with advice and support.

The BVOP introduces fear management as a significant activity of the Business Value-Oriented People Management (BVOPPM) office. Fear may be a root cause of different losses and wastes in areas like:

• Productivity
• Proactivity
• Communication
• Information

The result from fear may be:

• Not taking any actions
• Taking improper actions
• Not getting involved in communications
• Lack of commitment
• General passiveness
• Avoiding events and situations
• Concealment
• Providing wrong information
• Developing incorrect or unneeded work

All these results may cause waste and serious losses may be considered. The Business Value-Oriented People Management (BVOPPM) office needs to be aware of these general fear-driven potential results amongst individuals inside the organization and try to minimize them.

Fear may include the following aspects:

• Embarrassment
• Deposing
• Dismissal
• Reprimand
• Criticism

Workforce status analysis

If the organization is not aware of its workforce status, it may not plan its future or current initiatives correctly. Motivation, conflicts, skills, tools, and personnel efficiency and sufficiency may be subjects of analysis, reports, and monitoring.

Organizational attitude analysis

The senior management’s general attitude may be a core source of the entire organizational attitude and vice versa. The personnel’s attitude may affect the entire organization’s on every level.

The BVOPPM office analyses the general organizational attitude, assists in its management, and supports all departments, offices, key roles, and individuals in planning and maintaining a positive atmosphere.

Candidates management

Candidates management may include the following activities that require particular focus:

• Defining job descriptions
• Candidates interviews
• Post-interview activities

Defining job descriptions

Before new candidates are processed, the job descriptions need to be clearly defined and announced with strict and precise responsibilities and desired skills from the candidates. 

The new applicants need to understand if their profiles and skill sets match the position before they wish to apply. A clear understanding of the job descriptions may prevent time waste for applicants and the organization.

Candidates interviews

Before attending an interview, the candidates need to know and understand the entire hiring process. They need to be aware of all interview stages, tasks they may have to do, and all additional information like the participants, the location, the languages used, and the required materials.

During the interview, the Business Value-Oriented People Management (BVOPPM) office representatives ensure that all discussions, test sessions, or demonstrations are relative to the position and are conducted positively and openly.

After the interview, the Business Value-Oriented People Management (BVOPPM) office representatives inform the candidates of when to expect feedback and all potential further processes.

If candidates do not match the criteria, BVOPPM office representatives share with them the reasons why they are not chosen for the position, the areas they lack skills in or specific qualities they have that do not match the organizational needs.

Onboarding

The organization may need to determine the characteristics, skills, behavior, and personality of the desired personnel. The Business Value-Oriented People Management (BVOPPM) office participates in defining these attributes together with other offices and makes plans for hiring needed individuals. 

The BVOPPM office representatives may participate in the following activities related to the new members of the organization:

• Discussing job descriptions and responsibilities.
• Providing a proper environment, tools, access to workplace, databases, products, and a tour.
• Organizing a plan for acquiring specific skills.
• Organizing knowledge sharing from other offices, departments, teams, or key roles.
• Assisting in formal, informal, individual, and collective socialization.
• Presenting and requiring specific behavior aligned with the organizational culture.
• Presenting regular organizational events, strategies, or plans related to the new members.
• Presenting possible paths for development and career growth inside the organization.
• Presenting communication channels with the organizational offices.
• Presenting the available support from human resources offices and how the members can approach representatives.
• Presenting social packages and bonus schemes.
• Presenting principles like proactivity, responsibility, ethics, and need for personal and professional development.
• Establishing a strong and positive relationship with supervisors and direct managers.

Offboarding

Offboarding is the process of separating the employee from the organization that involves multiple planned steps.

Separation is a sensitive matter, as in some cases, it is related to negative emotions. The BVOPPM office participates fully in managing potential negative emotions from both employees and organizational sides and focuses on positive outcomes for both.

Other activities of the BVOPPM office related to the offboarding may include:

• Analyzing the reasons for leaving or dismissal  
• Assist in resignation or dismissal.
• Sending off-boarding notifications to interested parties.
• Organizing and assisting in knowledge transfers.
• Organizing environment, tools, databases, and access resetting.
• Organizing and conducting an exit interview.

Leaving and dismissal reasons management

The BVOPPM office maintains a list of general reasons for people leaving the organization and dismissal factors. It plans improvements in human resources strategies and participates in improving the strategies of all organizational offices.

By the 1950s, Japan was in the midst of war. However, in less than 30 years it became an economic giant and ranked second in the world. This draws the attention of scientists and specialists to the Japanese model of management.

Comparative analysis of Western and Japanese management points out the following differences.

Western management is characterized by:

• Individual decision-making process.
• Individual responsibility.
• Precisely formulated management structure.
• Linking salary and career with individual results.
• Training of narrowly specialized experts.
• Formal relations between managers and subordinates.
• Easy and frequent transfer from one company to another.

The analysis of the Japanese management system shows significant differences in its business principles.

There is lifetime employment in Japan. Moving from one company to another is very rare and not well accepted. This leads to the stability of the composition of companies and their divisions. Favorable preconditions are created for the emergence of informal relationships and connections. 

This reflects on the following outcomes:

• Collective responsibility
• Group forms of control
• Informal relationships
• A priority of group achievements.

Collective methods are preferred in decision-making processes.

A consensus is preferred when making a decision, although the procedure for reaching consensus may take time.

The selection, evaluation, and promotion of staff in the Japanese model are also specific. Young employees entering Japanese companies are not required to have prior professional training.

Employees must go through all the positions at the lowest hierarchical level before starting to climb the hierarchical ladder. The employee is strictly observed. 

An employee with a lower position can’t take the place of his/her superior until he/she has been appointed to a higher position.

BVOP recommends for the staff to explore the possibilities of the following approaches:

• A long-term career in one organization.
• A slower process of professional growth.
• Making team decisions by consensus.
• Achieving a high degree of trust between employees.
• Constant care for the people in the organization.

Every business organization needs a clearly defined list of goals and priorities. These priorities need to be defined carefully and prioritized based on the strategies of the organization and its mission. The future of an organization is based on current activities and how they are executed.

General priorities may include:

• Cost management
• Optimizing financial leverage
• Bond rating
• Optimizing budget
• Diversify revenue streams
• Value versus cost
• Cross-selling
• Partnerships
• Innovation
• Customer focus
• Workplace safety
• Skills improvement
• Image improvement
• Investing in tools

Cost management

Planning and managing costs is an essential activity that may require careful budgeting and allocating financial resources for planned projects, investments, or other initiatives. The organization may try to predict impending expenditures or to survive unexpected or challenging periods.

Optimizing financial leverage

Financial leverage describes how much of an organization's assets or investments are self-funded and how many come from borrowed funds (loans, bonds, etc.).

If an organization uses mainly its own funds, it may be unsuited for larger initiatives. Using mainly borrowed funds is a high risk.

Organizations need to decide strategies, priorities, and manage risk. The borrowed funds are used only for increasing their own capital or for equity. Optimizing financial leverage may be related to optimizing internal financial resources.

Bond rating

The bond rating indicates the credit quality of a bond. It helps potential investors to decide whether to invest in a company or not. If an organization prioritizes its bond rating, this may be related to optimizing financial resources.

Optimizing budget

Optimizing budgets may be a general goal and a priority for a business organization and it may not be related to any financial leverage optimizations or bond rating improvements.

Diversify revenue streams

An organization may decide to receive revenue from multiple sources or products and services. 

This may require acquiring or developing additional products or services and typically calls for investments.

Value versus cost

Sales initiatives focused on the customers and their understanding of the product or service and the way prices match their expectations.

Cross-selling

This may include the strategy of selling more products to the same customers.

Partnerships

An organization may focus on establishing close partnerships with their clients or other organizations. This is a typical priority that occurs when designing solutions are dependent on customers' participation.

Innovation

An organization may need to differentiate its products or services by investing in innovation. This is usually related to investment in research and development (R&D), tools, environment, analysis, tests, and more, attracting great employees, and establishing a good reputation.

Customer focus

Customer satisfaction and excellent services may be critical for a business. Customer retention and marketing initiatives may be a priority if the organization depends on its existing customers.

Workplace safety

Authorities may require workplace safety, or this may be an organizational decision. This requires the focus not only from the business (the organization) but from all the employees as well. Training, equipment, and policies may be needed.

Skills improving

Investing in employees' skills may be a priority and an objective for organizations when they rely on highly skilled teams.

Image improving

Image may be important when organizations request an investment, need to extend markets or attract quality employees.

Investing in tools

Equipment and tools may be of high priority for a business, especially when they relate to manufacturing, procurement, development, or training.

Without such priorities and planned resources, the organizations may not be stable for the long term. All BVOP office representatives and key roles need to be aware of the current organizational priorities, and why the organization takes or does not take particular actions, investments, or directions.

The BVOP suggest additional and necessary priorities on which organizations need to focus:

• Growing an internal positive atmosphere 
• Managing organizational issues

Growing an internal positive atmosphere 

Positive attitude, confidence, and calmness are equally important for both people and businesses.

Confident and positive people are more productive, and bigger production rates increase profit and image. Business initiatives are developed faster.

Stress and fear need to be reduced and managed, and everyone should act proactively without fear of being penalized verbally, formally, informally, financially, or in any other way.

The organization creates and provides a positive atmosphere with the support of all offices.

Transparent board of organizational issues

The BVOP introduces the transparent board of organizational issues as a tool for managing and solving internal or external problems. It may be a list of current organizational, structural, management, or supply issues that reflect on image, productivity, morale, innovation, or other topics important for the organization.

It is a regularly updated list, and its items need to be prioritized.

The transparency of the list provokes a fair and clear definition of problems. Multiple organization management offices and key roles have access to the list and update it when needed. These can be interested parties such as C-Level positions, portfolio and program directors, human resources directors, and other roles in the organization that can support its productive management.

All offices, executives, or key roles managing the transparent board of organizational issues should commit to solving the prioritized problems (from top to bottom). If one at a top position cannot be processed or resolved at a current stage, the interested parties focus on the next from the list.

Understanding and aligning with priorities

All office representatives and important roles need to have an understanding of organizational priorities and strategies and align with them. Organizations may need support and understanding not only from C-level positions or high management but from many teams and individuals during critical periods, or large-scale initiatives.