Unit 4
Project Planning, Management and Estimation
The implementation of the project is the first step of the life cycle of project management and businesses determine at this point if the project is needed and how useful it will be for them. The business case and feasibility analysis are the two metrics that are used to assess a planned project and determine its expectations.
Project initiation process:
Now that we have decided what the initiation of the project is and why it is so important, it is time to see what the key steps in the checklist for the initiation of the project are and how successful managers initiate their projects.
Fig 1: project initiation
- Creating a business case
The business case is an essential document which describes how the objectives of the project fit with the long-term goals of the organization. This report examines why the organization should invest its technological, financial and human capital on a particular project.
2. Conducting a feasibility study
The next step after the acceptance of the business case is to assess the probability of the success of the project after considering all the variables. This research describes the project's high-level limitations and assumptions and determines whether or not the project is worth it.
3. Establishing a project charter
Perhaps the most detailed and critical aspect of the process of project initiation is the project charter. To define the scope/goal, team members, and the potential timeline of the project, it responds to the 3 Ws.
In several cases, the charter is the first project document that outlines the necessary specifics, such as the project's objectives and constraints.
4. Identifying stakeholders and making a stakeholder register
Communication and discussions are an important aspect of successful project management and a significant part of the time spent by a project manager is typically spent communicating with stakeholders. PMBOK describes stakeholders as anybody who can be impacted or have an impact on the project. Project stakeholders can be internal or external and each category has its own communication requirements.
5. Assembling the team and establishing a project office
Without a project team, no project can be initiated. Forming a working project team and assigning tasks and duties to them is an integral part of the initiation process of the project. It also increases the overall responsibility of the whole team by assigning tasks and responsibilities early on and can assist you as a manager in the later stages of the project life cycle.
6. Final review
It is a good idea to revisit the entire project initiation process after doing all to ensure that you missed nothing. You will have to check the work in later stages, as monitoring and control is one of the five phases of the life cycle of project management.
Key takeaways
- The implementation of the project is the first step of the life cycle of project management
- The business case and feasibility analysis are the two metrics that are used to assess a planned project and determine its expectations.
The process of developing a scope management plan that records how the scope of the project will be defined, validated, and managed is Plan Scope Management. The main advantage of this approach is that it offers guidance and direction on how to handle the scope throughout the project.
This is the process of developing a strategy for scope management that records how to identify, verify and monitor the scope of the project.
Scope management plan planning is close to project management plan planning. Before defining a performance for this phase, we have to start with a statement of work, WBS and other specifications.
Fig 2: plan scope management
- Input: It offers an overview of the deliverables and approval requirements for a project as an input to the "Plan Scope Management" process.
2. Expert judgment: This resource is an article explaining the judgments of experts and how they are used to help project managers establish a strategy for scope management.
3. Output: The tools for creating a scope management plan, scope declaration, WBS, and how they are managed and recorded are defined.
Key takeaways
- The main advantage of this approach is that it offers guidance and direction on how to handle the scope throughout the project.
- Scope management plan planning is close to project management plan planning.
A common project management tool is a job breakdown structure. It is a diagram that helps to break down big projects into smaller and more manageable components that include the deliverables or results of the project that will be completed.
It is a project-oriented breakdown of deliverables that separates project deliverables into sub-deliverables and work packages that describe the work, length and expense of the tasks to be performed.
It has a structure that is hierarchical. Typically, having three stages of decomposition in a WBS is easier. You can add a fourth and a fifth level in the case of a more complicated project.
Fig 3: work break down structure (example)
We have then mentioned the steps you need to take to build a scratch-based job breakdown structure.
Step 1: To define the project's deliverables and sub-deliverables, get the team together. This will include the project managers and the professionals in the subject matter.
Step 2: Collect the necessary documents, such as the project charter, the declaration of project scope and the strategy for project scope management.
Step 3: Identify the project's main deliverables. These should come at your WBS's second level. To complete the project, key deliverables will be necessary and will be carried out by separate teams, meaning the same team will not work on completing another deliverable.
Step 4: Split the main deliverables into smaller sections of the work (work packages) or, in other words, define the work that is required to complete each deliverable with the aid of the subject matter experts.
Step 5: Build a WBS dictionary that includes the description and scope of the various elements in your job breakdown structure as a text. The WBS dictionary contains details such as the name and ID of the job package, the name of the person to whom it is assigned, the due date, the approximate cost, etc. This will allow the team to better appreciate task packages.
Step 6: Using various formats, such as text-based work breakdown structures, tabular structures, or more visual ones like flowcharts, you can create a WBS. Share it with the team until it is over. With a safe share connection, a creatively functioning breakdown framework can be easily shared with the rest of your team. Once shared, you can collaborate on it in real time.
Key takeaways
- It has a structure that is hierarchical.
- You can add a fourth and a fifth level in the case of a more complicated project.
Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. It is important to note, however, that the schedule evolves over time. During early stages of project planning, a macroscopic schedule is developed. This type of schedule identifies all major software engineering activities and the product functions to which they are applied. As the project gets under way, each entry on the macroscopic schedule is refined into a detailed schedule. Here, specific software tasks (required to accomplish an activity) are identified and scheduled.
You need to plan projects carefully in order to coordinate and complete your projects in a timely, productive and financially responsible manner. In ensuring project progress, successful project preparation plays a crucial role. Set practical time limits, correctly delegate resources and control quality to minimize product defects in order to keep projects on track. Usually, this leads to lower costs and improved customer satisfaction. Financial, paperwork, management and quality assurance are essential variables.
❏ Financial
The scheduling of programs affects a project's overall finances. Time constraints enable project managers to efficiently plan resources. This is especially true when resources are required to have highly specialized skills and experience to complete a task or when expensive materials are needed. Usually, completing a project in a short time period costs more because it needs extra personnel or expedited materials. Realistic forecasts and detailed predictions eliminate last-minute instructions that push up costs with precise project scheduling.
❏ Documentation
You can create a map, such as a Gantt chart, that lists the project tasks, displays dependencies and defines milestones by creating a detailed job breakdown structure. This kind of chart was designed by management consultant Henry Gantt to display a graphic schedule of scheduled work. In business projects, its task is to record and report progress towards the completion of the project. Your project plan also helps you to delegate the job to human resources and determine their allocation to ensure that you have the appropriate rate of usage.
❏ Management
Daily meetings to get status updates are held by successful project managers. To check in with their team members and avoid expensive misunderstandings, they use project scheduling meetings. Such daily meetings ensure that work flows from one process to the next and that each member of the team recognizes that it needs to be done to contribute to the overall success of the project.
❏ Quality
Before the next task in the process starts, project scheduling ensures that one task is accomplished in a quality manner. You ensure that managers and team members resolve concerns as they occur and do not wait for the end, by ensuring that quality initiatives meet standards at every step of the way. Upon completion, there should be no big problems because you have set up quality controls from the very beginning of the scheduling process.
Some steps for using Gantt chart
Step 1 - Review Scope Baseline
The accepted scope baseline consists of three components: 1) the Scope Statement, 2) the Job Breakdown Structure (WBS) and 3) the WBS Dictionary. Assemble the team and review it. The member of the project team should ensure that 100 percent of the project scope is covered by the scope baseline.
Step 2 - Create Activities
The project team breaks down each WBS work kit into tasks using a technique called Decomposition. The team needs to set guidelines for the production of schedule operations, much as when designing the WBS job packages. The final timetable needs to be one that is reliable and accurate. Too many operations can be just as bad as too few. It is also essential to establish deadlines and milestones while the project is decomposing.
Step 3 - Sequence Activities
Any action is connected to one or more other operations. Every operation has a relationship with a predecessor and a successor, except the first and last. Sequencing activities involves using the correct relationships to put the activities in the correct order. Four forms of relationships exist:
➢ Finish to start: Until its predecessor is completed, the successor operation cannot be initiated.
➢ Start to start: The successor operation cannot be initiated until its predecessor has started.
➢ Start to finish: The successor operation cannot be done until its predecessor has begun.
➢ Finish to finish: The successor operation will not be done until its predecessor is completed.
Relationships 1 and 2 are the most widely used. Finish to Start is a sequential relationship and a parallel or overlapping relationship is usually Start to Start.
Step 4 - Estimate Resources
Resources must be defined and measured before the length can be estimated. Labor, supplies, and facilities are tools. Several estimation methods, including Equivalent, Parametric, Three-Point and Bottom Up, are used. Skills, skills and technologies are crucial aspects to be taken into account on the basis of the calculation.
Step 5 - Estimate Durations
The time between the beginning and the end of an operation is the period. Review the methods, interactions and timing, then estimate the length of each operation. To estimate durations, the same estimation methods used for estimating resources can be used, but make sure you define constraints. Which are restrictions on an operation or constraints.
Step 6 - Develop Schedule
Build the Gantt map by loading all data into a software tool for project management. Check the timetable to make sure all timetable risks have been resolved. Check that response plans and contingencies for scheduling have been included. The addition of Buffers at the operation level, the project level or both is a common way of handling schedule contingencies. In order to provide extra time and minimize schedule uncertainties, A Buffer is an operation with no resources or scope.
To build practical schedules, resource management strategies are used, such as resource smoothing or levelling. Check the schedule and accept it. The agreed Gantt chart schedule becomes the baseline of the schedule.
Key takeaways
- The project team breaks down each WBS work kit into tasks using a technique called Decomposition.
- Build the Gantt map by loading all data into a software tool for project management.
Program evaluation and review technique (PERT) and critical path method (CPM) are two project scheduling methods that can be applied to software development. Both techniques are driven by information already developed in earlier project planning activities:
● Estimates of effort
● A decomposition of the product function
● The selection of the appropriate process model and task set
● Decomposition of tasks
Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product as a whole or for individual functions.
Both PERT and CPM provide quantitative tools that allow the software planner to
● Determine the critical path—the chain of tasks that determines the duration of the project;
● Establish “most likely” time estimates for individual tasks by applying statistical models; and
● Calculate “boundary times” that define a time "window" for a particular task.
Boundary time calculations can be very useful in software project scheduling. Slippage in the design of one function, for example, can retard further development of other functions. Riggs describes important boundary times that may be discerned from a PERT or CPM network:
● The earliest time that a task can begin when all preceding tasks are completed in the shortest possible time,
● The latest time for task initiation before the minimum project completion time is delayed,
● The earliest finish—the sum of the earliest start and the task duration,
● The latest finish— the latest start time added to task duration, and
● The total float—the amount of surplus time or leeway allowed in scheduling tasks so that the network critical path is maintained on schedule. Boundary time calculations lead to a determination of critical path and provide the manager with a quantitative method for evaluating progress as tasks are completed.
Both PERT and CPM have been implemented in a wide variety of automated tools that are available for the personal computer. Such tools are easy to use and make the scheduling methods described previously available to every software project manager.
Key takeaways
- Scheduling for software engineering projects can be viewed from two rather different perspectives.
- Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort
- PERT/CPM are two project scheduling methods that can be applied to software development.
4.7.1 The Management Spectrum
Successful project management of software focuses on the four P's: persons, product, method and project. Not arbitrary is the order. In project management, a boss who forgets that software engineering work is an intensely human endeavour will never succeed.
Early in the evolution of a project, a manager who does not facilitate comprehensive customer contact risks building an elegant solution to the wrong problem. The manager, who pays no attention to the operation, runs the risk of putting in a vacuum the necessary technological methods and instruments. The boss who embarks without a strong project plan is risking the product's success.
The scope of management focuses on the four P's; persons, product, process and project. Here, in order to provide a smooth flow in the production of the project and to achieve the objective, the project manager must control all these P's.
The four Leadership Spectrum P's are:
- People
- Product
- Process
- Project
The four P's of the management spectrum are briefly described below:
4.7.2 People
Since the 1960s, the cultivation of driven, highly qualified software individuals has been debated. In reality, the "people factor" is so critical that a people management capacity maturity model (PM-CMM) has been developed by the Software Engineering Institute to improve the readiness of software organizations.
By helping to attract, cultivate, inspire, deploy, and maintain the talent necessary to enhance their software development capabilities, to pursue increasingly complex applications.
Fig 4: 4 p’s of management spectrum
4.7.3 Product
Product goals and scope should be established before a project can be planned, alternative solutions should be considered and technical and management constraints should be identified. Without this information, reasonable (and accurate) cost estimates, an effective risk assessment, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress are impossible to define.
4.7.4 Process
The framework from which a comprehensive software development plan can be established is provided by a software process. A number of different task sets allow the framework activities to be adapted to the characteristics of the software project and the requirements of the project team, such as tasks, milestones, work products and quality assurance points. Finally, umbrella operations overlay the model of the software process.
4.7.5 Project
The project is a complete software project involving the analysis, development, delivery, maintenance and updating of requirements. It is the responsibility of the project manager of a project or sub-project to manage people, products and processes. A long list would be the responsibilities or activities of the software project manager, but that must be followed to prevent project failure.
A software project could be extremely complicated and the failure rate is high, according to industry data. It's just because of the growth, but mostly because of the steps before development and sometimes because of the lack of maintenance.
Key takeaways
- Successful project management of software focuses on the four P's: persons, product, method and project.
- The management framework of software engineering describes the management of a software project.
Barry Boehm gave a philosophy which prepares software projects with simple and manageable designs or outlines. He also presented a methodology to address the priorities, management, obligations and technological approach of the project and its required resources. Then he called it as the W5HH concept when few issues resulted in the success of the project properties, description and resulting plan.
Barry Boehm states: “you need an organizing principle that scales down to provide simple plans for simple projects.”
Those questions are as follows:
❖ Why the system is going to be developed?
Both stakeholders must determine the validity of the product/project framework for the purposes of software work. Here Barry asks whether the object of the project would justify the cost of time spent on it by individuals?
❖ What are the activities are needed to be done in this?
In this, Barry asks what role is currently expected to be performed for the project.
❖ When is this done?
After recognizing when project activities will be started and when they enter the final step to achieve the target, project scheduling is performed by team.
❖ Who are the reasons for these activities in this project?
For this, every member who is part of the software team is responsible. And it determines their positions.
❖ Where are these authoritatively located?
Tech professionals not only have positions in this, but consumers, clients and partners also have organizational roles and obligations as well.
❖ How is job technically and managerially finished?
After understanding the scope of the project that is being developed, all technical techniques and project management rules are established.
❖ How much part of each resource is required?
After estimating each resource as per customer/user requirements, software developers know this.
Key takeaways
- This Bohem W5HH theory is relevant, irrespective of the size or complexity of the development of software projects.
- These questions assist in preparing the software team's project outline.
Process metrics guideline:
● When analyzing data from metrics, utilizing common sense and organizational awareness.
● Provide the people and teams that collect measurements and metrics with daily feedback.
● To intimidate individuals or teams, never use metrics.
● Work to set specific targets and metrics that will be used to achieve them with professionals and teams.
● Data on metrics that demonstrate a problem area should not be regarded as "negative" Such knowledge is merely a measure of process change.
● To the exclusion of other significant metrics, don't obsess on a single metric.
Process metrics
➢ Quality related: Concentrate on the quality of goods and deliverables at work.
➢ Productivity related: Job development - an increased effort-related commodity.
➢ Statistical SAQ data: error categorization and analysis.
➢ Defect removal efficiency: Propagation of error from operation of processes to activity.
➢ Reuse data: The number of generated components and their degree of reusability.
Project metrics
● Used by making the necessary changes to prevent delays and mitigate possible issues and risks to minimize the development timeline.
● Used to ensure consistent access to product quality and, where appropriate, to change the technical approach to quality management.
● Each project should be assessed by:
❏ Input: Measures of the tools needed to do the job (e.g. Personnel and instruments)
❏ Output: Measures of the deliverables or job items produced during the process of software engineering.
❏ Result: Measures that show the deliverables' efficacy.
Typical project metrics
● Effort /time per software engineering task
● Errors uncovered per review hour.
● Changes (number) and their characteristics
Key takeaways
- Don't use metrics to measure people
- Work to set specific targets and metrics that will be used to achieve them with professionals and teams
Estimation of the size of software is an essential part of software project management. It helps the project manager to further predict the effort, cost and time which will be needed to build the product. The project size is a measure of the problem complexity in terms of the effort and time required to build the product.
There are two software matrices which are being used to estimate size:
● Size Oriented metrics
It focuses on the size of the software that has been produced. If a software organization maintains simple records, a table of size-oriented measures, such as shown below can be created. The table lists each software development project that has been completed over the past few years and corresponding measures for that project.
Fig 5: size oriented metrics
It shows that for the project: alpha, 12,100 LOC were developed with 24 person months of effort, at a cost of $168,000. Note that the effort and cost recorded in the table represent all software engineering activities (i.e. analysis, design, code and test) and not just coding. Furthermore, it shows that 365 pages of documentation were developed, 134 errors were recorded before software was released and 29 defects were encountered after release to the customer within the first year of operation and three people worked on this project alpha.
In order to develop metrics that can be assimilated with similar metrics from other projects, we choose lines of code as our normalization value. From the rudimentary data contained in the table, a set of simple size-oriented metrics can be developed for each project:
● Errors per KLOC (thousand lines of code).
● Defects per KLOC.
● $ per LOC.
● Page of documentation per KLOC.
In addition, other interesting metrics can be computed:
● Errors per person-month.
LOC per person-month.
● $ per page of documentation.
Size-oriented metrics are not universally accepted as the best way to measure the process of software development. Most of the controversy swirls around the use of lines of code as a key measure. Proponents of the LOC measure claim that LOC is an "artifact" of all software development projects that can be easily counted, that many existing software estimation models use LOC or KLOC as a key input, and that a large body of literature and data predicated on LOC already exists. On the other hand, opponents argue that LOC measures are programming language dependent, that they penalize well-designed but shorter programs, that they cannot easily accommodate nonprocedural languages, and that their use in estimation requires a level of detail that may be difficult to achieve (i.e., the planner must estimate the LOC to be produced long before analysis and design have been completed).
● Function-Oriented Metrics
Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value. Since ‘functionality’ cannot be measured directly, it must be derived indirectly using other direct measures. Function-oriented metrics were first proposed by Albrecht, who suggested a measure called the function point. Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity.
Fig 6: computing functional point
Function points are computed by completing the table shown in Figure above. Five information domain characteristics are determined and counts are provided in the appropriate table location. Information domain values are defined in the following manner:
Number of user inputs – Each user input that provides distinct application-oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately.
Number of user outputs – Each user output that provides application-oriented information to the user is counted. In this context output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately.
Number of user inquiries – An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted.
Number of files – Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted.
Number of external interfaces – All machine-readable interfaces (e.g., data files on storage media) that are used to transmit information to another system are counted.
Once these data have been collected, a complexity value is associated with each count. Organizations that use function point methods develop criteria for determining whether a particular entry is simple, average, or complex. Nonetheless, the determination of complexity is somewhat subjective. To compute function points (FP), the following relationship is used:
FP = count total * [0.65 + 0.01 * Σ(Fi)]
Where count total is the sum of all FP entries obtained from Figure above.
The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions:
● Does the system require reliable backup and recovery?
● Are data communications required?
● Are there distributed processing functions?
● Is performance critical?
● Will the system run in an existing, heavily utilized operational environment?
● Does the system require on-line data entry?
● Does the on-line data entry require the input transaction to be built over multiple screens or operations?
● Are the master files updated on-line?
● Are the inputs, outputs, files, or inquiries complex?
● Is the internal processing complex?
● Is the code designed to be reusable?
● Are conversion and installation included in the design?
● Is the system designed for multiple installations in different organizations?
● Is the application designed to facilitate change and ease of use by the user?
Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential). The constant values in Equation and the weighting factors that are applied to information domain counts are determined empirically. Once function points have been calculated, they are used in a manner analogous to LOC as a way to normalize measures for software productivity, quality, and other attributes:
● Errors per FP.
● Defects per FP.
● $ per FP.
● Pages of documentation per FP.
● FP per person-month.
Key takeaways
- FP is programming language independent, making it ideal for applications using conventional and non-procedural languages.
- It focuses on the size of the software that has been produced.
- Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value.
- The project size is a measure of the problem complexity in terms of the effort and time required to build the product.
These are indicators that relate to the quality of projects. They are used to measure errors, prices, scheduling, efficiency and estimation of different resources and deliverables of the project.
- Schedule Variance: Any inconsistency is known as Schedule Variation between the expected completion of an operation and the actual completion.
Schedule variance = ((Actual calendar days – Planned calendar days) + Start variance)/ Planned calendar days x 100.
2. Effort Variance: The gap between the expected effort outlined and the effort needed to actually execute the mission is called the variance of effort.
Effort variance = (Actual Effort – Planned Effort)/ Planned Effort x 100.
3. Size Variance: Difference between the approximate project size and the project's actual size (normally in KLOC or FP).
Size variance = (Actual size – Estimated size)/ Estimated size x 100.
4. Requirement Stability Index: Provides visibility of the extent and effect of changes in specifications.
RSI = 1- ((Number of changed + Number of deleted + Number of added) / Total number of initial requirements) x100.
5. Productivity (Project): A calculation of output for an input unit from a related process.
Project Productivity = Actual Project Size / Actual effort expended in the project.
6. Productivity (for test case preparation) = Actual number of test cases/ Actual effort expended in test case preparation.
7. Productivity (for test case execution) = Actual number of test cases / actual effort expended in testing.
8. Productivity (defect detection) = Actual number of defects (review + testing) / actual effort spent on (review + testing).
9. Productivity (defect fixation) = actual no of defects fixed/ actual effort spent on defect fixation.
10. Schedule variance for a phase: The deviation between scheduled and actual schedules within a project for the phases.
Schedule variance for a phase = (Actual Calendar days for a phase – Planned calendar days for a phase + Start variance for a phase)/ (Planned calendar days for a phase) x 100
11. Effort variance for a phase: The deviation between a scheduled and actual effort within the project for different phases.
Effort variance for a phase = (Actual effort for a phase – a planned effort for a phase)/ (planned effort for a phase) x 100.
For an effective management accurate estimation of various measures is a must.
With correct estimation managers can manage and control the project more
Efficiently and effectively.
Project estimation may involve the following:
● Software size estimation
Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by calculating the number of function points in the software. Lines of code depend upon coding practices and Function points vary according to the user or software requirement.
● Effort estimation
The managers estimate efforts in terms of personnel requirement and man-hour required to produce the software. For effort estimation software size should be known. This can either be derived by managers’ experience, organization’s historical data or software size can be converted into efforts by using some standard formulae.
● Time estimation
Once size and efforts are estimated, the time required to produce the software can be estimated. Efforts required is segregated into sub categories as per the requirement specifications and interdependency of various components of software. Software tasks are divided into smaller tasks, activities or events by Work Breakthrough Structure (WBS). The tasks are scheduled on a day-to-day basis or in calendar months. The sum of time required to complete all tasks in hours or days is the total time invested to complete the project.
● Cost estimation
This might be considered as the most difficult of all because it depends on more elements than any of the previous ones. For estimating project cost, it is required to consider -
- Size of software
- Software quality
- Hardware
- Additional software or tools, licenses etc.
- Skilled personnel with task-specific skills
- Travel involved
- Communication
- Training and support
Key takeaways
- For an effective management accurate estimation of various measures is a must.
- Software size may be estimated either in terms of KLOC or by calculating the number of function points in the software
- Once size and efforts are estimated, the time required to produce the
- software can be estimated.
The software is believed by this approach to be a product of different compositions.
Before it is possible to make an approximation and apply decomposition techniques, the planner must
- Understand the complexity of the programme to be designed.
- Generate an approximation of the size of the programme.
Two major models exist -
Line of code (LOC): The calculation is conducted on behalf of the number of codes in the software product line.
Functions points (FP): Estimation is performed on behalf of the number of software product feature points.
Either of two strategies is then used
- Problem based estimation
Based on either code source lines or estimates of feature points.
- Process based estimation
Based on the effort needed to achieve each assignment.
Problem-Based Estimation
Start with a restricted declaration of scope. Decompose the programme into problem functions that can be independently calculated for each one. For each function, compute a LOC or FP value. By adding the LOC or FP values to the base productivity metrics (e.g. LOC/person-month or FP/person-month) to extract cost or effort estimates. Merge for the whole project.
LOC and FP estimation are different estimation methods, but both have a number of characteristics in common. The project manager starts with a restricted software scope statement and tries to decompose software into problem functions that can be independently calculated from this statement. LOC or FP (the estimation variable) is then estimated for each function.
Process-Based Estimation
The most popular way of estimating a project is to base the estimation on the method that will be used. That is, the method is broken down into a relatively small set of tasks and it calculates the effort needed to accomplish each task.
Process-based estimation starts, like problem-based techniques, with a delineation of software functions obtained from the scope of the project. For each function, a sequence of software process operations must be performed.
Functions and related activities of the software process can be described as part of a table.
When problem functions and process activities are melded, the planner calculates the effort needed to execute each software process operation for each software function (e.g., person-months). These data constitute the table's core matrix.
Key takeaways
- In decomposition technique
- Understand the complexity of the programme to be designed.
- Generate an approximation of the size of the programme.
- Decompose the programme into problem functions that can be independently calculated for each one.
- LOC and FP estimation are different estimation methods, but both have a number of characteristics in common.
- Process-based estimation starts, like problem-based techniques, with a delineation of software functions obtained from the scope of the project
For all projects, accurate cost estimates are important. It would be difficult to prepare a business plan, set up comprehensive budgets, forecast resource needs or manage project costs without a cost estimate.
Estimating project costs scares a lot of people. They don't know how much it's going to cost, but they know whatever value they offer, their boss will keep them.
The Project Cost Engineer uses either one or a combination of the following instruments and techniques in the cost estimation process:
Fig 7: cost estimation technique
● EXPERT JUDGEMENT
To estimate the cost of the project, expert judgement uses the expertise and knowledge of experts. The particular factors related to the project can be taken into account in this technique. It can also be biased, however.
● ANALOGOUS ESTIMATING
The values such as scope, expense, budget and length or measurements of scale such as size, weight and complexity from a previous, equivalent project are used in an analogous cost estimate as the basis for calculating the same parameter or measurement for a current project.
This methodology relies on the actual cost of previous, related projects when calculating costs as the basis for estimating the cost of the current project.
● PARAMETRIC ESTIMATING
In order to build a cost estimate, parametric estimation uses statistical modelling. To calculate an estimate for various parameters such as cost and length, it utilizes historical data from key cost drivers. Square footage, for instance, is used in some building projects.
● BOTTOM-UP ESTIMATING
In order to calculate an overall cost estimate for the project, bottom-up estimating uses the estimates of individual job packages that are then summarized or 'rolled up'. In general, this type of calculation is more comprehensive than other approaches since it looks at costs from a more granular perspective.
● THREE - POINT ESTIMATING
By using three estimates, the three-point estimation approach defines a spectrum of operation costs.
- Best case (B)
- Most likely (M)
- Worst case (W)
One of the main benefits of using the project cost estimation approach is that, compared to other project cost estimation methods, it gives you far more reliable and balanced estimates. The formula for three is used - estimation is :
Formula: E = (B + 4M + W) /6
● PROJECT MANAGEMENT ESTIMATING SOFTWARE
Software forecasting project management includes software cost estimating programs, spreadsheets, modelling applications, and tools for statistical software. This form of programme is particularly useful for looking at alternatives to cost estimation.
● Decision-Making Method
Unanimity, majority, plurality, division of points, and dictatorship are some decision techniques. All must insist on unanimity; there is a common consensus. Normally, a majority or plurality is decided by a vote. For a majority, more than half the participants must agree on the decision.
Key takeaways
- For all projects, accurate cost estimates are important.
- One of the most significant processes of project management is calculating costs.
- You can use it for many reasons, such as when negotiating for a project, if a company needs to know the cost of quoting the correct price.
Very often, the problems with your calculation of building costs are not readily evident. You see the consequences, but not the causes. The first step towards bringing greater productivity into your company is to identify those issues, particularly when they are small and seemingly innocuous. Here are 5 cost-estimating errors you're likely to make if you're struggling with this challenge.
- Using Hand Calculations
In order to do quality construction cost estimations, you need the right software. There really isn't any way to get around it. You create a greater risk of mistakes and unnecessarily slow down the process if the employees still perform cost estimating calculations by hand.
2. Expecting Software to Solve All Your Problems
It's safe to believe that all you need to do is have the proper tools. Cost-estimating software for building is an excellent tool that you can certainly use, but it needs to be used by a competent professional who knows how to use it to its maximum potential.
3. Failing to Allocate Enough Resources in Estimates
You know that for the success of a project, proper cost estimation is important. So why do many construction companies struggle to bring in the requisite human resources, equipment, and skills to do it right? This links back to the above-mentioned problems, such as using competent cost estimating tools, as well as neglecting to look closely at the spec book of the project.
4. Not Creating a Risk/Assumptions/Opportunities Register
This is an interesting tip that is deliberately employed by very few construction firms. In its cost estimation, the organization might be able to take certain measured risks, or to make some assumptions about material prices, labour delays and other possible problems. The idea here is that all of those aspects of your cost estimates should be tracked.
5. Neglecting to Review Cost Estimates at Project Completion
You may not have realized that, but after a project has been completed, there are cost estimation errors you can make. It's a chance for reflection on your process any time you complete a project. It's an opportunity to see what's working and what's not.
You're losing the crucial opportunities to change without taking the time to sit down and have a thorough conversation about each aspect of the cost estimate and how it was actually expressed in the project itself.
Key takeaways
- You see the consequences, but not the causes.
- The first step towards bringing greater productivity into your company is to identify those issues
References
- Roger Pressman, “Software Engineering: A Practitioner’s Approach”, McGraw Hill, ISBN 0-07-337597-7
- Ian Sommerville, “Software Engineering”, Addison and Wesley, ISBN 0-13-7035152
- Joseph Phillips, “IT Project Management-On Track From start to Finish”, Tata McGraw-Hill, ISBN13:978-0-07106727-0, ISBN-10:0-07-106727-2
- Pankaj Jalote, “Software Engineering: A Precise Approach”, Wiley India, ISBN: 9788-1265-2311-5
- Marchewka, “Information Technology Project Management”, Willey India, ISBN: 9788-1265-4394-6
- Rajib Mall, “Fundamentals of Software Engineering”, Prentice Hall India, ISBN-13:9788-1203-4898-1
