Module-III

Monitoring and Control

Chapter-7
Lecture-29
Learning Objective:
7.1 Monitoring and Controlling
7.2 Why is the project monitoring and controlling phase important?
7.3 Visualizing progress in software project management
7.1 Monitoring and Controlling
● Monitoring and Controlling are processes needed to track, review, and regulate the progress and performance of the
project. It also identifies any areas where changes to the project management method are required and initiates the
required changes.
● Project monitoring and controlling process group of activities help to keep the project on track.
● Project monitoring and controlling, unlike the other phases, are done from the beginning until the end of the project.
These project monitoring and controlling process activities check whether the project is going as planned and
whether there are any deviations from the baseline.
7.2 Why is the project monitoring and controlling phase important?
For a successful project, there are some best practices to implement good project monitoring and controlling. Because
monitoring and controlling activities check if there are deviations from the expected results of the project.
7.3 Visualizing progress in software project management
Having collected data about project progress, a manager needs some way of presenting that data to greatest effect. Some
of these methods (such as Gantt charts) provide a static picture, a single snap-shot, whereas others (such as time-line
charts) try to show how the project has progressed and changed through time.

The Gantt chart

One of the simplest and oldest techniques for tracking project progress is the Gantt chart. This is essentially an activity
bar chart indicating scheduled activity dates and durations frequently augmented with activity floats. Reported progress is
recorded on the chart (normally by shading activity bars) and a 'today cursor' provides an immediate visual indication of
which activities are ahead or behind schedule. The below figure shows part of Amanda's Gantt chart as at the end of
Tuesday of week 17. Code & test module D has been completed ahead of schedule and code & test module A appears
also to be ahead of schedule. The coding and testing of the other two modules are behind schedule.

Fig. 7.1: Part of Amanda's Gantt chart with the 'today cursor' in week 17.
 The Slip chart
A slip chart is a very similar alternative favoured by some project managers who believe it provides a more striking visual
indication of those activities that are not progressing to schedule - the more the slip line bends, the greater the variation
from the plan. Additional slip lines are added at intervals and, as they build up, the project manager will gain an idea as to
whether the project is improving (subsequent slip lines bend less) or not. A slip chart is a version of the Gantt chart where
a line is drawn from top to bottom. To the left of the line are all the completed activities and to the right those activities (
or parts of activities) that have not been completed. A very jagged slip line indicates a need for rescheduling.

Fig. 7.2: The Slip chart emphasizes the relative position of each activity

The Ball chart

The way of showing whether or not targets have been met or not. It is represented in the form of circles that indicate the
start and the end point completion of activities. Circles of the ball chart mostly contain only two dates, start date &
completion date. Whenever revisions are made the revised date is put in to the circle.
Circles, which represent the start or finish of activities, start with the initial target dates. If these are modified then the
second dates are changed. When the event actually takes place, the colour of the circle is changed to green if it is on target
and to red if it has missed the target.
The idea is that this chart is put on a wall in a prominent position as a constant reminder to the project team of the current
situation – hence it is often referred to as ‘balls on the wall’.

Fig. 7.3: Example of Ball charts

The Timeline
The timeline is a method of recording and displaying the way in which targets have changed throughout the duration of
the project.
Planned time is plotted on the horizontal axis, and actual time on the vertical axis. The bendy lines going from top to
bottom represent the scheduled completion date for each activity e.g. ‘analyse existing system’ – at start this was due
finish on the Monday of week 3 and it did finish then ‘obtain user requirements’ was originally planned to finish on the
Thursday of week 5, but at the end of the first week it was rescheduled to finish on the Tuesday of week 6 and so on.

At the end of the first week Brigette reviews these target dates and leaves them as they are - lines are therefore drawn
vertically downwards from the target dates to the end of week one on the actual time axis.

At the end of week two, Brigette decides that obtain user requirements will not be completed until Tuesday of week six -
she therefore extends that activity line diagonally to reflect this. The other activity completion targets are also delayed
correspondingly.

By the Tuesday of week three, analyse existing system is completed and Brigette puts a blob on the diagonal timeline to
indicate that this has happened. At the end of week three she decides to keep to the existing targets.

