Software Project Planning

Unit 2 – Software Project Management

Steps in Project Planning
1. Project Initiation
2. Defining Project Scope
3. Work Breakdown Structure (WBS)
4. Project Scheduling
5. Resource Planning
6. Estimation – Effort, Cost
7. Risk Management
8. Quality Assurance Planning
9. Communication and Reporting
10. Project Closure and Review
Project Initiation
RetailMax, a growing retail chain, faced increasing difficulties managing customer
interactions due to an outdated CRM system. Sales representatives struggled to track
customer histories, marketing campaigns lacked personalization, and customer complaints
often went unresolved. Recognizing the need for improvement, the leadership decided to
initiate a project for a modern CRM system to streamline operations and enhance
customer relationships.
To determine feasibility, the IT team assessed technical requirements and recommended a
cloud-based solution for better scalability. The finance team estimated a $500,000 budget,
projecting a strong return on investment through improved sales efficiency and customer
retention. Risks such as data migration challenges and employee adaptation were
identified, with mitigation plans including phased implementation and comprehensive
training.
A project charter was created to define objectives, scope, budget, and key stakeholders. A
cross-functional team was assembled, and a project manager was appointed to oversee
execution. With a clear vision and structured plan, RetailMax was ready to embark on a
transformative journey toward a smarter, more efficient CRM system.
 Project Initiation

•Define Project Objectives: Identify the purpose and goals of the project.
•Conduct Feasibility Study: Assess technical, financial, operational, and legal
feasibility.
•Identify Stakeholders: Determine key people involved, including sponsors, users,
and the development team.
•Develop Project Charter: Create a high-level document outlining the project scope,
objectives, and constraints.
Defining Project Scope
RetailMax initiated the CRM project by gathering input from key stakeholders, including
sales, marketing, and customer support teams. Through workshops and discussions, they
identified core business requirements: sales needed an intuitive dashboard for tracking
customer interactions, marketing requested automated email campaigns, and customer
support required a unified system for managing queries.
To ensure focus, the team prioritized features using the MoSCoW method. Must-have
features included customer data management, sales tracking, and reporting dashboards.
Should-have features, like email automation, were planned for early implementation, while
advanced AI-driven recommendations were marked for future development. To prevent
scope creep, certain features were explicitly excluded from the initial scope, such as social
media integration, full-scale predictive analytics, and mobile app development, which
would be considered in later phases.
By defining a well-structured scope, RetailMax aligned stakeholder expectations, set
achievable goals, and created a roadmap that balanced immediate needs with long-term
growth, paving the way for a successful CRM implementation.
Defining Project Scope
•Gather Requirements: Collect business and technical requirements from stakeholders.
•Define Deliverables: List the features and functionalities the software must have.
•Set Boundaries: Identify what is included and excluded from the project.
•Prioritize Features: Use techniques like MoSCoW (Must Have, Should Have, Could
Have, Won’t Have) to prioritize.
3. Work Breakdown Structure
With the project scope defined, RetailMax broke down the work into structured tasks. The project was divided
into key phases: requirements gathering, system design, development, testing, deployment, and training. Each
phase was further detailed to ensure clarity and accountability.

Requirements gathering focused on user needs and system functionalities, while system design involved data
modeling and UI wireframes. Development was split between front-end and back-end tasks, including
database setup and API integrations. Testing covered unit and user acceptance testing, ensuring system
stability before deployment. Data migration, phased rollout, and staff training were planned to ensure a
smooth transition.

Dependencies were mapped to prevent delays, and tasks were assigned to the respective teams. A timeline
with milestones was created, tracking progress from prototyping to final launch. With a clear breakdown of
responsibilities and deliverables, RetailMax ensured efficiency, reducing risks and keeping the CRM project on
track.
Work Breakdown Structure
• Break Down the Project: Divide the project into smaller, manageable
tasks.
• Identify Dependencies: Determine which tasks rely on others to be
completed first.
• Allocate Responsibilities: Assign tasks to specific teams or individuals.
4. Project Scheduling
With the work breakdown structure in place, RetailMax moved on to project scheduling to ensure timely
execution. The team estimated the duration of each task, considering resource availability and dependencies. A
Gantt chart was created to visualize the timeline, marking key milestones such as the completion of system
design, development phases, testing cycles, and final deployment.

