| Version | Date | Change Information | Author | Approver |

| ------- | ---- | ------------------ | ------ | -------- |

| V1.0 | Feb 24, 2026 | Initial Draft | Melisha Dsouza | Pooja Thorat |

Before commencing any project, the first activity an organization needs to perform is project planning. Any experienced project manager understands the significance of a well-structured plan. A carefully prepared project plan considers all critical aspects such as requirement understanding, timelines, resource availability, and risk analysis.

This ensures that the project team has a clear roadmap to follow during execution. The plan serves as both a guidance document and a reference point throughout the project lifecycle, helping to manage scope, allocate resources efficiently, and minimize risks.

The objective of project planning is to draw a blueprint for the project. The careful and detailed planning helps us to reduce risk and, in turn, uncertainty in any given project. In a meticulously planned project, the project planner attempts to make a provision for potential occurrences of uncertainties in advance. Project planning enables project managers to translate project requirements into a Work Breakdown Structure (WBS), task list, Gantt charts, resource assignment, and risk register, etc.

Scope involves getting the information required to start a project, and the features the product would have that would meet its stakeholders’ requirements. It is important to define a clear project scope at the beginning of the project to avoid scope creep.

In the planning, the scope is defined in two distinct ways,

1. **Project Scope:** "The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions”.The project scope is more work-oriented (the hows). Below are some general aspects of the Project scope that can be defined in the plan according to project needs.

* Detailed Planning, which will include,

* Time Bond

* Deliverables

* Resource Planning

* Budget Planning

* Task Planning

* Design Documents

2. **Product Scope:** "The features and functions that characterise a product, service, or result."Product Scope is more oriented toward functional requirements (the whats). Below are some general aspects of the Product scope that can be defined in the plan according to product and customer needs.

* Achievement of the requirements defined in the Approved SRS

* Quality of the product in terms of,

* Performance

* Ease of use

* Size

* Looks and features

* Durability

* Functioning

* Quantity of the product

* Technologies Being Used

Enovate IT Outsourcing is committed to establishing reasonable plans for managing software projects to deliver high-quality products and services. The purpose of the Project Planning policy is to ensure that Enovate IT Outsourcing consistently develops and documents: estimates for work to be performed; necessary, agreed-upon commitments from affected groups and individuals; and a plan to perform the work.

For each qualifying project, the Project Manager establishes, according to a documented procedure and in cooperation with other members of Enovate IT Outsourcing, a Project Plan document. Other impacted members of the Leadership Team within the department review and approve the subsequent Project Plan, and the Enovate IT Outsourcing director reviews the external (to the department) commitments. In addition, any external group affected by the size, effort, or cost estimates, schedule, or other commitments of the project will be asked to review that section of the Plan.

The Project Plan covers several areas, including estimates of the software project’s effort and cost, the size of the software work product, critical computer resources, schedule with milestones and reviews, and an assessment of the software project’s risks. The Project Plan is maintained and controlled as a living document that reflects the current state of a project’s status.

Enovate It outsourcing management provides resources to the Project Manager(s) for creating the Project Plan document and conducting regular reviews of progress, as well as providing the necessary support to establish and maintain the project planning efforts.

A work product may begin as an analysis made during the development of a project, creating a type of proposal for the project that a company cannot deliver until the project has received approval. Companies use work products to provide information to current stakeholders and potential investors. Types of information available in a work product might include prototypes, presentations, recorded discussions, diagrams, and status reports. The organisation can also use the work product as a source of information while the project progresses.

* **Project Plan**: A documented Plan

* **Task list and Plan**: A Task list is a list of tasks and plans that will include resources, timelines, priorities, and estimations, which will be maintained in the Jira tool.

| Process Elements | File Name or Reference |

| ---------------- | ----------------------------- |

| Documents | Procedure Document |

| Documents | Project Charter |

| Checklist | Project Kickoff Checklist |

| Checklist | Project Plan Checklist |

| Plan | Project Plan |

| Plan | Release Plan |

| Plan | Test Plan |

Gitlab Address for Documents:

| Record | Where to get? |

| ------------------------------------------------------- | -------------------------------------- |

| Procedure Document | Process Area_PLAN |

| Project Charter | Process Area_PLAN |

| Skills Matrix | Process Area_PLAN |

| Project Kickoff Checklist | Process Area_PLAN |

| Project Plan Checklist | Process Area_PQA |

| Project Plan | Process Area_PLAN |

| Release Plans | Process Area_PLAN |

| Test Plans | Process Area_PLAN |

| Task List and Plan | Jira tool |