At the end of week four she adds another three days to draft tender and issue tender.

Note that, by the end of week six, two activities have been completed and three are still unfinished. Up to this point she
has revised target dates on three occasions and the project as a whole is running seven days late.

The timeline chart is useful both during the execution of a project and as part of the post-implementation review. Analysis
of the timeline chart, and the reasons for the changes, can indicate failures in the estimation process or other errors that
might, with that knowledge, be avoided in future.

Fig. 7.4: Brigette 's timeline chart at the end of week six.
Module-III

Chapter-7
Lecture-30
Learning Objective:
7.4 Earned Value Analysis

7.4 Earned Value Analysis

 Earned Value Analysis (EVA) is one of the key tools and techniques used in Project Management, to have an
understanding of how the project is progressing.
 Both schedule and cost are calculated on the basis of EVA.
 EVA metrics are used to measure project health and project performance.
 Earned value integrates cost, schedule and scope and can be used to forecast future performance and project completion
dates. It allows projects to be managed better – on time, on budget.
 Three quantities form the basis for cost performance measurement using Earned Value Management. They are:
1. Budgeted Cost of Work Scheduled (BCWS) or Planned Value (PV)
2. Budgeted Cost of Work Performed (BCWP) or Earned Value (EV)
3. Actual Cost of Work Performed (ACWP) or Actual Cost (AC).

Planned Value (PV) – The approved cost baseline for the work package. It was earlier known as Budgeted Cost of Work
Scheduled (BCWS).
Earned Value (EV) – The budgeted value of the completed work packages. It used to be known as Budgeted Cost of
Work Performance at a specified point (BCWP).
Actual Cost (AC) – The actual cost incurred during the execution of work packages up to a specified point in time. It was
previously called Actual Cost of Work Performed (ACWP).

Features of EVA
 Earned Value Analysis is an objective method to measure project performance in terms of scope, time and
cost.
 EVA metrics are used to measure project health and project performance.
 Earned Value Analysis is a quantitative technique for assessing progress as the software project team moves
through the work tasks, allocated to the Project Schedule.
 EVA provides a common value scale for every project task.
 Total hours to complete the project are estimated and every task is given an Earned Value, based on its
estimated (%) of the total.
 Earned Value is a measure of ‘Progress’ to assess ‘Percentage of Completeness’

Baseline budget:
The first stage in setting up an earned value analysis is to create the baseline budget. The baseline budget is based on the
project plan and shows the forecast growth in earned value through time. Earned value may be measured in monetary
values but, in the case of staff-intensive projects such as software development, it is common to measure earned value in
person-hours or workdays.

Monitoring Earned Value:

Having created the baseline budget, the next task is to monitor named value as the project progresses. This is done by
monitoring the completion of tasks (or activity starts and milestone achievements in the case of other crediting
techniques).
The following performance statistics, which can be shown directly or derived from the earned value chart.
Schedule Variance (SV) – The difference between the work actually performed (BCWP) and the work scheduled
(BCWS). The schedule variance is calculated in terms of the difference in dollar value between the amount of work that
should have been completed in a given time period and the work actually completed.
Cost Variance (CV) – The difference between the planned cost of work performed (BCWP) and actual cost incurred for
the work (ACWP). This is the actual dollar value by which a project is either overrunning or under running its estimated
cost.
Time Variance(TV)-The difference between the time when the achievement of the current earned value was planned to
occur and the time now.
Module-III

Chapter-7
Lecture-31

Learning Objective:
7.5 Managing people and organizing teams

7.5 Managing people and organizing teams

The main objectives of managing people and organizing teams are
 Identify some of the factors that influence people’s behaviour in project.
 Select and induct new staff into a project.
 Increase staff motivation.
 Improve group working.
 Use the most appropriate leadership styles.

Team Organization/Team Structure