Critical path analysis was conducted to identify tasks that directly impacted the project’s timeline.
Development and data migration were high-priority, as delays in these could push back testing and
deployment. To mitigate risks, buffer time was allocated for unexpected challenges, such as debugging issues
or integration setbacks.

Regular progress reviews were scheduled, with weekly check-ins to track milestones and adjust plans if
needed. Task dependencies were carefully managed to avoid bottlenecks, ensuring seamless handoffs between
teams. With a structured schedule in place, RetailMax ensured that the CRM project stayed on track, balancing
efficiency with flexibility for a smooth implementation.
Project Scheduling
• Estimate Time for Each Task: Use expert judgment, historical data, or estimation
techniques.

• Create a Gantt Chart: Visualize task timelines and dependencies.

• Identify the Critical Path: Determine the longest sequence of dependent tasks to
estimate project duration.

• Set Milestones: Define key project checkpoints.

5. Resource Planning
RetailMax moved forward with resource planning to ensure smooth execution. The project team identified key
personnel, including software developers, UI designers, data analysts, and IT support staff. Sales and marketing
representatives were also involved to provide feedback on functionality. External consultants were brought in
for specialized tasks such as data migration and system integration.

Each team member was assigned responsibilities based on expertise, ensuring balanced workloads. Hardware
and software requirements were assessed, with cloud infrastructure selected for scalability. Budget allocation
covered salaries, software licenses, training, and contingency funds for unexpected expenses.

To prevent resource shortages, overlapping tasks were carefully managed, ensuring that critical team members
were not overloaded. Regular check-ins helped track resource utilization and reallocate support when needed.
A well-planned resource strategy ensured that the right people and tools were in place to drive the CRM
project to successful completion.
Resource Planning
• Identify Required Resources: Determine the number of developers, testers, designers,
and tools needed.

• Allocate Team Members: Assign responsibilities based on skills and availability.

• Estimate Workload: Balance workloads to prevent overutilization.

6. Budget Estimation and Cost Estimation
RetailMax then shifted focus to budget and cost estimation to ensure financial control throughout the project.
The finance team worked closely with project managers to outline all potential costs, including software
development, cloud infrastructure, third-party integrations, training, and ongoing support. An initial budget of
$500,000 was approved, with provisions for unforeseen expenses.

The team estimated costs for each phase of the project, ensuring a balance between quality and cost-
efficiency. A detailed breakdown included development costs for both front-end and back-end tasks, expenses
for licensing and tools, and resources for testing and deployment.

To track progress and keep costs under control, the team implemented regular financial reviews, comparing
actual expenses to the budgeted amounts. If any phase exceeded its budget, adjustments were made in other
areas to maintain financial balance. This careful financial planning ensured that the CRM project stayed on
track while delivering the required features within the allocated budget.
Budget Estimation and Cost Estimation
• Estimate Costs: Personnel, tools, infrastructure, training, and contingency.

• Develop a Budget Plan: Align with organizational funding and cost constraints.

• Track Expenses: Use cost-tracking tools to monitor actual vs. estimated expenses.
7. Risk Management
RetailMax focused on risk management to address potential challenges that could impact the CRM project. The
team identified key risks early on, including technical issues such as data migration challenges, the possibility of
delays in third-party integrations, and potential resistance from employees adapting to the new system.

Each risk was assessed in terms of likelihood and impact. High-priority risks, like data loss during migration,
were given more attention, with a detailed contingency plan in place. For example, data backups and validation
checks were implemented to reduce the chances of errors.

Mitigation strategies were developed for each identified risk. The team planned for gradual, phased
implementation of the CRM to allow for quick troubleshooting and smooth adaptation by employees. Regular
risk assessments were scheduled to monitor any emerging issues and adapt plans accordingly. By proactively
managing risks, RetailMax ensured that potential setbacks were addressed before they could derail the project.
Risk Management
• Identify Risks: Determine potential risks (technical, financial, resource-related).

• Analyze Risk Impact: Assess the likelihood and severity of each risk.

• Develop Mitigation Strategies: Create action plans to prevent or minimize risks.

• Monitor Risks: Continuously track and reassess risks throughout the project.
8. Quality Assurance (QA) Planning
As the CRM project progressed, RetailMax focused on quality assurance to ensure the system met the required
standards. The team defined quality benchmarks, including performance, security, and usability. The IT
department established testing protocols to ensure that each feature worked as expected and met both
functional and non-functional requirements.

