Work breakdown structure (WBS) is yet another very important aspect and deliverable of the project planning process. In this stage, you break the project into small and atomic individual activities that can be managed efficiently. In a work breakdown structure, you need to identify the smallest units of the work items that can be started and completed as a unit. A work breakdown structure provides a bird’s eye view of the project and helps identifying various dependencies in the project. Work breakdown structure is the key deliverable of the project planning and forms an input for various planning activities.
For the project management team, a work breakdown structure is a key deliverable. It is a decomposition of a project into smaller components. Each component by itself has a well defined deliverable and might be an input for another component. Creating a work breakdown structure enables the team to organize the entire work of the project into manageable sections and avoid any ambiguity.
According to the Project Management Body of Knowledge (PMBOK) guide, the work breakdown structure is defined as “A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.” A component of element of a work breakdown structure can be data, product, service, or it can be a combination of these elements. A well defined work breakdown structure not only provides you with a framework that you can use to create a detailed cost estimation and control, but also enables you to create a detailed schedule and help controlling it.
When you create a work breakdown structure, it is essentially a hierarchical decomposition of complex project into simple phases, deliverables, and work packages. It is usually an inverted tree structure; with each branch of this tree you indicate a subdivision of efforts required to accomplish an objective. To create a work breakdown structure, you start with the final objective of the project and then subdivide it into manageable components. You can define these components based on the size, duration, and responsibility. Each component includes all steps that the team needs to perform for achieving the objective.
One of the most important objectives of creating the work breakdown structure is to provide a framework for dividing work into definable units of work. You can use this structure for overall planning and control of the project and even to define the statement of work. Further, you can use the work breakdown structure to establish schedule, cost, and labor hour reporting.
A work breakdown structure also enables you to sum subordinate costs of the tasks and materials of the components into the tasks and materials of the parent component. You must provide a description of the tasks to be performed for each element of the work breakdown structure. You can also use the work breakdown structure to define the complete scope of the project.
One thing you must keep in mind is to focus the work breakdown structure around product of the project and not around the tasks needed to perform to produce the product.
Before you start a project, you must define its scope. This is very important stage of the project management because the scope of the project defines the entire course of the project and its life cycle. It is a general practice that stakeholders tend to change their requirements or even attempt to push new requirements to the project. This not only adds to the work but can also impact the morale of the project team if the changes or additions of the requests tend to change the complete course of the project. Therefore, it is not only important but a must to finalize the scope of the project before you start it.
When you define a scope of the project, the main concern for you is to decide on what is inclusive and what is exclusive for the project. Additionally, you must decide on the deliverables of the project.
To define the scope of the project, you take inputs from the project charter, requirements document, and any information available about the risks, constraints, and assumptions associated to the project. It is important to understand that the project scope forms the axis of a project and defining it is an important stage of project planning. Any ambiguity and lack of clarity in the project scope is capable in making the complete project a failure. However, a well defined project scope accepted by the stakeholders can guarantee a success.
One thing you must keep in mind is that any stage of the planning process is iterative. So is true with defining the project scope. You use the project management processes to determine the schedule and budget of the project, which are the integral part of the project scope. It is not always that the management and stakeholders agree to the budget and schedules at just first or initial few iterations. If the project schedule and budget does not meet the management and stakeholders’ expectations, then you might need to balance the project requirements, which in turn is the project scope, with respect to the schedule, budget, and other constraints in the project. This process might need you to fast track some of the activities or schedule compression. After balancing the requirements, you need to present the redefined project scope to the management and stakeholders. You might need to iterate this process several times to come up with the project scope that meets cost, schedule, and scope objectives of the project before the management and stakeholders agree to the project scope and signs it off. The final result of these iterations is a realistic schedule and budget that can accomplish the scope of the project.
However, it is important for you to understand that not every change or additional request is rejected during the life cycle of the project. Changing market conditions and competition products might make it compulsory to make changes to the ongoing project scope. You keep iterating the process of defining the scope of the project throughout the life cycle of the project depending on the requests received from the stakeholders. In this process you keep deciding what is inclusive and what is exclusive for the project.
According to the PBBOK guide of the Project Management Institute, the outcome of this process (the Define Scope process) is the Project Scope Statement document. This document clearly states what an approved project is and what is the scope of the product – the final outcome of the project. The Project Scope Statement document is not an outcome of a day or two but you might take several days to complete this document. To finalize this document you might need to seek expert judgment of several stakeholders within the organization as well as experts from outside the organization. When creating this document, you must identify the areas that some stakeholders want in the scope, but were not approved for adding to the scope of the project. Additionally, in this document you must clarify the ambiguous areas that are capable of adding any misunderstanding to the scope of the project. Therefore, in the Project Scope Statement document, you should not only specify what is included in the project, but also what is not included in the project and such additional are not allowed to be added to the project.
A typical Project Scope Statement document consists of the following sections:
After you have collected the requirements by using either manual methods or using software utilities, you move a step forward towards defining the scope of the project. As the next step, you collate the requirements you have collected from the stakeholder. It is not that all the requirements from every stakeholder makes into the final list of requirements. You have to meticulously study each and every requirement before you decide to include it in the final list. Depending on the merit of the each requirement, you include the requirement for the project.
To collate stakeholder requirements and finalize the project requirements, you must complete the following tasks:
After you have collected requirements from all the project stakeholders, you must collate all the requirements at single location so that you do not miss out on any of the requirement. As discussed earlier, it is not that every stakeholder requirement can make it to scope of the project. You must make decision on the merit and importance of each requirement before selecting it for the project scope.
The requirements you have collected form the stakeholders might have several conflicting requirements. Therefore, you must review, analyze, accept or reject, and prioritize the requirements you have collected. To complete this exercise, you can either get a consensus to nominate a person, maybe yourself, or create a group of reviewers to make the decision of accepting or rejecting the requirements.
Assigning one person to make decision on behalf of the entire group is known as dictatorship method. It is simple and faster method. However, it can negatively impact the decisions because of biasedness, if any. Additionally, some of the stakeholders might not buy in to the decision made by a single person.
Opting to create a group of reviewers to make decisions is known as plurality method. In this method, a decision to accept or reject a requirement is made by taking majority approach. Usually, the group chooses the requirement that is backed by more than half of the members. However, if there is a fractured mandate, then the group goes with the decision that has largest number of supporters.
Create the Requirements Document
After you have collected and finalized the requirements, you must document these. The document you create as a result is known as Requirements Document and is an outcome of the Collect Requirements process defined in the PMBOK guide. Creating a Requirements Document makes sure that the requirements are clear and unambiguous. You can use this document to verify the requirements with the stakeholders and get their acceptance.
Balance the Stakeholder Requirements
As a project manager, it is very important for you to balance the stakeholder requirements. To balance the stakeholder requirements, you must make sure that you can meet the requirements within the objectives of the project. If you cannot meet the stakeholder requirements within the objectives of the projects, then you need to consider adjusting the scope, time, cost, quality, resources, risk, and customer satisfaction of the project. To balance the stakeholder requirements, you also need to prioritize the requirements and resolve conflicts, if any, among the requirements.
In the interest of the project, you must balance the stakeholder requirements that might or might not match the project or other stakeholder requirements. You must balance and resolve such requirement conflicts in the interest of the project. However, you must have clear project objectives before you can balance or resolve conflicts in the stakeholder requirements. Otherwise, it could become a very difficult task for you to balance and resolve stakeholder requirements in absence of the clear project objectives. Additionally, it would be easier for you to balance and resolve conflicts in the stakeholder requirements if you have identified prioritized all the requirements you have collected form all the stakeholders.
This is an ongoing process you would find in a real world projects. You might keep getting new or modified requirements from the stakeholders throughout the life cycle of the project. However, in the interest of the project, you must balance these requirements.
Resolve Competing Requirements
Different departments involved in the project life cycle have their own objectives and priorities set for the project. As a result, requirements from one department might conflict the interests of another department. For example, the aim of the development department might be to keep the defects in the project to be low even if they need additional resources. On the other hand, the objectives of the finance department could be to keep the budget or cost of the project as low as possible, thereby, conflicting the requirements with that of the development department. However, you must manage the requirements keeping the project as a whole in the mind and not according to the requirements of an individual stakeholder. Even if you need an intervention from the management, you must resolve such conflicts in the interest of the project.
When resolving conflict, you must keep in mind that you should accept only such requirements that comply with the business case for which the project was started, project charter, project scope statement, and project constraints. If the stakeholder requirement does not comply with these, you must reject the requirement. You must also reject a requirement that does not add something related to the business case of the project.
Create a Requirements Management Plan
As is the case with any activity of managing a project, you must plan to manage project requirements. When creating the plan to manage the requirements, you must describe the methods you plan to use to identify the requirements. Additionally, you must specify how you intend to analyze the requirements, prioritize the requirements, manage the requirements, and track the change requests for the requirements.
Create a Requirements Traceability Matrix
One of the biggest conflicts seen between the customer and project team is that the project delivered to the customer does not map to the actual expectations of the customer. This issue mostly arises when you do not have the requirement traceability matrix. This matrix helps you to track the requirements through out the life cycle of the project and makes sure that the actual requirement is addressed in the product.
When you start the process of identifying requirements, it might result in further refinement of the requirement. This, in turn, might completely redefine the requirement and you might lose track of where the actual requirement came from. To avoid such situations, you can create a requirements traceability matrix in a tabular form. The table contains an identification number for each requirement, its source, person assigned to, and the status of the requirement. Such matrix can help you to trace each and every project requirement and help you manage the customer expectations accordingly.
Before you start planning for a project, it is important for you to finalize the scope of the project. However, you cannot finalize the scope of the project unless and until you know the requirements of the project, which you need to collect from all the stakeholders of the project. Requirements are defined as the outcome or capabilities that the stakeholders want see in the product to be developed in the project. In addition to the outcome or capabilities of the product, the requirement might even state other expectations, such as the quality standards of the product. Therefore, when collecting requirements from the stakeholders, you not only need to collect the product requirements but also the overall expectations of the stakeholders from the project.
The project charter that you receive from the Project Management Office already contains the high level requirements from the stakeholders. Therefore, the aim of collecting requirements at this stage is to get elaborated and specific requirements from the stakeholders. Collecting such information is very critical for the project because if you miss even seemingly small requirement, it can be capable of changing the entire course of the project and raising conflict throughout the course of the project, which ultimately might result in the complete failure of the project.
One of the methods to collect requirements from the stakeholders is by using various software utilities, wherein; you need to use certain software applications or tools to collect the requirements from the stakeholders. You can use any of the following software utilities and techniques to collect the detailed requirements from the stakeholders:
Mind Maps:Mind map is a graphic utility that you can use to understand the requirements, and arrive at the scope of the project. Even though you can manually create mind maps for the project requirements by using pen and paper, there are many automated utilities available in the market that you can use to create mind map for the project. Mind map is a graphic representation of the flow of ideas or requirements for the project. It is a diagram that you use to visually organize information. You generally create a mind map that joins various information and requirements on a project and shows the relationship among the different requirements. To start with, you create an image or just a simple box depicting the project. Now, you start with a branch that depicts an idea for the project and keep branching it by adding further ideas or requirements till it reaches the minute level of information on requirements for the main idea or requirement. Similarly, you repeat the process of depicting other major ideas on the mind map. You must connect all major ideas or requirements directly to the image representing the project. After you have completed the mind map for the project, you can read each branch like a story when explaining the requirements for the project.
Delphi Technique: Delphi technique is a method that you can use to estimate the probability and outcome of the future events. It is a quantitative technique you use to arrive at a consensus. In this technique, as a facilitator, you seek information from a group of experts who participate anonymously. After you receive responses from them, you compile the same and send the results back to the group for review. You iterate the process until you arrive at a consensus.
Questionnaires and Surveys: Questionnaires and surveys are the methods you can use for a large group of stakeholders. When preparing a questionnaire, you create a series of questions and prompts relevant to the project, and provide sufficient space for response. After conducting surveys with the stakeholders using the questionnaire, you collate the information and arrive at the requirements for the project. You can use various online as well as offline survey utilities to collect requirements from the stakeholders.
Prototypes: Prototype is yet another effective method of collecting requirements from the stakeholders. You create a functional or non functional prototype according to the initial requirements you could gather and understand. You demonstrate this prototype to the stakeholders and, at times, let them play around with it, and seek feedback from them. Base on the feedback from the stakeholders, you might need to update the prototype for a few iterations until the stakeholder requirements are finalized.
Observations: Observations is a method in which you might need to use the job shadowing technique, where you must observe the potential user of the product working with the existing system that includes the manual system if it is still not automated. At times, this method might also require you to participate in the work to understand and identify the requirements.
Affinity Diagrams: Affinity diagrams are considers as on of the seven effective tools for management and planning. Affinity diagram is yet another graphical utility that you use after you have gathered requirements by using other methods discussed earlier. Here, you get all the requirements sorted and bucketed into groups based on the similarities. You assign title to each bucket or group of requirements for its identification. The sorting and bucketing the requirements makes it easier for you to identify the set of requirements as well as additional scope, which might have gone unnoticed earlier. This method also helps in identifying some of the risks associated to the project.
Before you start planning for a project, it is important for you to finalize the scope of the project. However, you cannot finalize the scope of the project unless and until you know the requirements of the project, which you need to collect from all the stakeholders of the project. Requirements are defined as the outcome or capabilities that the stakeholders want see in the product to be developed in the project. In addition to the outcome or capabilities of the product, the requirement might even state other expectations, such as the quality standards of the product. Therefore, when collecting requirements from the stakeholders, you not only need to collect the product requirements but also the overall expectations of the stakeholders from the project.
The project charter that you receive from the Project Management Office already contains the high level requirements from the stakeholders. Therefore, the aim of collecting requirements at this stage is to get elaborated and specific requirements from the stakeholders. Collecting such information is very critical for the project because if you miss even seemingly small requirement, it can be capable of changing the entire course of the project and raising conflict throughout the course of the project, which ultimately might result in the complete failure of the project.
One of the methods to collect requirements from the stakeholders is the manual method, wherein; you need to use certain tools to manually collect the requirements from the stakeholders. You can use any of the following techniques to collect the detailed requirements from the stakeholders:
Expert interviewing: Also known as interviewing, in this technique, you need to interview the stakeholders to identify their specific requirements for the project. The specificities include the ones for just a project work, product, or even the entire project. Depending on the convenience, you can interview stakeholders either individually or in batches. You can conduct interviews by using various mediums, such as in person, emails, letters, phone calls, or any other convenient medium. Even though this technique might take a lot of time, it gives you an opportunity to understand individual requirements in greater details. Additionally, the technique gives you an opportunity to develop good rapport with the stakeholders of the project.
Brainstorming: In this technique, you gather the stakeholders in a room and start the ideation process. During brainstorming, there is possibility of getting further ideas generated from the ones proposed by a stakeholder. You must facilitate the discussion during the session and keep capturing the ideas generated during the meeting. Make sure that you do not interrupt the process and note down the idea, irrespective of its level of relevance because even such ideas might give rise to another better one in due course of time. Even though there are chances that the meeting might turn into utter chaos if you are not able to manage it properly, this technique has a capability of generating great ideas that might get triggered from another idea.
Nominal group techniques: In this technique, you the participants of the brainstorming session rank the most useful requirements. Depending on the availability of time, you can either merge this session with the brainstorming session itself or conduct an individual session at a later time. Whereas the brainstorming session provides you a huge list of ideas, this technique enables you to create a meaningful set of requirements from the ideas generated during the brainstorming session. It is always advisable to reserve a time period for nominal group techniques immediately after the brainstorming session for two major reasons. First – the ideas are fresh and there are high chances of missing on some of these if the nominal group techniques session is delayed for a later time. Second – it might be difficult to come up with a common time convenient for all stakeholders because of their prior or ongoing commitments.
Focus groups: In this technique, as against the brainstorming session where you invite all stakeholders, you invite only a specific set of stakeholders who are subject matter experts. In this meeting you seek requirements usually on a specific aspect of the project for which the stakeholders have expertise. While you moderate the meeting, the stakeholders can discuss the requirements among themselves. Creating focus groups can help you to understand the requirements for the specific section or feature of the product because the stakeholder invited for the meeting would be having expertise in that area. Additionally, this technique can help you focus your energy and efforts at a feature at a time.
Facilitated workshops: In this technique, you organize workshops where you bring together stakeholders that have different perspective on the project. The stakeholders discuss project requirement from their perspective, which can be from various teams like product designers, developers, end users or any other stakeholder team members.
Even before you start with the project, the first activity that you must perform is to define the scope of the project. Managing the scope is an activity of the project management, which has two aspects – the scope of the project and the scope of the product. Scope management as a whole defines the process of collecting information to start a project and define the features of the product that would meet the stakeholder requirements.
According to the Guide to the Project Management Body of Knowledge guide (PMBOK Guide) published by the Project Management Institute, the scope of the project is defined as the work you need to accomplish to deliver a product, service, or result with specified features and functions. However, the PMBOK guide defines the product scope as the features and functions that characterize a product, service, or result.
The definitions of project scope and product scope distinctly indicate that while project scope is completely work oriented and completely focused on the tasks that you must perform to accomplish the goal; the product scope is more oriented towards the functionality of the product. To simplify the understanding, the project scope is the “How” part of the overall scope management while the product management is the “What” part of the scope management.
Now the big question raises is that why do you need scope management as an individual activity of the project management. Well, the scope forms the backbone of the project and is something that is capable of making or breaking the entire project. It is typical of a project that if you do not finalize the scope of the project and product, you might keep getting request to make changes to the project. This not only adds to the rework in the software product, but also adds to the dissatisfaction and demotivation of the team, especially when changes are too many and very frequent.
For an enterprise software project, the number of stakeholder is very large, which includes management, customers, sales and support teams being some of them. As a result, every team has its own set of requirements and tries to push their requirement as a priority. It is the responsibility of the project manager to manage and finalize the scope, ensuring the all stakeholders are on the same page.
Even though it is assumed that the scope of the project is finalized in the beginning of the project life cycle itself, it is not the situation in the real life. In real life projects, there are high chances that the project requirements might change over a period of time. This could be because of the varied reasons, products from the competition is one of the main reason to push such changes. Politico business requirements also play an important role in requests for changes in scope. Therefore, it is very important for you to plan how to handle any requests in the change in the scope of the project.
To manage the scope of the project, you must perform the following activities before you finalize the scope:
Determine the requirements: To come up with the solution, the first requirement is to understand the problem statement. Therefore, you must make sure that you understand requirements of all the stakeholders, and then map these requirements to the business need of the project as described in the project charter. You must weed out the seemingly and projected to be important requirements depending to the business needs of the project.
Define the scope of the project: After understanding the requirements and mapping the same to the business requirements of the project, you must define the scope of the project. The project must exclusively state the inclusive and exclusive items of the project scope.
Create a work breakdown structure: Work breakdown structure (WBS) is the process of breaking the scope of the project to smallest manageable pieces of tasks.
Verify the scope: You must verify that the work being done is according to the planned scope of the work.
Measure the performance: Make sure that you measure the performance of the project according to the scope of the project at regular intervals. If needed, adjust the scope to accommodate the additional work required.
After the management of the organization has initiated the project, the project is assigned to a project manager. As a project manager when you receive the project, you start with the thorough planning on how the project should be managed and completed. It is rightly said that failure to planning is like planning to failure. The success of the project completely depends on how well you have planned the project. A thoroughly planned project forms the basis of the success of the project. However, a poorly planned project is destined to be doomed.
In a well planned project, you take care of planning each and every aspect of the project, right from the scope of the project to the quality of the deliverables. The plan must consider the viability of the project in terms of the financial aspects. Following is a summary of various aspects around which you must put your efforts when planning a project. Most of these activities flow in a sequential order. Each of the following aspects are covered in details in an individual or a series on articles on these aspects of a project:
Plan the planning:The first thing you must consider when starting the project planning is how you are going to plan for the project. You must consider the areas that the project is going to or would be getting impacted, and plan to handle each of these areas effectively.
Finalize the requirements: Even before you start putting your efforts in a project, you must finalize the requirements. If you do not finalize the requirements right in the beginning of the project, frequent change requests from the stakeholders not only hamper the project progress, but also add a lot of rework and resource wastage.
Scope planning:Scope management is another important aspect of the project. Here, you define the items that are within the scope of the project and the ones that are out of scope for the project. To make the project successful, you must plan to manage the scope of the project to make sure that stakeholders know exactly what is the outcome of the project.
Resource planning:You must identify the resources that you need to complete the project, which includes movable and immovable resources. Additionally, it includes the duration for which the resource is required for the project.
Purchase planning:When creating a purchase plan, you must identify the resources that you can use in-house, the ones you should rent, and the ones for which you need to make an outright purchase from the market.
Work breakdown structure:Work breakdown structure (WBS) is yet another very important aspect of the project planning. In this stage, you break the project into small and atomic individual activities that can be managed efficiently. In a work breakdown structure, you need to identify the smallest units of the work items that can be started and completed as a unit. A work breakdown structure provides a bird’s eye view of the project and helps identifying various dependencies in the project. Work breakdown structure is the key deliverable of the project planning and forms an input for various planning activities.
Team planning:After understanding the project requirements and the work breakdown structure, you must identify the team required to complete the project. This includes the size of the team as well as the expertise you need to complete the project. Depending on the expertise and experience, you need to assign various roles and responsibilities to the team members to get the work done.
Communication planning:You must plan how the team would be communicating within as well as outside the team. It is important to establish a protocol as well as the mode of the communication to avoid any communication issues during the project and even after the project is completed.
Risk mitigation planning:You must identify and define the probable risks associated to the project, however big or small these might be. Mere identification of the risks would be of no use unless and until you plan on how to mitigate the identified risk. Success of the project is also based on how well you have planned to identify and mitigate risks at each and every stage of the project.
Project execution planning:After you have planned the complete project, you must also plan how to execute the plan. You must plan all the nitty gritties of the project. This includes how you are planning to actually implement the plan you have created for the project.
Project kick off:You must get the project plan approved and signed off by the stakeholders to make sure that everyone is on the same page and there is no communication gap. After the project plan is approved, you must hold a project kick off meeting with all stakeholders and present the detailed project plan. A project kick off meeting marks the formal start of the project plan.
Dynamic programming method is yet another constrained optimization method of project selection. In this method, you break a complex problem into a sequence of simpler problems. This method provides a general framework of analyzing many problem types. In this framework, you use various optimization techniques to solve a specific aspect of the problem. This method requires your creativity before you can decide if the problem needs to use dynamic programming for its solution.
This method of project selection is a mathematical technique to make a sequence of correlated decisions. The method consists of systematic procedure to determine the best combination of decisions. In the linear programming method of project selection, you have standard mathematical formula. However, in case of the dynamic programming method of project selection, you do not have any standard mathematical formula.
In the dynamic programming method, you use a general method to solve a problem. You must develop the equations used to solve the problem to the requirement of the problem.
Features of Dynamic Programming Method
The dynamic programming method of projects selection has the following features:
In the dynamic programming method, you structure the problem in multiple stages. You solve each of these stages sequentially, one at a time. Even though you solve one stage at a time, the solution of the problem in one stage defines the characteristics of the problem in the next stage. On a time line of the project planning, you represent each stage at different time frames. However, at times you might realize that some stages do not have any time association. When you formulate a dynamic program for a problem that has such stages, it becomes difficult to recognize the problems.
States
When you define a stage for a problem, you also associate it with a state of the process. The state of a process is the information you need to assess the effect of the decision has on the future action. You do not have to follow any set rules to specify a state. However, it is a critical parameter for dynamic programming method. Specifying a state is more of an art, and requires creativity and deep understanding of the problem.
You must consider the following properties of a state when specifying it:
You should keep the number of state variables to the minimal because of the cost involved in the computation efforts.
You must provide sufficient information to enable future decision without considering process used to reach the state.
Recursive Optimization
After you have structured stages and states associated to the stages, you need to develop a recursive optimization procedure. The recursive optimization procedure builds a solution of up to the n number of stages, with one stage at a time in the specified sequence. The recursive procedure solves each stage until an overall optimum solution is available.
You can base the recursive procedure on any of the following induction processes:
Forward induction process: The recursive procedure starts with the first stage and concludes with the last stage by including each stage sequentially, one stage at a time.
Backward induction process: The recursive procedure starts with the last stage and concludes with the first stage by including each stage sequentially, one stage at a time, in the reverse order.
Mathematical Formula
Consider that you have a multistage decision process where the return of the specific stage is represented by the following function (f):
Here:
dn: is the decision that you can chose form the set Dn.
sn: is the state of the process with n stages remaining in the N number of stages in the procedure.
The next state of the process completely depends on the current state and decision of the process. Therefore, you can define the transition function (t) with n-1 stages to be remaining in the procedure as:
Now that the dynamic programming method consists of a recursive optimization procedure, you can use the following optimal value function, which represents the maximum return possible over the n stages remaining:
Subject to:
The function uses only the decision variable and not the decision variable . Therefore, you can first maximize the latter part of the equation and then chose to maximize the entire equation.
Multi objective programming is another type of constrained optimization method of project selection. In this method, you make decision for multiple problems with mathematical optimization. In case, in a multi objective programming, a single solution cannot optimize each of the problems, then the problems are said to be in conflict and there is a probability of multiple optimal solutions. A solution is called as non dominated if values of none of the problem can be optimized without degrading values of another problem.
There are multiple terms used to define multi objective programming, such as multi objective optimization, vector optimization, multi criteria optimization, multi attribute optimization, or Pareto optimization. This method is an area of making decisions based on multiple criteria. You make decision mainly based on mathematical optimization of problems that requires you to simultaneously optimize more than one objective function. In this method of project selection, you make an optimal decision in presence of a trade off among multiple conflicting objectives. For example, minimizing cost, maintaining quality control, and adhering to deadlines are common multi objective optimization problems you face in most of the projects.
You can use the following methods of multi objective programming methods for selecting a project:
In a no preference method of multi objective programming, you do not require any preference information from the decision maker. One of the most common no preference methods you can use is the method of global criterion. In the global criterion method, you solve the scalar problem in the following form:
Subject to
The global criterion method is sensitive to objective function scaling. Therefore, you must normalize the objectives into a uniform and dimensionless scale.
A Priori Methods
In contrast to the no preference methods, in the a priori methods, you need to specify sufficient preference before the solution process. The most common a priori methods that you can use include utility function method, and lexicographic method.
For example, in a utility function method, you assume that the utility function is available. A utility function, such as a mapping u: Y→R, specifies an ordering of the decision vectors. After you have got the value for u, you solve the problem in the following form:
Subject to
Similarly, in a lexicographic method, you assume that you can rank objectives by the importance. Therefore, you assume that objective functions are ranked by importance such that f1 is most important and fk is least important. In the lexicographic method, you solve a sequence of single objective optimization problems in the following form:
Here, yj is the optimal value of the problem with n = m.
A Posteriori Methods
In the a posteriori methods, your goal is to prepare all the Pareto optimal solutions or subset of the Pareto optimal solutions. You can categories most of the a posteriori methods into the following classes:
Mathematical programming based a posteriori methods: In these methods, you repeat the algorithm and with each run of the algorithm, you produce a Pareto optimal solution. Examples of this class include Normal Boundary Intersection (NBI), Modified Normal Boundary Intersection (NBIm), Normal Constraint (NC), Successive Pareto Optimization (SPO), and Direct Search Domain (DSD).
Evolutional algorithms: In these methods, you produce a set of Pareto optimal solutions when you run the algorithm. Examples of this class include Non dominated Sorting Genetic Algorithm II (NSGA II) and Strength Pareto Evolutionary Algorithm 2 (SPEA 2).
Interactive Methods
In the interactive methods, you work on an interactive solution process and keep interacting with it when searching for a most favorable solution. In these methods, the process expects you to provide you preferences for each iteration of the process to get Pareto optimal solutions.
The following is a common algorithm of the procedure followed in the interactive methods:
Start the process with initial values.
Fix a starting point for the Pareto optimal solution.
Provide your preferences.
Generate a Pareto optimal solution.
Select the best solution so far, if multiple solutions are generated.
If it is an optimal solution, then stop. Else, repeat step 3 through step 6.
Hybrid Methods
In the hybrid methods, the algorithm consists of a combination of algorithms from multi criteria decision making (MCDM) and evolutionary multi objective optimization (EMO). The hybrid methods are used to overcome the shortcomings and utilizing the strengths of these methods.
Multi Objective Programming Software
Multi objective programming involves complex mathematical computations. Therefore, either you need help from an expert or use any of the multi objective programming software available in the market for this purpose. The following is a list of some of the software available in the market:
Integer programming is a yet another type of constrained optimization method of project selection. In this method, you look towards a decision that works on integer values and not on fractional values. For example, producing a number of cars can never be fractional.
In contrast to the linear programming method, where you work on a continuous model that enables you to define decision variables to be fractional, in the integer programming model, you must consider only integer values for the decision variables. For example, when you can produce 189.86 tones of sugar in a plant, you cannot produce 23.6 airplanes. While you can use linear programming method to select a project in the former case, you must use the linear programming method to select a project in the latter case because fractional solution is not at all realistic for it.
In the integer programming method, you optimize a solution by using the following formula:
Subject to:
You define an integer programming method as mixed integer program when you restrict only some of the decision variables as integers. However, when you make sure that the value of all the decision variables must be integers, then it is a pure integer program.
As in case of the linear programming method, where if the decision constraints are of a network type, you can get an integer solution by ignoring integrality restriction. However, in general the decision variables are fractional. For such a solution to be an integer solution, you must consider further steps to arrive at a solution.
Formulation of an Integer Program
The integer programming method has extensive programming capabilities that are better than the linear programming capabilities. The integrality restriction of this method reflects the natural sense of non possibility of dividing a problem. For example, when you decide to add a room to a building, it does not make any sense to have a fractional solution. In such problems, you must consider a solution that is integral in nature.
When formulating an integer program, you must consider the following components:
At times, you might have just two values for making a decision, which are Yes and No. In such cases, the variables in the program are restricted to only two values – 0 or 1. The variables for which you restrict values to 0 or 1 are known as binary, logical, bivalent, or 0 – 1 variables. In formulating an integer program, you use such variables quite frequently.
To formulate a problem solution using a binary variable in an integer program, you use the following formula:
Logical Constraints
When you use decision variables in an integer program, you impose logical constraints. You can consider the following constraints at the time of formulating a solution by using an integer program:
Constraint feasibility: For a decision variable, you ask a question whether the choice available for the decision variable satisfies the constraint. If the constraint is satisfied, you assign value 0 to the variable and 1 if it does not.
Alternative constraints: For a decision variable, you might have more than one constraint. The decision variable must satisfy at least one constraint and not both.
Conditional constraints: In contrast to the alternative constraints, you might have multiple constraints, the decision variable must satisfy both the constraints.
Compound alternatives: Compound alternatives include sets of alternative constraints. These sets of constraints can lie in disjointed regions when plotted on a graph or can be on overlapping regions.
Subject to:
Subject to 
Subject to 
