What is project planning?

Project planning is a discipline addressing how to complete a project in a certain timeframe, usually
with defined stages and designated resources. One view of project planning divides the activity into
these steps:
• setting measurable objectives
• identifying deliverables
• scheduling
• planning tasks
For example, you could need to adjust the project timeline after planning your resources to avoid
burning out your employees. As a result, the project planning processes can quickly become
complicated!

components :-
• Scope. The scope determines what a project team will and will not do. It takes the team's
vision, what stakeholders want and the customer's requirements and then determines
what's possible. As part of defining the project scope, the project manager must set
performance goals.
• Budget. Project managers look at what manpower and other resources will be required to
meet the project goals to estimate the project's cost.
• Timeline. This reveals the length of time expected to complete each phase of the project
and includes a schedule of milestones that will be met.

project planning process:-

Project planning includes the following 10 steps:
1. Define stakeholders. Stakeholders include anyone with an interest in the project. They can
include the customer or end user, members of the project team, other people in the
organization the project will affect and outside organizations or individuals with an interest.
2. Define roles. Each stakeholder's role should be clearly defined. Some people will fill multiple
roles, however.
3. Introduce stakeholders. Hold a meeting to bring stakeholders together and unify the vision
behind the project. The topics covered should include scope, goals, budget, schedule and
roles.
4. Set goals. Take what is gleaned from the meeting and refine it into a project plan. It should
include goals and deliverables that define what the product or service will result in.
5. Prioritize tasks. List tasks necessary to meet goals and prioritize them based on importance
and interdependencies. A Gantt chart can be helpful for mapping project dependencies.
 6. Create a schedule. Establish a timeline that considers the resources needed for all the tasks.
7. Assess risks. Identify project risks and develop strategies for mitigating them.
8. Communicate. Share the plan with all stakeholders and provide communications updates in
the format and frequency stakeholders expect.
9. Reassess. As milestones are met, revisit the project plan and revise any areas that are not
meeting expectations.
10. Final evaluation. Once the project is completed, performance should be evaluated to learn
from the experience and identify areas to improve.

5 phases of a project planning

Projects typically pass through five phases. The project lifecycle includes the following:
• Initiation defines project goals and objectives. It also is when feasibility is considered, along
with how to measure project objectives.
• Planning sets out the project scope. It establishes what tasks need to get done and who will
do them.
• Execution is when the deliverables are created. This is the longest phase of a project. During
execution, the plan is set into motion and augmented, if necessary.
• Monitoring and management occur during the execution phase and may be considered part
of the same step. This phase ensures that the project is going according to plan.
• Closing and review is the final Contracts are closed out and the final deliverables are given
to the client. Successes and failures are evaluated.

Software scope and feasibility :-

Software scope refers to the boundaries and limitations of a software project, defining what the
project will deliver, how it will be done, and what functionalities and features will be included. It
helps set clear expectations and ensures that the project stays focused and manageable. Feasibility,
on the other hand, refers to assessing whether the project is technically, financially, and
operationally viable.

Software Scope: Defining the software scope is a critical step in project planning. It involves
determining project goals, tasks, costs, and deadlines. The scope outlines the functions,
performance, constraints, and interfaces of the software. It helps manage expectations, avoid scope
creep (uncontrolled expansion of project scope), and deliver quality results. A clear and realistic
scope is essential for effective project management and successful software development

Software Feasibility: Software feasibility refers to evaluating the practicality and viability of a
software project. It involves assessing various factors, such as technical, economic, legal,
operational, and scheduling considerations, to determine whether the project is feasible and worth
pursuing. Conducting a feasibility study is crucial in software development as it helps identify
potential challenges, risks, and obstacles associated with the project. It allows stakeholders to make
informed decisions by providing insights into the project's scope, cost, benefits, and potential
obstacles before significant resources are invested

A typical feasibility study in software engineering includes an analysis of technical feasibility,