The testing phase was divided into multiple stages, starting with unit testing of individual components,
followed by integration testing to ensure the system worked as a whole. User acceptance testing (UAT) involved
employees from sales, marketing, and customer support to validate the system’s ease of use and functionality.

Security and data privacy were also a top priority, with regular security audits to identify vulnerabilities.
Performance testing was conducted to ensure that the CRM system could handle the expected load and scale
as needed. By thoroughly testing every aspect of the CRM, RetailMax ensured that the system would meet the
high standards necessary for successful deployment.
Quality Assurance (QA) Planning
• Define Quality Standards: Set software performance, security, and usability benchmarks.

• Develop Testing Plan: Plan for unit, integration, system, and user acceptance testing.

• Implement Review Processes: Conduct code reviews, peer reviews, and design
inspections.
9. Communication and Reporting
RetailMax turned its attention to communication and reporting to keep all stakeholders informed throughout
the CRM project. A communication plan was developed to outline how updates would be shared with internal
teams, management, and external consultants. Regular meetings were scheduled, including weekly project
status updates to track progress and address any concerns.

The project manager ensured that key milestones were clearly communicated, and issues were quickly
escalated when necessary. Communication tools like Slack and email were used for day-to-day interactions,
while more formal updates were provided through project management software.

To ensure transparency, project reports were generated regularly, detailing completed tasks, upcoming
milestones, and any potential risks or roadblocks. These reports were shared with senior leadership to provide
insight into the project’s progress. By maintaining clear and consistent communication, RetailMax kept
everyone aligned, which helped prevent misunderstandings and kept the project on schedule.
Communication and Reporting
• Create a Communication Plan: Define how updates will be shared with stakeholders.

• Schedule Regular Meetings: Set weekly or bi-weekly check-ins.

• Use Project Management Tools: Platforms like Jira, Trello, or Asana help track progress.

• Document Project Reports: Provide regular status reports to management.

10. Project Closure and Review
As the CRM project neared completion, RetailMax focused on project closure and review. The development
and testing phases were wrapped up, and the system was deployed in phases, ensuring smooth integration
with existing operations. Once the system was fully functional, the project team transitioned the CRM to the
maintenance phase, with ongoing support for bug fixes and updates.

A post-implementation review was conducted to assess the success of the project. The team evaluated
whether the CRM met the initial objectives, such as improving customer tracking, streamlining sales processes,
and increasing overall customer satisfaction.

Lessons learned were documented for future projects, including the importance of early stakeholder
involvement and the need for clear, ongoing communication. The final project reports were submitted, and the
team officially closed the project, releasing resources and acknowledging the hard work of everyone involved.
This structured closure ensured that RetailMax could transition smoothly into the CRM’s long-term use and
maintenance.
Project Closure and Review
• Deliver Final Software: Deploy and transition to the maintenance team.

• Conduct Post-Implementation Review: Evaluate project success and areas of

improvement.

• Document Lessons Learned: Record insights for future projects.

• Close Project: Officially hand over the project and release resources.
Software Project Estimation
• Estimation begins with a description of the scope of the problem. The problem is then decomposed into a
set of smaller problems, and each of these is estimated using historical data and experience as guides.

• Problem complexity and risk are considered before a final estimate is made.

• Estimating resources, cost, and schedule for a software engineering effort requires experience, access to
good historical information (metrics), and the courage to commit to quantitative predictions when
qualitative information exists.

• Software cost and effort estimation is not an exact science.

• Estimation carries inherent risk, and this risk leads to uncertainty.

Reasons for Estimation
• Strategic planning - Project portfolio management involves estimating the costs and
benefits of new applications in order to allocate priorities. Such estimates may also
influence the scale of development staff recruitment.
• Feasibility study - This confirms that the benefits of the potential system will justify the
costs
• System specification - Most system development methodologies usefully distinguish
between the definition of the users’ requirements and the design which shows how those
requirements are to be fulfilled. The effort needed to implement different design
proposals will need to be estimated. Estimates at the design stage will also confirm that
the feasibility study is still valid.
Problems with Over Estimates
• Parkinson’s Law ‘Work expands to fill the time available’, that is, given an easy target staff
will work less hard.