Team structure addresses the issue of organization of the individual project teams. There are some possible methods in
which the different project teams can be organized. There are primarily three formal team structures: chief programmer
Team, Democratic Team, and the mixed team organizations.
Chief Programmer Team
 In this team structure, a senior member provides the technical leadership and is designated as the chief programmer.
 The chief programmer is essential for all major technical decisions of the project.
 The chief programmer defines the specification and constructs the high level designs and then assigns the remaining
tasks coding, testing, documentation etc to the team members.
 He/She also verifies and integrates the work completed by different team members.

Fig. 7.5: Chief programmer team structure

Democratic Teams
 The democratic team structure does not enforce any formal team hierarchy.
 Decisions are taken based on discussions, where any member is free to discuss with any other member.
 Typically a manager provides the administrative leadership.
 At different times, different member of the team provide technical leadership.
 Democratic structure offers higher moral and job satisfaction to the team members. Consequently, a democratic team
usually suffers from lower manpower turnover compared to the chief programmer team.
 Though democratic teams are less productive compared to the chief programmer team for small and simple projects
 Democratic team structure is appropriate for less understood problems, since a group of developers can invent better
solutions than a single individual as in a chief programmer team.
 The democratic structure is suitable for research oriented projects requiring less than five or six developers.
 The democratic team organization encourages egoless programming as programmers can share and review one another’s
work.

Fig. 7.6: Democratic team structure

Mixed control team structure
 The mixed team structure draws idea from both the democratic and chief-programmer team structures.
 In below figure it shows that, communication paths are shown as dashed lines and the reporting structure is shown
using solid arrows.Observe that this team structure incorporates both hierarchical reporting and democratic setup.
 The democratic arrangement at the level of senior developers is used to decompose the problem into small parts.This
team structure is extremely popular and is being used in many software development companies.The mixed control
team organization is suitable for large team sizes.

Fig. 7.7: Mixed control team structure

Module-III

Chapter-7
Lecture-32

Learning Objective:
7.6 Organizational Structures
7.6.1 Functional format
7.6.2 Project Format
7.6.3 Matrix Format

7.6 Organizational Structures

Large software development companies are usually organized into departments. Departmentalization of a company may
be based on several criteria such as staff specialization, product lines, categories of customers, or geographical location.
For example, a certain company at a high-level may be divided into departments banking, embedded application, and
telecom software development. Such departments are also called verticals.

Each software package development organization handles many projects at any time. Software package organizations
assign totally different groups of engineers to handle different software projects.

There are three broad ways in which a software development department can be structured, functional, project and
matrix formats.
7.6.1 Functional format
 In the functional format, the developers are divided into functional groups based on their specialization or experience. In
other words, each functional group comprises developers having expertise in some specific task or functional area.
 For example, the different functional groups of an organization might specialize in areas such as database, networking,
requirements analysis, design, testing, and so on.
 Every developer in an organization would belong to some functional group depending on his/her specialization. For
carrying out specific activities, different projects borrow developers from the corresponding functional groups. Upon the
completion of their activities, the developers are returned to their respective functional groups.
 The partially completed product passes from one team to another and evolves due to the work done on if by several
teams.
 A functional team working on a project does not physically meet the members of other functional teams who have
carried out other parts of the project. Consequently, a team understands the work carried out by the other functional
teams solely by studying the documents produced by them. Unless good quality documents are produced by each team,
team working subsequently on the project will find it hard to understand the work already completed. We can therefore
say that a functional organization mandates production of good quality documentation.

Fig. 7.8: Functional Organization

7.6.2 Project Format
 The project format is designed for realizing task-oriented teams.
 In the project format, at the start of every project, a set of developers are assigned to it .It is assumed that, among
them the assigned members can carry out various activities required for project completion.
  The developers remain with the project till the completion of the project. Thus, the same team carries out all the
project activities.
 This is in contrast to a functional organization, where each developer belongs to a functional group for completing
a project activity, members of the corresponding functional area are assigned to the project temporarily, who are
returned back to their respective functional area after completion of the activity.

Fig. 7.9: Project Organization

7.6.3 Matrix Format

 Matrix format is an extension of a functional format, and is intended to provide the advantages of both the
