# **Estimating (EST)** _(Approval of the estimating indicates an understanding of the purpose and content described in this deliverable. By signing this deliverable, each individual agrees on the proposed subsystems' roles and business logic it is responsible for; Test Planning and Detailed design work should be initiated on this project, and necessary resources should be committed as described in the charter document.)_ **Document Revision History** | Version | Date | Change Information | Author | Approver | | ------- | ---- | ------------------ | ------ | -------- | | V1.0 | Feb 24, 2026 | Initial Draft | Melisha Dsouza | Pooja Thorat | ### **1. Introduction** Estimating is the process of finding an approximation of the project based on its requirements, scope, and key factors such as time, resources, and budget. It is an essential part of the project that helps, - To justify the project, particularly at the proposal stage, enabling the costs to be compared with the anticipated benefits, and to enable informed comparisons to be made between different technical or functional options. - To enforce the disciplines needed to make the project succeed. - To secure the resources required to deliver the project successfully. - To ensure that the support impact of the project is fully understood. - To inform and improve our software development process The estimating method is helpful to achieve accuracy and find out the measurements in terms of, - **Point Estimate**: When the estimated values are very close to the actual values. - **Overestimate**: When the estimated values are significantly higher than the actual values. - **Underestimate**: When the estimated values are significantly lower than the actual values. ### **2. Policies** - To estimate, one should have a clear set of client requirements with respect to, * Product * Technologies * Resources * Budget - An organization should have the approval of the client on the estimated hours and dates to start the project ### **3. Work Product** 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 organization can also use the work product as a source of information while the project progresses. **Work product for the EST area is,** - Estimated Plan and Client Approval ### **4. Estimation Guideline** The best people to undertake estimation are the staff who are going to do the work. The staff chosen to produce an estimate are typically drawn from customers and/or service partners who have relevant experience of similar previous projects or tasks in the business area. **Our estimation process is based on three components:** - **Expert judgment**: Consultation with qualified experts from within our business and service partners. This is supplemented, where required, by expert input from software suppliers and consultants. - **Experience**: Comparison of the proposed project or task with previously completed work. - **Task Decomposition**: Decomposing the project into components, i.e., a Work Breakdown Structure, and estimating each component individually to produce an overall estimate. The estimates are validated through peer review and are backed up by an experienced Project Manager who takes overall responsibility for the total. Estimates are reviewed and updated throughout the project lifecycle. Estimates and the processes followed to produce them are transparent and consistent across all projects. **The important factors should be considered during estimation,** - **Scope**: The scope has a detailed description and requirements of the project, so the scope is an important part when it comes to estimating the project. The scope of the project decides on what basis one is going to estimate. - **Technology**: One should consider the request for technology to be used for the project. Estimates can vary according to technologies and the skills of the resource for that particular technology. - **Complexity**: The complexity of the tasks or modules can vary from person to person; the expert may find it less complex, and the fresher may find it more complex. Both scenarios should be considered. - **Reusability**: The reusability of the work can help to save time. - **Skills of a resource**: The expert judgment of estimation can vary when compared to the resource estimation of those who are actually going to work on that task. - **Work Breakdown Structure**: The work breakdown structure can help to get an accurate estimation of the project as a resource, considering every small part of the project during estimation. ### **5. Estimation Methods** There are various types of estimation; the standard two types of estimation will be followed at Enovate IT outsourcing. - **Ballpark Estimation or Quick Review and Rough Estimation**: The Ballpark Estimation is an acceptable, roughly accurate approximation by an expert. It is never the actual figure, but it is somewhere around the actual estimation. **When to use the Ballpark Estimation method?** * When the client just wants a rough estimation, not an actual * When requirements have vague information * When you think you may not get the project, as if the client is just looking for ballpark numbers * When you have to save time in the estimation process - **WBS (Work Breakdown Structure) Estimation**: Work Breakdown Structure estimation gives an actual number of the estimation as every task is divided into small chunks to estimate by considering all scenarios. **When to use the WBS Estimation method?** * When the client is looking for an actual figure * When you are sure you will get the project * When requirements are very clear ### **6. Estimation Valuation** Estimation valuation is determining the fair price of the product, or here at Enovate, as work is mostly based on hours, so it involves determining the fair estimation of the work. #### **6.1. Ratio** The ratio will be calculated in two ways at the project level and at the expertise level with respect to, - Hours - Timelines **1. Project Level** - **With Respect to Hours:** * A project owner should calculate the buffer estimation as a % for the project. * **For Example:** A project is estimated to be 1000 hours, and 2% buffer means that any variation above or below the actual hours will not create any loss. If we compare the estimated to the actual during periodic reviews as below, | Cases | Estimated Hours | Up or Below (2%) | Actual | UP(+) in % | Below(-) in % | Buffer (2%) | Measurements | | ------ | --------------- | ---------------- | ------ | ---------- | ------------- | ----------- | ---------------- | | Case 1 | 1000 | 20 | 1030 | 3% | 0 | 1% | Underestimate | | Case 2 | 1000 | 20 | 1000 | 0 | 0 | 0 | Point Estimate | | Case 3 | 1000 | 20 | 998 | 0 | 0.2 | -2.2% | Overestimate | **Case 1:** ``` Estimated Hours = 1000 Actual Hours = 1030 Difference(Actual- Estimated)=30 Loss(%) =(Difference/Estimated)*100 =(30/1000)*100 =(0.03)*100 =3% Actual Loss = (Loss-Buffer) = (3-2) = 1% If the Actual Loss is >=1, then the measurement of estimated hours is “Underestimated” ``` **Case 2:** ``` Estimated Hours = 1000 Actual Hours = 1000 Difference(Actual- Estimated)=0 Loss(%) =(Difference/Estimated)*100 =(0/1000)*100 =(0)*100 =0% Actual Loss = (Loss-Buffer) = (0-2) = -2% If the Actual Loss is <=0, then the measurement of estimated hours is “Point Estimated” ``` **Case 3: ** ``` Estimated Hours = 1000 Actual Hours = 998 Difference(Actual- Estimated)=-2 Loss(%) =(Difference/Estimated)*100 =(-2/1000)*100 =(-0.02)*100 =-0.2% Actual Loss = (Loss-Buffer) = (-0.2-2) = -2.2% If the Actual Loss is <=-1, then the measurement of estimated hours is “Overestimated” ``` - **With Respect to Timelines** A project manager or estimation expert should decide a buffer timeline for the project in terms of days. Then the Measurements will be, * **Point Timeline** If Actual Delivery/Release Date = Estimated Delivery Date * **Under Time** If Actual Delivery/Release Date < Estimated Delivery Date * **Over Time**, If Actual Delivery/Release Date > Estimated Delivery Date **2. Expertise Level** - The ratio of expertise’s hours is a well-analyzed judgment for the person or team who estimates the hours/ cost of the project. It gives an idea about the accuracy when we compare the estimated cost to the actual cost. Also, it gives an idea about experts’ accuracy on estimation, which helps to find out whether the project is point estimated, overestimated, or underestimated. - In the organization, we get the estimation from the people who are going to work, but those estimations may not be acceptable to the client so a specific person or a team should be considered responsible to estimate for the project and all the coming modules in the project. - The PQA team should decide the estimation valuation of expertise based on previous project experience. For example, an expert estimation can be so accurate, or it can be underestimated or overestimated, so a coordinator should calculate a final estimation by considering the valuation of the work before sharing it with the client. - Based on the project level ratio, we can make conclusions about expertise hours and timelines in terms of, * Point Estimated * Overestimated * Underestimated * Point Timeline * Under Timeline * Over Timeline ### **7. Enovate’s Estimation Structure** The Enovate’s Estimation structure is as follows, `Total Hours: Development hours + Testing hours + Managerial hours.` **Total Hours** - **Development Hours i.e** * Development * Understanding the requirement - **Testing Hours = 0.30*Dev Hours** * Unit Test Cases and Testing (done by Developer) * Functional Test Cases and Testing (done by QA) - **Managerial Hours = 0.25*Dev Hours** * Documentation * Stakeholder Communication * Reviews - **Deployment** - **Project Base setup** Example as below, | Module/Task | Total | Managerial | Testing | Dev | | --------------------- | ----- | ---------- | ------- | --- | | Project Base Setup | 10 | 0 | 0 | 10 | | Login | 3.1 | 0.5 | 0.6 | 2 | | Update profile | 4.65 | 0.75 | 0.9 | 3 | | Upload profile photo | 3.1 | 0.5 | 0.6 | 2 | | Logout | 2.325 | 0.375 | 0.45 | 1.5 | | Deployment | 2 | 0 | 0 | 2 | | Total | 25.175 | | | | _**Note**: It’s the generic and basic structure; it can vary according to project needs_ ### **8. Factors Affecting Estimation Approach** In the organization, estimations and costs can vary from a generic structure according to different scenarios and working approaches. Below are possible situations for which estimations, costs, and timelines can be different from the generic estimation structure. - Estimates by an Expert, but work from a Junior Developer - Ready Product - Work With Outsources In such cases, the project owner will be responsible for deciding the cost of the work. Funding structure will be maintained in, * **For Client**- In the Project Charter * **For Outsources**- In the Outsource Agreement ### **9. Sharing Estimation / Cost with the Seller** When it comes to sharing an estimation with the client, - Use official emails - Never share the overall estimation structure, which includes managerial, testing, and dev hours. Just Share Module/Task and its total hours. If required, one can add justification for the hours - Use a very simple format to share the estimation, which will not create confusion. - Use pdf attachments to share the estimation. ### **10. Records of Estimating** | Record | Where to get? | | ----------------------------- | -------------------------- | | Estimated Hours Sheet | Process Area_Estimating | | Actual Hours | Jira | | Estimated Vs Actual | Process Area_Estimating | | The ratio | Process Area_Estimating | | Measurements | Process Area_MPM | | Project Charter | Process Area_PLAN | | Outsource Agreement Template | Process Area_ | | Estimating Checklist | Process Area_Estimating | | Estimating Audit Checklist | Process Area_PQA | ### **11. Roles and Responsibilities** | Roles | Responsibilities | | ----------------------------------- | ---------------- | | Project Owner | Decides the valuation (cost) of the project<br>Decides the Funding structure for the client as well as for outsourcing | | Project Manager | The Project Manager is responsible for giving development hours for the project<br>Responsible for giving estimated timelines of the project | | Project Coordinator/ Business Analyst | Responsible for making the final hours sheet by using Enovate’s estimation structure<br>Responsible for sharing the estimation with the client<br>Responsible for keeping evidence of approved estimation | | PQA | PQA is responsible for periodic audits to make sure the process is aligned<br>In every audit, PQA will check the Project and expertise ratio | ### **12. Process Flow and Description** #### **Initial Phase** - Once we receive the final set of requirements, the project manager will provide development hours to the project coordinator or BA with module names - BA will create a final set of hours by following Enovate’s estimation structure and will confirm with the project manager - Then BA will provide total hours to the project owner for the information and will share with the client for approval with the project manager and owner in CC - The BA should be very specific about the hours information that a client should not assume a future change in requirement in the initial phase of hours #### **Change in the Requirement hours management** - Whenever there is a change in requirement, BA should share the estimation with the client before starting the work, as described in the RDM area about changes in requirements. #### **When the project is in Progress** - Let’s assume the project is in progress. - Whenever the project manager or coordinator creates a task, they must add estimated hours as well as estimated timelines for the project - Respective resources should report actual working hours time to time, as well as estimated timelines - BA or PC should review estimated hours and timelines during every release and should inform the manager if it is exceeding - PQA should make sure the process is aligned during every audit ### **13. Skills Required** | Roles | Required Skills | | ---------------------------------- | --------------- | | Project Owner | Math Skills<br>Critical thinking | | Project Manager | Math Skills<br>Critical thinking<br>Data Analysis<br>Good Organizing skills<br>Detail Orientation skills<br>Effective Communication<br>Technical Skills<br>Time Management | | Project Coordinator/ Business Analyst | Math Skills<br>Writing Skills<br>Excel | | PQA | Auditing Skills<br>CMMI Knowledge<br>Report Analysis | ### **14. Verification and Validation** - Periodic reviews to check that the project is on track according to the estimated timelines - Periodic audits will be conducted to check the process - In every audit, PQA will calculate the project ratio and the expertise ratio - Every three months, the project coordinator will provide an estimated vs. actual hours report to higher management for every project. (This is an org-level task, not specific to just a single project ### **15. Measurements** Measurements for Estimating area are, 1. **Project ratio** with respect to, - **Hours** * **Point Estimated** * **Overestimated** * If Overestimation = 10% = Low Intensity * If Overestimation > 10% & = 20% = Medium Intensity * If Overestimation >20% & = 35% = High Intensity * If Overestimation > 35% = Very High Intensity * **Under Estimated** * If Underestimation = 10% = Low Intensity * If Underestimation > 10% & = 20% = Medium Intensity * If Underestimation >20% & = 35% = High Intensity * If Underestimation > 35% = Very High Intensity - **Timelines** * **Point Timeline** * **Over Timeline** * If Over Timeline = 3 Days = Low Intensity * If Over Timeline >3 & = 7 Days = Medium Intensity * If Over Timeline >7 & = 10 Days = High Intensity * If Over Timeline > 10 Days = Very High Intensity * **Under Timeline** * If Under Timeline = 3 Days = Low Intensity * If Under Timeline >3 & = 7 Days = Medium Intensity * If Under Timeline >7 & = 10 Days = High Intensity * If Under Timeline > 10 Days = Very High Intensity 2. **Expertise ratio** with respect to, - **Hours** * **Point Estimated** * **Overestimated** * If Overestimation = 10% = Low Intensity * If Overestimation > 10% & = 20% = Medium Intensity * If Overestimation >20% & = 35% = High Intensity * If Overestimation > 35% = Very High Intensity * **Under Estimated** * If Underestimation = 10% = Low Intensity * If Underestimation > 10% & = 20% = Medium Intensity * If Underestimation >20% & = 35% = High Intensity * If Underestimation > 35% = Very High Intensity - **Timelines** * **Point Timeline** * **Over Timeline** * If Over Timeline = 3 Days = Low Intensity * If Over Timeline >3 & = 7 Days = Medium Intensity * If Over Timeline >7 & = 10 Days = High Intensity * If Over Timeline > 10 Days = Very High Intensity * **Under Timeline** * If Under Timeline = 3 Days = Low Intensity * If Under Timeline >3 & = 7 Days = Medium Intensity * If Under Timeline >7 & = 10 Days = High Intensity * If Under Timeline > 10 Days = Very High Intensity ### **16. Entry and Exit Criteria** - **Entry Criteria** * Approved Estimation from Client - **Exit Criteria** * Product Delivery as per estimated hours and timelines * Audit Reports ### **17. Procedure Tailor According to the Project** Click the link → Copy the document → Move it to your project folder → Update as needed. Do not edit the original file. 🔗 [Document Link](https://docs.google.com/document/d/1-W8mpOYO7--E0k2xnuG5Pmw9o7mAKI8a/edit?usp=sharing&ouid=116180547719541291059&rtpof=true&sd=true)