economic feasibility, legal feasibility, operational feasibility, and scheduling feasibility. These
components collectively provide a comprehensive understanding of whether a software project is
viable and can be successfully executed

Resources Used in Project Development

Project resources simply mean resources that are required for successful development and
completion of project. These resources can be capital, people, material, tool, or supplies that are
helpful to carry out certain tasks in project. Without these resources, it is impossible to complete
project. In project planning phase, identification of resources that are required for completion of
project and how they will be allocated is key element and very important task to do. In project
management, some resources that are required are assigned to each task of project to get job
done. There are three types of resources that are considered and are very essential for execution of
project and completion of project on time and on budget. These resources can be denoted by
pyramid which is also known as Resource Pyramid. At base of pyramid i.e. last layer, hardware and
software tools are present, then at middle layer, reusable components are present, and at top of
pyramid i.e. top layer, human resources are present.
This is shown in following diagram :

Types of resources :
1. Human Resource – Human plays an important role in software development process. No
matter what size is and how much complexity is there in project, if you want to perform
project task in an effective manner, then human resources are very essential. In software
industry, people are assigned some organizational positions such as manager, software
 developer, software testing, engineer, and so on. These positions are according to their skills
and specialty. For small project only, single individual can perform all these roles. But for
large project, team of people works on it. The total number of people that are required for
project is estimated by calculating development effort inters of person-months.
2. Reusable Components – For bringing ease in software development process or to accelerate
development process software, industry prefers to use some ready software components.
The components can be defined as the software building blocks that can be created and
reused in software development process. Generally, regardless of their type, size, or
complexity, all projects need money. Managing budget for project is one of most important
tasks that all project managers have to do. The reusable resources also known as cost
resources are very helpful as they help in reducing overall cost of development. The use of
components emphasizes reusability. This is also termed as Component-Based Software
Engineering.
3. Hardware and Software tools – These are actually material resources that are part of
project. This type of resource should be planned before starting development of project
otherwise it way causes problems for the project. For example, if you require certain
software elements during performing task and somehow you can’t manage to get them on
time, even they could take few weeks to ship from manufacturer and this will cause delay to
your project.
Additional Types of Resources used in Project Development:
1. Money Resources: Financial planning, budgeting and funding make sure that you’ve got the
money to pay your staff, obtain more resources and maintain the project.
2. Information Resources: Access to important information, records and additional materials
that support your team’s decision-making and seamless progress.
4. Examining and ensuring quality Resources: Equipment and workers committed to making
sure the final product is free of mistakes and fulfils the required standards.
6. Communication Resources: Anything that enables easy communication within your team,
such as video conferencing tools, messaging apps and email.

Software Project Estimation