| Estimated Vs Actual | Process Area_EST |

| Work Products Checklist | Process Area_PQA |

| Defined Scope | Project Plan Dcument_Process Area_PLAN |

| Stakeholder Analysis Matrix according to process areas | Process Area_PLAN |

| Configuration Management Plan | Process Area_CM |

| Audit Plans and Reports | Process Area_PQA |

| Roles | Responsibilities |

| ---------------------------------- | ---------------- |

| Project Owner | Conducts an Initial meeting<br>Prepares Quotations and agreements for the project. |

| Business Analyst / Project Coordinator | Prepare Project Charter<br>Communicates and resolves any customer-related issues.<br>Record MOM<br>Help PM make the Project Plan<br>Prepare Release Plan<br>Review Test Plan<br>Ensure the successful delivery of the project |

| Quality Analyst | Prepare test Plan |

| Team Leader | Understand the Project Plan<br>Prepare task list<br>Allocate task list to Resources<br>Update estimated hours and dates in task allocation, and make sure it will fill the project plan’s needs<br>To help the developer with critical technical issues<br>To ensure delivery on given timelines according to release plans<br>Record MOM<br>Keep the PM informed of any changes required in the plan and any issues encountered by the team members. |

| Project Manager | Prepare resource plan (Comes under detailed project plan)<br>Design Document review (HLD, LLD, design doc, etc.)<br>Communicates and resolves the issue escalated by the project team.<br>Monitors the project progress and keeps the PC/BA/customer informed.<br>Periodically seeks customer feedback<br>Record MOM |

| Developer | Understand the Project plan and project needs |

| Process Quality Assurance Manager | Prepare Audit Plan<br>Maintain Audit reports<br>Assure the quality of the process |

| Configuration Manager | Prepare a CM plan |

| PQA | Prepare Audit Plan |

- The project Owner, along with the senior management, forms the Project Initiation Group (PIG). Roles and Responsibilities of the project are assigned to the PIG.

- The project manager should prepare a detailed project plan which should cover,

* Resource Plan

* Project Delivery Plan

* Task Plan

* Data Management Plan

* Training/KT Plan

* Project Test Plan

* Adopted project Life cycle or approach

* Communication Plan

* Transition Plan

* Documentation Delivery Plan

* Review Plan

* Change in requirements and new requirements management Plan

* Issue Management Plan

* Risk Management Plan

* Process Tailoring Plan

* Close-Out Plan

- A Business Analyst should prepare a **project charter** and **release plans** based on the project delivery plan.

- **Configuration Manager** should prepare the **CM plan** and share it with the required stakeholders.

- A **Quality Analyst** should prepare a test plan based on the project and release plans

- **Process Quality Assurance** should prepare **audit plans** to ensure the process and share them with the required stakeholders.

- The Project Manager should **identify** or **define the software development lifecycle**

- The **manager** should derive **estimation plans**.

1. **Iterative Project Life of Enovate/Agile Life Cycle**

3. Software Prototyping Model

Software prototyping activity of creating prototypes of software applications that are incomplete versions of a software program being developed.

The prototype model is generally used when the requirements are unclear. It is used when the customer is unclear about the details of the input, process and output needs of the software.

- **Requirement gathering:** Understanding the very basic product requirements, especially in terms of the user interface.

- Quick design: After requirement gathering, a quick design is made that is work on the flow diagram, languages, etc.

- **Building prototype:** These basic requirements are showcased and user interfaces are provided. This prototype gives some look and feels to the customer in what will be an exact product.

- **Evaluate / review of the prototype:** The Prototype developed is then presented to the customer and the other stakeholder in the project. Feedback is collected and used for further enhancements.

- **Refine prototype:** Feedback and comment are discussed and some negotiations happen with a customer based on time and budget constraints. The changes accepted again incorporated in the new prototype. This cycle repeats until customer expectations are met.

- **Product**: After repeating the above steps, finally, the product is developed, meeting user expectations.

- It is usually built using several "shortcuts". The shortcuts might involve using inefficient, inaccurate, or dummy functions.

- **Example**: In a process, we can show a table-look-up instead of showing actual computation.

- In this prototyping, quick iterations are planned and quick modeling occurs.

- The prototype is implemented and then accessed by customers or users for their feedback to refine requirements for the software.

- That prototyping is turned and iterated until customer satisfaction.

5. Software Prototyping Model

The spiral model is another iterative software development life cycle which is greatly used for high level and long term project as well as high-level risk analysis.

To use this model an experienced and skilled team required



- This model improves the avoidance of risk