• Brooks’ Law The effort of implementing a project will go up disproportionately with the
number of staff assigned to the project. As the project team grows in size, so will the
effort that has to go into management, coordination and communication. This has given
rise, in extreme cases, to the notion of Brooks’Law: ‘putting more people on a late job
makes it later’. If there is an overestimate of the effort required, this could lead to more
staff being allocated than needed and managerial overheads being increased.
Problem with Under-Estimate
• The danger with the under-estimate is the effect on quality. Staff, particularly those with
less experience, could respond to pressing deadlines by producing work that is
substandard.
• This may be seen as a manifestation of Weinberg’s zeroth law of reliability: ‘if a system
does not have to be reliable, it can meet any other objective’.
• Substandard work might only become visible at the later, testing, phases of a project
which are particularly difficult to control and where extensive rework can easily delay
project completion
• To achieve reliable cost and effort estimates, the options available
are:
Decomposition Techniques
• Decomposition techniques decompose a project into major functions
and related software engineering activities, cost and effort estimation
can be performed in a stepwise fashion

• Popular Types of Decomposition Techniques are,

• Problem-based Estimation
• Process-based Estimation
Problem Based Estimation
• In problem based estimation, the scope is decomposed into problem
functions that can be estimated individually.

• Ex. User interface and control facilities, database management,

peripheral control function, etc.
Problem-based Estimation
• Using Lines of Code (LOC)
• The major software functions are identified
• A range of LOC estimates is developed.
• For eg. For the 3D geometric analysis function,
• Optimistic estimate is 4600 LOC
• The most likely estimate is 6900 LOC
• Pessimistic estimate is 8600 LOC
• Based on the 3 estimates, the expected value is calculated using the
following formula,
• Based on Historical Data,

• Average productivity of systems of this type is - 620 LOC/pm

• If the Labour rate is - $8000 per
month
• Cost per line of code is $13 approx. (i.e. $8000/620)
• Total Lines of code in the project is - 33,200
• The estimated effort is 54 person months approx. (33,200/620)
• and the total estimated project cost is $432,000 (54 * 8000)
Process Based Estimation
• Base the estimate on the process that will be used.
• The process is decomposed into a relatively small set of tasks and the
effort required to accomplish each task is estimated.
Effort is estimated in
person-months
• Estimated effort is 46 person-months

• Average labour rate is $8000 per month

• The total estimated project cost is $368,000 (i.e. 46 x $8000)

Empirical Estimation Models
• An estimation model for computer software uses empirically derived
formulae to predict effort as a function of LOC.
• The empirical data that supports the estimation model is derived
from a limited sample of projects.
• The empirical model should be calibrated to reflect local conditions.
• The model should be tested by applying data collected from
completed projects, plugging the data into the model, and then
comparing actual to predicted results.
• If agreement is poor, the model must be tuned and retested before it
can be used.
• For Example,

• Here A,B and C are constants.

• E is the effort in person-months
• ev is the estimation variable (for eg. LOC)
COCOMO II Model
• COnstructive COst MOdel is a popularly used software cost estimation
model.
• COCOMO model can use object points / function points / lines of
code.
• Object point is an indirect software measure that is computed using
counts of the number of
1. Screens (at the user interface)
2. Reports
3. Components likely to be required to build the application
 Effort=A×SizeB×EAF
A – Baseline productivity Constant
Size – Software size in KLOC
B – Exponent reflecting non-linear effects of size
EAF – Effort adjustment factors (based on cost drivers)
•A = 2.94
•Size = 50 KLOC
•B = 1.1 (exponent reflecting the effort's non-linearity)
•EAF = 1.15 (Effort Adjustment Factor based on cost drivers)

•Effort=A×SizeB×EAF
•A = 2.94
•Size = 50 KLOC
•B = 1.1 (exponent reflecting the effort's non-linearity)
•EAF = 1.15 (Effort Adjustment Factor based on cost drivers)

1.1
Effort=2.94×50 ×1.15 =209.69 person-months
Effort Multipliers (Cost Drivers)
• Product factors – required software reliability, database size,
complexity of the product
• Platform factors – execution time constraints, memory constraints,
platform volatility
• Personnel factors – Analyst capability, programmer experience,
development team cohesion
• Project factors – multisite development, development schedule
System Classification
• Organic mode - This would typically be the case when relatively small teams developed
software in a highly familiar in-house environment and when the system being developed
was small and the interface requirements were flexible.

• Embedded mode - This meant that the product being developed had to operate within
very tight constraints and changes to the system were very costly.

• Semi-detached mode - This combined elements of the organic and the embedded modes
or had characteristics that came between the two
COCOMO II Project Categories