Software project estimation is the process of predicting the amount of effort, time, and resources
required to complete a software project. This involves assessing the scope of work, identifying the
tasks needed, and determining the resources (including personnel, tools, and budget) necessary to
achieve the project goals. Accurate estimation is crucial for effective planning, budgeting,
scheduling, and resource allocation, ensuring that the project can be completed on time and within
budget while meeting the desired quality standards.
Key Components of Project Estimation
In project management estimation, every project is a triangle balancing act with three components:
• Cost
• Scope
• Time
2.1. Cost
In project management, cost is one of the three primary constraints. The project will fail if you do
not have sufficient funds to complete it. You can help set client expectations and ensure you have
enough money to complete the work if you can accurately estimate project costs early on.
Estimating costs entails determining how much money you’ll need and when you’ll need it.
2.2. Time
Another of the project’s three main constraints is the lack of time. It is critical for project planning
to be able to estimate both the overall project duration and the timing of individual tasks.
You can plan for people and resources to be available when you need them if you estimate your
project schedule ahead of time. It also enables you to manage client expectations for key
deliverables.
2.3. Size Or Scope
The third major project constraint is scope. The project scope refers to all of the tasks that must be
completed in order to complete the project or deliver a product. You can ensure that you have the
right materials and expertise on the project by estimating how much work is involved and exactly
what tasks must be completed.
Project Estimation Methods
Now that you understand the importance of project estimation and its elements, let's explore the
most popular project estimation techniques.
Top-Down Estimate
When you need to get a project done in an exact amount of time, the top-down estimation
technique can be a good solution. Utilizing this classic method for estimating software projects
starts by defining an overarching timeline. You then logically break it down into progressively more
granular phases and tasks – known as Work Breakdown Structure (WBS) – so that all objectives can
be met within the allotted timeframe. Top-down estimating in project management provides clients
with peace of mind knowing their projects will stay on track for delivery before the deadline.
Bottom-Up Estimate
This is the reverse of the above project estimation method. In it, you estimate each task individually
- then combine them for a more precise schedule. Though such project management estimation
techniques take longer, you'll ultimately get a more accurate estimate of the time needed to
complete the project.
Analogous Estimation
The analogous project estimation technique involves comparing your current undertaking with one
similar in scope that has already been completed. Thus, you leverage past experience for greater
precision when resources are limited. Analogous estimating in project management is rather
effective as by studying variables from similar previous projects and applying them top-down to
estimation calculations, you'll have more data and accuracy to rely upon.
Parametric Estimation
Parametric estimating in project management is another powerful estimation method to gather the
insights of past projects and incorporate them into current time estimates. By utilizing parametric
modeling, managers can predict timelines for their upcoming venture more accurately by adjusting
old project data in accordance with any discrepancies between them. With the parametric
estimating method, it is possible to get more precise estimates based on the details from a
previous project and pro-rating it.

Empirical Estimation Models

Empirical estimation models are methods used to predict the effort, cost, and duration of a
software project based on historical data and statistical analysis. These models use data from
previous projects to create formulas and algorithms that estimate the resources needed for new
projects. The two most widely recognized empirical estimation models are COCOMO (Constructive
Cost Model) and Function Point Analysis (FPA).
The estimation models are based on the following relationship:

COCOMO Model:
COCOMO (Constructive Cost Model) is a regression model based on number of Lines of Code (LOC).
It is a procedural cost estimation model for software projects. This model is used for predicting the
various parameters associated with developing a project such as size, effort, cost and time.
COCOMO was proposed by Barry Boehm in 1970 and is based on the study of 63 projects.
Effort and schedule parameters are outcomes of COCOMO model.

• Effort: Amount of labor (staff) that will be required to complete a task. It is measured in person-
months units.
• Schedule: means the amount of time required for the completion of the job, which is
proportional to the effort. It is measured in the units of time such as weeks, months.

Different models of COCOMO have been proposed to predict the cost estimation at different levels,
based on the amount of accuracy and correctness required. All of these models can be applied to a
variety of projects. Boehm’s categorizes the projects as follows:
1. Organic: If the team size required to develop a software project is small then the software
project is called as Organic project. In this the problem is well understood and has been solved in
the past and also the team members have a nominal experience regarding the problem.
2. Semi-detached: If the main features such as team-size, experience, knowledge of the various
programming environment lie in between Organic and Embedded then software project is called as
Semi-detached type project. The Semi-Detached projects are less familiar and difficult to develop
compared to the organic ones and require more experience and better guidance and creativity. Eg:
Compilers or different Embedded Systems.
3. Embedded: Embedded software projects require highest level of complexity, creativity, and
experience. This type of software requires a larger team size than the other two models and also
the developers need to be sufficiently experienced and creative to develop such complex models.
All the above system types utilize different values of the constants used in Effort and Time
calculations.

There are three types of COCOMO model:

1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model

1. Basic Model

The basic COCOMO model provide an accurate size of the project parameters.
The following expressions give the basic COCOMO estimation model:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Where
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a1,a2,b1,b2 are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months
(PMs).
The above formula is used for the cost estimation of the basic COCOMO model and also is used in
the subsequent models. The constant values a, b, c, and d for the Basic Model for the different
categories of the system:
Software Projects A1 A2 B1 B2

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

