Month: February 2017

Defining the Scope of a project

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:

  • The scope of the project
  • The deliverables of the project
  • Acceptance criteria of the product
  • What is not included in the project
  • Additional risks identified
  • Constraints and assumptions for the project

Collating Stakeholder Requirements and Finalizing the Project Requirements

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:

Conduct Group Decision Making Session

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.

Using Software Utilities to Collect Project Requirements

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.

Collecting Project Requirements as a Group before finalising the scope

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.

Project Scope management – an overview

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.

Planning a Project – An Overview

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.
Pages: Page 1, Page 2
Share
Share