functional and project structures.
 In a matrix organization, the pool of functional specialists is assigned to different projects as needed.
 Thus, deployment of the different functional specialists in different projects can be represented in a matrix.
 Observe that a member assigned to a project reports to both the manager of his functional group as well as the
manager of the project to which he has been assigned. Thus, in a matrix organization, the project manager needs to
share the project responsibility with a number of individual functional managers.
 Matrix organizations can be characterized as weak or strong, depending upon the relative authority of the
functional managers and the project managers.
 In a strong functional matrix, the functional managers have authority to assign workers to projects and project
managers have to accept the assigned personnel.
 In a weak matrix, the project manager completely controls the project budget, can reject workers from functional
groups, and can even decide to hire outside workers.
 Though a matrix team organization offers several advantages, two important problems that such an organization
may suffer from are the following.
Due to the multiplicity of authority, conflicts can occur between functional and project managers over
allocation of workers.
In a strong matrix organization, frequent shifting of workers may take place as the functional managers
adopt a fire fighting mode to tackle the crises in different projects.

Fig. 7.10: Matrix Organization

Module-III

Chapter-7
Lecture-33

Learning Objective:
7.7 Case Studies

7.7 Case Studies

Agile methodology — Zomato Case study
Waterfall Methodology:
A software methodology that needs to know all requirements up-front and also requires design documents months before any
coding begins may seem suspect these days. But in the 70s and 80s, when the main source of money to be made in software
was in the civil engineering, defence and aerospace industries, the planning was everything.

Waterfall method was based on the fact that stakeholder sign-off for a requirement or design document meant that the
stakeholder would see a software system sometime later that accurately reflected all of those plans.

Inception of Agile Methodology:

Waterfall projects began to fail due to an imbalance between a well-intentioned methodology and the typical outcome for
large-scale software projects.
Agile was developed as a solution for the shortcomings of the waterfall model. This method combines iterative and
incremental approaches and encourages a flexible environment.
Iterative development: An iterative process is one that makes progress through successive refinement. Since customer
requirements are not clear, every iteration incorporates feedback at multiple levels in the product development process.
Incremental development: An incremental process is one in which software is built and delivered in a staggered approach.
Each piece, or increment, represents a complete subset of functionality. Each increment is fully coded and tested and it is
potentially shippable.

Fig. 7.11: Iterative and Incremental development model

The Manifesto for Agile Software Development

The manifesto proclaimed that they value
 Individuals and interactions over processes and tools
 Working Software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to Change over following a plan
This Agile Manifesto — led to a fundamental change in how software is developed and projects are managed.
76% of users choosing an enterprise Agile planning tool do so to increase their projects’ visibility. Statistics show that
in the past 10 years, there has been tremendous growth in adopting Agile projects. Major growth in Agile began to
step up since 2009.
 Fig. 7.12: Growth of Agile Projects

About the Company — Zomato:

Zomato is a restaurant search and food ordering application. It operates in 24 countries, including India, Australia, and the
US. The vision of the product is to provide better food for more people. They not only connect people to food in every context
but work closely with restaurants to enable a sustainable ecosystem.
Implementation of Agile Methodology at Zomato:
We’ll be taking a deeper dive into how a PM at Zomato uses an incremental and iterative approach to develop the features.
One of the Agile methodologies, the Scrum Framework could be followed.
Scrum
This is a lightweight framework employed in the development of complex products since the early 1990s.
The Scrum framework is characterized by overlapping phases, i.e., you work on one feature at a time and conduct all the
phases of development such as analysis, design, implementation, and testing and then product a potentially shippable product
increment.
Scrum Team:
The scrum team consists of three players:
 Product Owner: Creates product backlog, prioritizes the backlog and is responsible for the delivery of the functionality at
each iteration. Major decision power lies with the Product Owner and he/she looks forward to maximize the ROI.
 Scrum Master: Responsible for facilitating and coaching the team. Organizes Scrum events like daily stand-ups, Sprint
reviews and retrospectives. During the Sprint, Scrum Master is responsible for removing any impediments.
 Development Team: This is self-organizing team and manages its own work and organizes the work to complete the sprint