1. The effort is measured in Person-Months and as evident from the formula is dependent on
Kilo-Lines of code. The development time is measured in months.
2. These formulas are used as such in the Basic Model calculations, as not much consideration
of different factors such as reliability, and expertise is taken into account, henceforth the
estimate is rough.
2. Intermediate Model
The basic Cocomo model assumes that the effort is only a function of the number of lines of code
and some constants evaluated according to the different software systems. However, in reality, no
system’s effort and schedule can be solely calculated based on Lines of Code. For that, various
other factors such as reliability, experience, and Capability. These factors are known as Cost Drivers
and the Intermediate Model utilizes 15 such drivers for cost estimation. Classification of Cost
Drivers and their Attributes:
Classification of Cost Drivers and their attributes:
1. Required software reliability extent
2. Size of the application database
3. The complexity of the product
4. Run-time performance constraints
5. Memory constraints
6. The volatility of the virtual machine environment
7. Required turnabout time
8. Analyst capability
9. Software engineering capability
10. Applications experience
11. Virtual machine experience
12. Programming language experience
13. Use of software tools
14. Application of software engineering methods
15. Required development schedule
Intermediate COCOMO equation:
E=ai (KLOC) bi*EAF
D=ci (E)di
Coefficients for intermediate COCOMO

Project ai bi ci di

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

3. Detailed COCOMO Model:Detailed COCOMO incorporates all qualities of the standard version
with an assessment of the cost driver?s effect on each method of the software engineering
process. The detailed model uses various effort multipliers for each cost driver property. In detailed
cocomo, the whole software is differentiated into multiple modules, and then we apply COCOMO in
various modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model

Estimation for object-oriented projects

Estimating the effort and feasibility of object-oriented projects is an important aspect of project
planning. While the search results provide limited information on this topic, I can provide some
general insights based on my knowledge as a language model. Here are some considerations for
estimating object-oriented projects:
1. Size Estimation Techniques: Various size estimation techniques can be used for object-
oriented projects. One such technique is Object Points, which estimates the size of a project
based on the number of objects and their complexity. Another approach is Class Point
estimation, which estimates effort based on the number of classes and their complexity.
 2. Effort Estimation: Effort estimation involves estimating the amount of work required to
complete the project. It takes into account factors such as the size and complexity of the
project, the skills and experience of the development team, and the available resources.
Effort estimation can be done using techniques like Function Point Analysis (FPA) or
COCOMO (COnstructive COst MOdel).
3. Feasibility Analysis: Feasibility analysis assesses the practicality and viability of the project.
It considers factors such as technical feasibility (whether the project can be implemented
with the available technology), economic feasibility (whether the project is financially
viable), and operational feasibility (whether the project aligns with the organization's
capabilities and goals).
4. Historical Data and Expert Judgment: Historical data from previous projects can provide
valuable insights for estimating effort and feasibility. Analyzing similar past projects can help
identify patterns and trends that can be used as a basis for estimation. Additionally, expert
judgment from experienced project managers and developers can contribute to more
accurate estimations.
5. Risk Assessment: Assessing and managing risks is crucial in project estimation. Identify
potential risks and uncertainties that may impact the project's success and estimate their
potential impact on effort and feasibility. This allows for contingency planning and risk
mitigation strategies.

Estimating effort for Agile development and web engineering projects