- This model is very useful for choosing a methodology for a software iteration

- This model can associate other methodologies like Waterfall, Prototyping, and Incremental methodologies. Suppose a project having a low risk of not meeting the user requirements and on the other side having high risk of missing budget would follow waterfall approach

- In this model more functionality can be added in later versions.

- Estimates (i.e. Budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier.

- Software engineers can get their hands in and start working on a project earlier.

- Prototyping is used as a risk reduction mechanism

- After the final iteration, all risks are resolved and the “requirements” are ready for development.

- Costs and risk revolution is important

- From Medium to High Risk Projects

- Users are unsure of their needs

- Requirements are complex

- Significant Changes are expected

Non-Iterative Life Cycle

A waterfall life cycle is a linear, sequential flow. In which progress is seen as flowing steadily downwards (like a waterfall) through the phases of software implementation. This means that any phase in the development process begins only if the previous phase is complete. The waterfall approach does not define the process to go back to the previous phase to handle changes in requirements.

Due to the nature of the waterfall model, it is hard to get back to the previous phase once completed. Although this can be very rigid in some software projects that need some flexibility, this model can be essential or the most suitable model for other software projects’ contexts.

The usage of the waterfall model can fall under the projects that do not focus on changing the requirements, for example:

- Projects initiated from a request for proposal (RFP), the customer has very clear documented requirements

- Mission Critical projects, for example, in a Space shuttle

- Embedded systems.


Model is mostly known as the validation and verification software development. Although it is considered as an improvement to the waterfall model and it has some similarities as the process also based on sequential steps moving down in a linear way, it differs from the waterfall model as the steps move upwards after the coding phase to form the typical V shape. This V shape demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

This means that any phase in the development process begins only if the previous phase is complete and has a corresponding related testing phase, which is performed against this phase's completion. Similar to the Waterfall model, the V-Model does not define the process to go back to the previous phase to handle changes in requirements.

The technical aspect of the project cycle is considered as a V shape starting with the business needs on the upper left and ending with the user acceptance testing on the upper right.

The V-Model contains the main phases similar to other process models. You can read this article for more information about SDLC phases definitions.

Moreover, it breaks down the testing phase into detailed steps to ensure the validation and verification process. So, it contains the following testing phases:

**Unit Testing** Unit testing is the testing at the code level and helps eliminate issues at an early stage, mainly the developer is responsible to perform the unit test for his code while not all the defects cannot be discovered at the unit testing.

**Functional Testing** Functional testing is associated with the low-level design phase which ensures that collections of codes and units are working together probably to execute new function or service.

**Integration Testing** Integration testing is associated with the high-level design phase. Integration testing ensures the integration between all system modules after adding any new functions or updates.

**System Testing** System testing is associated with the system requirements and design phase. It combines the software, hardware, and the integration of this system with the other external systems.

**User Acceptance Testing** User Acceptance testing is associated with the business and operations analysis phase. The customer users are the main performers of this testing based on test cases and scenarios that cover the business requirements to ensure that they have delivered the right software as per the specifications.

Due to the nature of the V-Model, it is hard to go back to the previous phase once completed. Although, this is can be very rigid in some software projects which need some flexibility, while, this model can be essential or the most suitable model to other software projects’ contexts and which focus on quality as an important aspect of the delivery.

The usage of V-Model can fall under the projects which did not focus on changing the requirements, for example:

1. Projects initiated from a request for proposals (RFPs), the customer has a very clear documented requirements

2. Military projects

3. Mission Critical projects, for example, in a Space shuttle

4. Embedded systems.

5. Projects with defined and clear requirements

Measurements standards is used to determine an accuracy as well as to see chain or graph of the process. In measurement of a set, accuracy refers to the closeness of the measurements to a specific value. In the PLAN process area below measurement will be counted,

1) Deliverables/Release Plans

* Note down deliverables/Releases plan are delivered on planned date or not

- Periodic reviews of the process and work will be done by BA and Manager.

- All managerial tasks and required information will be maintained in jira.

- This provides awareness of and insight into software process activities at an appropriate level of abstraction and in a timely manner. The time between the reviews should meet the needs of the organization.

- Assigned Stakeholders

| Acronym/Term | Description/ Definition |

| ------------ | --------------------------------- |

| RTM | Requirement Traceability Matrix |

| PM | Project Manager |

| PL | Project Leader |

| PC | Project Coordinator |

| BA | Business analyst |

| CM | Configuration Management |

| HRM | Human Resource Management |

| TC | Test Cases |

| RSH | Related Stakeholders |

| SPO