or cycle
These three roles together constitute the Scrum Team.

Fig. 7.13: Scrum Team

In “Scrum”, the development is done in sprints and each feature is broken down into “Epics” which are further broken down
into “User Stories”.
A Typical Scrum:
1. Team Size: The scrum team would comprise of 5 to 9 members
2. Sprint duration: 2 to 4 weeks
3. Spring backlog: Contains user stories that are taken from the Product Backlog order of priority.
These are further divided into tasks.
Let us look at a scenario where a Product Manager at Zomato is asked to build the following features.
Feature list —
1. Order Food Online
2. Add Search Filters
3. Rate/Review Restaurant
Each feature goes through the following phases:
1. Ideation
2. Design
3. Implementation
4. Testing
5. Deployment
Let’s see how it is implemented at Zomato for the feature list taken.

Feature 1: Order Food Online:

Users can choose the location and search for restaurants, add items to cart and then go ahead to order food.
Ideation: The users should be able to search for a location and/or restaurants. Search results should list the restaurants within
a radius of the location where delivery is feasible. Users should be able to select a restaurant, view its details like location,
price for two, cuisine, etc.
Users should be able to choose the menu, add items from the menu to the cart, select quantity, add delivery details and select
the payment options. They should be able to review the order before placing an order. After placing the order, they should
receive a confirmation via SMS/email and also, they could track the status of their order with an estimated delivery time. In
case of any hassles, customer support can be reached out for.
Design: The design team gives the paper sketches for the screens to be designed. Wireframes and prototypes are created once
the feature list is frozen
The screens below could be proposed initially.
1. Search the location and/or a restaurant
2. List of restaurants with basic details like photo, cuisine, price
3. Detailed view of restaurant with Menu, price, location, any offers, ratings, etc.
4. Adding/Updating/Deleting items to and from the cart
5. Select or add a new delivery address
6. Review order
7. Placing an order
8. Payment page
9. Track status of the order
10.Enabling customer support chat/phone number
Implementation & Testing: Once the design is finalized, developers will build the features related to various screens and
QA team will go ahead with testing.
Deployment: Post testing, the product is deployed to the customer.
Multiple features can be added in subsequent iterations. These are
1. Payment options: Introducing multiple payments options
2. Saving customers address details
3. Notify customers about status of order
4. Taking customer ratings and feedback after an order is placed
5. Tracking the order, see the ETA and contact of the delivery person
6. Offers and discounts
Feature 2: Add a Search Filter
Users should be able to search restaurants by location and different other filters.

Ideation: By adding more filters, a customer can only view restaurants that are relevant to them. Filters could be of the
following.
Since all the features cannot be released in one sprint, 1. Filter by location 2. Filter by restaurant cuisine in the initial phase.
Design: Design must be simple and precise. Filter by location will contain a checkbox and filter by restaurant cuisine could
be a drop-down of multi-selectable options like North Indian, Italian, etc. After selecting the cuisine, the customer is
redirected to a page that shows relevant restaurants.
These options can be below the search on the page. Upon selection, the filter should slightly move upward making room for
the display of restaurants.
Design team build screens for filter by location and filter by cuisine
Implementation and testing: Developers build functionality and testers conduct testing.
Deployment: The feature is deployed and user experience is analysed by tracking some events and taking feedback.
In subsequent iterations, the following filters can be added to various releases.
1. Filter by place within a location — ex: Saket in Delhi (part of a bigger location)
2. Filter by cuisine
3. Filter by restaurants ratings
4. Filter by price
5. Filter by popularity
6. Filter by coupons applicable
7. Filter by restaurant offers
8. Filter by delivery times, etc.

Feature 3: Rate and Review Restaurants:

Allows users to rate and review restaurants.
Ideation: Users should be able to rate the restaurant and write a review after the order has been delivered. Customer
satisfaction feedback should be sent via e-mail or as an SMS notification. The goal is to get feedback on the quality of food
and service and even how prompt the delivery was — was it as expected or delayed, etc.
Ratings should be shown restaurant’s detail page. When a user clicks on review, the top 10 customer reviews should be
shown. Customer should be able to change the ratings and update/delete the review that they wrote.
Design: The design team build screens for ratings and reviews. Ratings will be in the format of stars ranging from 1 to 5
5-Excellent 4 -Good, 3- Satisfactory, 2-Bad and 1-Worst
The review box is a blank text area where the user can type some comments.
Implementation & Testing: Developers build functionality and testing is conducted to check if there are any errors for
ratings and review screens
Deployment: Once all the functionality is tested the product will be deployed and the customer will be asked to rate/review
and give feedback.
More features that can be implemented in subsequent iterations are
1. Allowing users to add/upload their own photos at the restaurant
2. Sharing ratings and reviews on social media
3. Chat option to have a conversation with restaurant authorities to directly communicate any issues.

Summary: Agile methodology ensures great product quality, higher customer satisfaction, increased ROI. As all the phases
are done during the same iteration, there are regular feedbacks, which can be incorporated into the subsequent increments.
Most importantly, every iteration has an increment developed that is potentially shippable which means it is fully functional.
This gives the customer as to where the product status is and what exactly is the progress. Each of these increments is produced
in a staggered manner. Agile methodologies help product managers to improve their products continuously.
Module-III

Chapter-7
Lecture-34

Learning Objective:
7.8 Agile Development
7.8.1 What is Agile?
7.8.2 Why Agile?
7.8.3 Principle of Agile Development

7.8.1 What is Agile?

→ Agile is an iterative approach to project management and software development that helps teams deliver value to their
customers faster and with fewer headaches.
→That builds software incrementally from the start of the project, instead of trying to deliver all at once.
7.8.2 Why Agile?
 The conventional software models such as Waterfall Model that depends on completely specifying the requirements,
designing, and testing the system are not geared towards rapid software development. As a consequence, a
conventional software development model fails to deliver the required product.
 This is where agile software development comes to the rescue. It was specially designed to curate the needs of the
rapidly changing environment by embracing the idea of incremental development and developing the actual final
product.
7.8.3 Principle of Agile Development
1. Highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shortest
timescale.
4. During the project, business people and developers must collaborate on a daily basis.
5. Build projects around motivated individuals. Give them the environment and the support they need, and trust them to
get the job done.
6. Working software is the primary measure of progress.
7. Simplicity the art of maximizing the amount of work not done is essential.
8. The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
9. Agile approaches encourage long-term development; therefore, developers and clients should be able to keep working
on projects forever.
10. A constant focus on technical excellence and smart design improve agility.
11. Self-organizing teams provide the finest architectures, requirements, and designs.
12. Teams think about how to become more successful at regular intervals and alter their behaviour appropriately.
Factors Affecting Humans
Members of agile development teams must possess the following characteristics −
 Competence
 a common goal
 Collaboration
 Ability to make decisions
 Ability to solve ambiguous problems
 Mutual respect and trust
 Self-organization
Models of Agile Processes
 Scrum
 Crystal
 Dynamic Software Development Method (DSDM)
 Feature Driven Development (FDD)
 Lean Software Development
 eXtreme Programming (XP)
 MODULE QUESTION & ANSWERS (Module-III)
(Seven Semester)
Subject: -SPM

Short Questions
1. What is the purpose of project monitoring and control?
Ans: The purpose of project monitoring and control is to ‘keep the team and management up to date on the project’s
progress.
2. What is a Milestone?
Ans: A Milestone is a symbol that marks a point in time where something will be produced or when an event
will occur during a project lifecycle.
3. What is Agile?
Ans:
→ Agile is an iterative approach to project management and software development that helps teams deliver value to their
customers faster and with fewer headaches.
→That builds software incrementally from the start of the project, instead of trying to deliver all at once.
4. Which type of charts are used for visualizing progress in software project management?
Ans: Gantt chart, Slip chart, Ball chart and the time line chart.
5. What is earned value in software project management?
Ans: Earned value (EV) is a way to measure and monitor the level of work completed on a project against the plan.

Long Questions

1. Explain Earned value analysis.

2. Explain about different team structure.
3. Describe different types of organizational structures.