Estimating effort for Agile development and web engineering projects in software project
management requires a flexible approach that aligns with the iterative nature of Agile
methodologies and the specific requirements of web engineering. Here are some techniques
commonly used in Agile projects for estimating effort:
1. Story Points: Agile teams often use story points to estimate the relative size or effort
required for user stories or tasks. Story points are a unitless measure that reflects the overall
complexity, risk, and effort involved in implementing a particular feature or functionality.
Teams typically assign story points based on consensus during sprint planning sessions.
2. Planning Poker: Planning poker is a collaborative technique used by Agile teams to estimate
the effort required for each user story. Team members individually estimate the story points
for a user story, and then discuss their estimates. Any significant discrepancies are discussed,
and the team reaches a consensus on the final estimate through discussion and negotiation.
3. Relative Estimation: Instead of estimating absolute time or effort, Agile teams often use
relative estimation techniques such as comparing user stories to each other in terms of
complexity or effort required. This approach can provide more accurate estimates and is less
prone to bias than trying to estimate absolute values.
4. Velocity Tracking: Agile teams track their velocity, which is the amount of work completed in
each sprint. By analyzing past velocity, teams can forecast how much work they can
accomplish in future sprints, allowing for more accurate long-term planning and estimation.
 5. Burn-down Charts: Burn-down charts visually represent the progress of a project by
showing the remaining work (usually measured in story points or tasks) over time. By
comparing actual progress with the planned trajectory, teams can identify deviations and
adjust their estimates and plans accordingly.
For web engineering projects specifically, some additional considerations for estimation include:
1. Frontend vs. Backend Development: Break down the project into frontend and backend
tasks, and estimate the effort required for each separately. Frontend tasks may involve UI
design, client-side scripting, and user interaction, while backend tasks may involve server-
side logic, database design, and API development.
2. Browser Compatibility: Consider the effort required to ensure cross-browser compatibility
and responsiveness across different devices and screen sizes. This may involve additional
testing and development effort.
3. Integration and Deployment: Factor in the effort required for integrating third-party
services, deploying the application to production environments, and setting up continuous
integration/continuous deployment (CI/CD) pipelines.
4. Iterative Development: Since web projects often involve rapid iterations and frequent
updates, it's important to account for ongoing maintenance and feature enhancements in
the estimation process.

What is a Make-or-Buy Decision?

A make-or-buy decision refers to an act of using cost-benefit to make a strategic choice between
manufacturing a product in-house or purchasing from an external supplier. It arises when a
producing company faces a diminishing capacity, experiences problems with the current suppliers,
or sees changing demand.

The make-or-buy decision compares the costs and benefits that accrue by producing a good or
service internally against the costs and benefits that result from subcontracting. For an accurate
comparison of costs and benefits, managers need to evaluate the benefits of purchasing expertise
against the benefits of developing and nurturing the same expertise within the company.

Reasons for Making

There are number of reasons a company would consider when it comes to making in-house.
Following are a few:
• Cost concerns
• Desire to expand the manufacturing focus
• Need of direct control over the product
• Intellectual property concerns
• Quality control concerns
• Supplier unreliability
• Lack of competent suppliers
• Volume too small to get a supplier attracted
• Reduction of logistic costs (shipping etc.)
• To maintain a backup source
• Political and environment reasons
• Organizational pride
Reasons for Buying
Following are some of the reasons companies may consider when it comes to buying from a
supplier:
• Lack of technical experience
• Supplier's expertise on the technical areas and the domain
• Cost considerations
• Need of small volume
• Insufficient capacity to produce in-house
• Brand preferences
• Strategic partnerships
The Process
The make or buy decision can be in many scales. If the decision is small in nature and has less
impact on the business, then even one person can make the decision. The person can consider the
pros and cons between making and buying and finally arrive at a decision.
When it comes to larger and high impact decisions, usually organizations follow a standard method
to arrive at a decision. This method can be divided into four main stages as below.

1. Preparation
• Team creation and appointment of the team leader
• Identifying the product requirements and analysis
• Team briefing and aspect/area destitution
2. Data Collection
• Collecting information on various aspects of make-or-buy decision
• Workshops on weightings, ratings, and cost for both make-or-buy
3. Data Analysis
• Analysis of data gathered
4. Feedback
• Feedback on the decision made
By following the above structured process, the organization can make an informed decision on
make-or-buy. Although this is a standard process for making the make-or-buy decision, the
organizations can have their own varieties.