SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4

Module 4 - Introduction to Project Management

All projects are about meeting objectives. Like any other project, a software project must satisfy real
needs. To do this we must identify the project's stakeholders and their objectives. Ensuring that their
objectives are met is the aim of project management. However, we cannot know that a project will meet
its objectives in the future unless we know the present state of the project.

Why is software project management important?

Firstly, there is the question of money. A lot of money is at stake with Information and Communications
Technology (ICT) projects. Mismanagement of ICT projects means there is lessto spend on good things
such as hospitals. Unfortunately, projects are not always successful. The reasons for shortcomings are
often the management of projects. The National Audit office in the UK, for example, among other factors
causing project failure identified 'lack of skills and proven approach to project management and risk
management’.

What is a Project?
The dictionary definitions put a clear emphasis on the project being a planned activity. The definitions
include: 'A specific plan or design’, ‘A planned undertaking’, ‘A large undertakíng: e.g., a public works
scheme’, Longman Concise English Dictionary, 1982.

The emphasis on being planned assumes we can determine how to carry out a task before we start.
Planning, is in essence, thinking carefully about something before you do it - even with uncertain projects,
this is worth doing as long as the resulting plans are seen as provisional. Other activities, such as routine
maintenance, will have been performed so many times, that everyone knows exactly what to do

Programme management is often used to coordinate activities on concurrent jobs. The activities that
benefit most from conventional project management are likely to lie between these two extremes - see
Figure 1.1.

Dept. of CS&E, BIT Page 1

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
There is a hazy boundary between the non-routine project and the routine job. The first time you do a
routine task, it will be like a project. On the other hand, a project to develop a system similar to previous
ones that you have developed will have a large element of the routine.

The following characteristics distinguish projects:

 non-routine tasks are involved;

 planning is required;

 specific objectives are to be met or a specified product is to be created;

 the project has a predetermined time span;

 work is carried out for someone other than yourself;

 work involves several specialisms;

 people are formed into a temporary work group to carry out the task;

 work is carried out in several phases;

 the resources that are available for use on the project are constrained;

 the project is large or complex.

The more any of these factors apply to a task, the more difficult that task will be.

Project size is particularly important. The project that employs 20 developers is likely to be
disproportionately more difficult than one with only 10 staff because of the need for additional
coordination.
Some argue that projects are especially problematic as they are temporary sub-organizations. A group of
people is brought together to carry out a task. The existence of this sub-organization cuts across the
authority of the existing units within the organization. This has the advantage that a group containing
various specialists is focused on a single important task. However, the project is likely to be seen as
disruptive to others. Also, expertise built up during the project may be lost when the team is eventually
dispersed at the end of the project.

Software Projects versus other Types of Projects

Many techniques in general project management also apply to software project management, but Fred
Brooks identified some characteristics of software projects which make them particularly difficult:

Dept. of CS&E, BIT Page 2

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
 Invisibility: When a physical artefact such as a bridge is constructed, the progress can actually be
seen. With software, progress is not immediately visible. Software project management can be
seen as the process of making the invisible visible.

 Complexity: Per Dollar, Pound or Euro spent, software products contain more complexity than
other engineered artifacts.

 Conformity: The 'traditional' engineer usually works with physical systems and materials like
cement and steel. These physical systems have complexity, but are governed by consistent physical
laws. Software developers have to conform to the requirements of human clients. lt is not just that.
Individuals can be inconsistent. Organizations, because of lapses in collective memory in internal
communication or in effective decision making, can exhibit remarkable 'organizational stupidity'.
 Flexibility: That software is easy to change is seen as a strength. However, where the software
system interfaces with a physical or organizational system, it is expected that the software will
change to accommodate the other components rather than vice versa. Thus software systems are
particularly subject to change.

Contract Management and Technical Project Management

In-house projects are where the users and the developers of new software work for the same
organization. However, increasingly, organizations contract out ICT development to outside developers.

Here, the client organization will often appoint a 'project manager' to supervise the contract who will
delegate many technically oriented decisions to the contractors. Thus, the project manager will not worry
about estimating the effort needed to write individual software components as longas the overall project is
within budget and on time. On the supplier side, there will need to be project managers who deal with the
more technical issues. This book leans towards the concerns of these 'technical' project managers.

Activities covered by software project management

Feasibility study, planning of project and execution of it brings in new system into being. Feasibility
study:
 Assess if a project is worth starting, validate the business case for the project.
 Information is gathered about the requirements of the proposed application.
 Requirements elicitation can be complex and difficult initially since, stakeholders may know

Dept. of CS&E, BIT Page 3

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
their aims but not be sure about the means of achievement.

Dept. of CS&E, BIT Page 4

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
 Developmental and operational costs need to be estimated. The value of the benefits of the new
system also needs to be estimated.

Planning:
 If feasibility study shows this project is good enough to be executed(viable) then planning is
begun.
 We create an outline plan(how to do) for the whole project and a detailed one for the first stage.
Because we will have more detailed and accurate project information approach to after the earlier
stages of the project have been completed, planning of the later stages is left to nearer their start.

Project execution:
 The execution of a project often contains design and implementation sub-phases.
 Design is making decisions about the form of the products to be created. This could relate to the
external appearance of the software, that is, the user interface, or the internal architecture. The
plan details the activities to be carried out to create these products.

Dept. of CS&E, BIT Page 5

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4

Typical sequence of software development:

 Requirements analysis begins with gathering information from potential users and their
managers to understand what they need from the new system. This can include functionalrequirements,
which define what the system should do, and quality requirements, which describe how well it should
perform. For example, in an ambulance dispatch system, the transaction time depends on hardware and
software performance as well as the operators' speed.
Training for operators to use the system efficiently is a system requirement, while development costs are
resource requirements.
 Architecture designs: The components of the new system that fulfil each requirement have to
be identified. Existing components may be able to satisfy some requirements, in other cases a new
component will have to be made. These components are not only software: they could be new hardware
or work processes. The design of the system architecture is thus an input to the software requirements. A
second architecture design process then takes place that maps the software requirements to software
components.
 Detailed design: Each software component is made up of a number of software units thatcan be
separately coded and tested. The detailed design of these units is carried out separately.
 Code and test: refers to writing code for each software unit. Initial testing to debug individual
software units would be carried out at this stage.

Dept. of CS&E, BIT Page 6

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
 Integration: The components are tested together to see if they meet the overall requirements. It
may involve combining different software components, or combining and testing the software element of
the system in conjunction with the hardware platforms and user interactions.
 Qualification testing: The system, including the software components, has to be tested carefully
to ensure that all the requirements have been met.
 Installation: Making software operational. It would include activities such as setting up standing
data (details of employees), setting system parameters, installing the software on to the hardware platforms
and user training.
 Acceptance support: Resolving of problems of newly installed system, including the correction
of any errors, and implementing agreed extensions and improvements. Software maintenance can be seen
as a series of minor software projects.

Plans, method, methodologies:

Plan
A plan for an activity must be based on some idea of a method of work. So converting methods into real
activities for a project execution is called planning.
Example: If you were asked to test some software, you may know nothing about the software to be tested,
but you can assume that you would need to do certain activities such as
 analyze the requirements for the software
 devise and write test cases that will check that each requirement that has been satisfied
 create test scripts and expected results for each test case
 Compare the actual results and the expected results and identify discrepancies.

Method and Methodologies

A method relates to a type of activity in general, a plan takes that method and converts it to real activities
Key elements of methods:
 Start and end dates: Define when each activity begins and ends.
 Who will carry it out: Identify who will carry out each activity.
 What tools and materials: Determine the necessary tools, materials, and also information required.
Output of one method might be input for another. Groups of methods or techniques are called
methodologies.

Some ways of categorizing software projects

Projects may differ because of the different technical products to be created. Thus we need to identify the

Dept. of CS&E, BIT Page 7

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
characteristics of a project which could affect the way in which it should be planned and managed. Other
factors are discussed below.

Changes to the characteristics of software projects

Over the past few decades, software projects have evolved significantly. Initially, most software was
created entirely from scratch due to limited availability of reusable code and inadequate support for code
reuse in programming paradigms of the time. Now, nearly every programming language facilitates code
reuse through various mechanisms, including dynamic linking and frameworks.
Today, many projects involve customizing existing software or developing new versions, relying
heavily on reused code. Project durations have shortened to just months, compared to the multi- year
projects of the past. Customer involvement has also evolved; now, customers actively participate
throughout the project, often being integrated into development teams.

Compulsory versus voluntary users

In workplaces, there are systems that staff have to use if they want to do something, such as recording a
sale. However, use of a system is increasingly voluntary, as in the case of computer games. Here it is
difficult to elicit precise requirements from potential users as we could with a business system. What the
game will do will thus depend much on the informed ingenuity of the developers, along with techniques
such as market surveys, focus groups and prototype evaluation.

Information systems versus embedded systems

A traditional distinction has been between information systems which enable staff to carry out office
processes and embedded systems which control machines. A stock control system would bean information
system. An embedded, or process control, system might control the air conditioning equipment in a
building. Some systems may have elements of both where, for example, the stock control system also
controls an automated warehouse.

Software products versus services

All types of software projects can broadly be classified into software product development projects and
software services projects. These two broad classes of software projects can be further classified into
subclasses, as shown in Figure 1.4.

Dept. of CS&E, BIT Page 8

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4

 A software product development project concerns developing the software by keeping the
requirements of the general customers in mind and the developed software is usually sold off- the-
shelf to a large number of customers.
 A software product development project can further be classified depending on whether it
concerns developing a generic product or a domain-specific product.

a. A generic software product is sold to a broad spectrum of customers and is said to have a
horizontal market. Examples Microsoft's Windows OS Oracle Corporation's Oracle Si
database management software.

b. On the other hand, domain-specific software products are sold to specific categories of
customers and are said to have a vertical market. Domain-specific software products target
specific segments of customers (called verticals), such as, banking, telecommunication,
finance and accounts and medical.

Examples : BANCS from TCS (banking domain) FINACLE from Infosys (banking
domain)
AspenPlus from Aspen Corporation (chemical process simulation).

 Software services on the other hand, cover a large gamut of software projects such as
customization. outsourcing, maintenance, testing and consultancy.

 At present, there is a rapid growth in the number of software services projects that are being
undertaken world-wide and software services are poised to become the dominant type of software
projects.

Dept. of CS&E, BIT Page 9

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
 Reasons:

1. Steep growth in available code base.

2. Many programs have already been developed and can be modified for specific customer needs.

3. Most projects now involve customizing existing software rather than writing code from scratch.

 Example: Customizing existing payroll software for an educational institute based on a previously
developed program.

 Due to heavy reuse of code, it has now become possible to develop even large software systemsin
rather short period of time. Therefore, typical project durations are at present only a couple of
months and multi-year projects have become very rare.

Outsourced projects
While developing a large project, sometimes, it makes good commercial sense for a company to
outsource some parts of its work to other companies. There can be several reasons behind such a
decision. For example. a company may consider outsourcing as a good option, if it feels that it does not
have sufficient expertise to develop some specific parts of the product or if it determines that some parts
can be developed cost-effectively by another company. Since an outsourced project is a small part of some
project, it is usually small in size and needs to be completed within a few months. Considering these
differences between an outsourced project and a conventional project, managing an outsourced project
entails special challenges. Indian software companies excel in executing outsourced software projects and
have earned a fine reputation in this field all over the world. of late, the Indian companies have slowly
begun to focus on product development as well.The type of development work a company handles impacts
its profitability. A company developinga generic software product typically enjoys an uninterrupted stream
of revenue over several years,whereas outsourced projects provide only one-time revenue.

Objective-driven development
Projects can be distinguished by their aim: producing a product or meeting certain objectives. A project
might create a specified product, with the client justifying the product. Alternatively, a project might aim
to meet objectives that can be achieved in various ways, such as solving a problem with a specialist's
recommendation.
Many software projects have two stages:
1. An objective-driven project resulting in recommendations, possibly identifying the need for a new
software system.
2. A project to create the software product, useful when technical work is done by an external group and

Dept. of CS&E, BIT Page

10
SOFTWARE ENGINEERING & PROJECT MANAGEMENT (21CS61) Module-4
user needs are unclear. The external group produces a preliminary design for a fixed fee. If acceptable,
developers quote a price for the implementation stage based on agreed requirements.

Stakeholders
These are people who have a stake or interest in the project. Their early identification is importantas you
need to set up adequate communication channels with them. Stakeholders can be categorized as:

➢ Internal to the project team: This means that they will be under the direct managerial control of
the project leader.

➢ External to the project team but within the same organization: For example, the project leader
might need the assistance of the users to carry out systems testing. Here the commitment of the
people involved must be negotiated.

➢ External to both the project team and the organization: External stakeholders may be customers
(or users) who will benefit from the system that the project implements. They may be contractors
who will carry out work for the project. The relationship here is usuallybased on a contract.

Different types of stakeholders may have different objectives and one of the jobs of the project leader is
to recognize these different interests and to be able to reconcile them. For example, end- users may be
concerned with the ease of use of the new application, while their managers may bemore focused on staff
savings.
The project leader therefore needs to be a good communicator and negotiator. Boehm and Ross
proposed a "Theory W" of software project management where the manager concentrates on creating
situations where all parties benefit from a project and therefore have an interest in its success. (The ‘W’
stands for 'win-win'.)
Project managers can sometimes miss an important stakeholder group, especially in unfamiliar business
contexts. These could be departments supplying important services that are taken for granted.
Given the importance of coordinating the efforts of stakeholders, the recommended practice is for a
communication plan to be created at the start of a project.

Setting Objectives
The owners of the project, who have control over its funding, are the ones who set the project objectives.
The objectives clarify what the project team must accomplish to consider the project successful. Even
though different stakeholders may have various motivations, project objectives identify the common
goals for the project.

Dept. of CS&E, BIT Page 10

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
Project objectives focus on the anticipated outcomes rather than the tasks involved and could be
informally stated as statements following 'the project will be deemed successful if... '. A single objective
might be 'enabling online orders for our products' rather than 'developing an e-commercesite.'

In cases where there are several stakeholders with potential ownership claims, a project authority with
overall project command must be explicitly identified. This authority is usually a project steering
committee, or project board or project management board, responsible for setting, monitoring and
adjusting the objectives. The project manager manages the project day-to-day andregularly reports to the
steering committee.

Sub-objectives and Goals

Effective individual objectives must be controllable by that individual. An objective that the resulting
software application pay for itself via reduced staff costs may be a valid overall businessobjective, but not
for software developers as the cost reduction is contingent upon the management of the operational system.
A more suitable goal for software developers would be keeping the development costs within a certain
budget.
Often, achieving an objective requires meeting certain sub-goals or sub-objectives first. These are steps
towards achieving the main objective, similar to scoring goals in a football game being steps towards the
ultimate objective of winning the match.

SMART (Specific, Measurable, Achievable, Relevant, and Time-constrained) is a commonly use dacronym
for defining clear objectives. It means that objectives should be unequivocal, quantifiable, attainable,
pertinent to the project, and time bound.

Measures of Effectiveness
Measures of effectiveness offer practical methods to confirm that an objective has been met. For instance,
'mean time between failures' (mtbf) can measure the system's reliability. During the system's
development, predictive measures may be employed. For instance, a large number of errors noted during
code inspections might indicate possible reliability issues in the future.

The Business Case

Most projects require a justification or business case, with the project's costs and benefits often itemized
and quantified in a cost-benefit analysis as part of the feasibility study. The benefits are tied to the
project's completion date - the sooner it finishes, the sooner benefits can be reaped.

Dept. of CS&E, BIT Page 11

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
Creating the business case often involves formulating a business model to validate how the new
application can deliver the benefits claimed. As an example, a new web-based application might boost
sales by allowing global customers to order a company's products online.

The project plan should preserve the business case. For instance, it should prevent development costs
from surpassing the worth of the benefits, keep the system features at a level that will deliver expected
benefits, and avoid delays in the delivery date that may result in significant loss of benefits.

Project Success and Failure

The project plan should ensure success by preserving the project's business case. However, every non-
trivial project will encounter problems. Determining when a project is a failure can be challenging, as
different stakeholders have different interests. As a result, some stakeholders might view a project as a
success while others do not.
Broadly speaking, we can distinguish between project objectives and business objectives.

The project objectives are the targets that the project team is expected to achieve. In the case of software
projects, they can usually be summarized as delivering:
• The agreed functionality
• The required level of quality
• On time
• Within budget
In business terms, a project is deemed successful if the value of its benefits exceeds its costs. Project
managers can influence development costs, but the value of benefits is often tied to external factors like
customer uptake. Project objectives play a crucial role in determining business success. Delays in project
completion can reduce the time available to realize benefits, thereby diminishing the project's overall value.
➢ A project can succeed on delivery but fail as a business if benefits do not outweigh costs.
➢ Conversely, a project that exceeds budget and timeline may still yield long-term benefits that
justify initial expenses.
➢ Bridging the gap between project and business success requires a broader view integrating
business considerations.
➢ Project management for complex projects like e-commerce websites should include activities such
as market surveys, competitor analysis, and user evaluation to mitigate business risks.
➢ Project management often focuses on immediate outcomes, potentially overlooking its role in a
larger sequence of projects.
➢ Skills acquired from previous projects enhance technical efficiency in subsequent projects,

Dept. of CS&E, BIT Page 12

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
➢ Despite initial higher costs for learning.
➢ Expertise gained includes reusable software assets like code libraries, contributing to long-term
efficiency and cost-effectiveness.
➢ Outsourcing software development may save costs initially but can reduce long-term benefits
associated with in-house expertise.
➢ Building customer relationships across projects enhances business continuity, as satisfied
clients are more likely to return for future projects.
➢ Retaining existing clients is generally more economical than acquiring new ones, reinforcing the
importance of client trust and satisfaction.

Traditional vs Modern project management practices

Planning Incremental Delivery: Few decades ago, projects were much simpler and therefore more
predictable than the present day projects. In those days, projects were planned with sufficient detail, much
before the actual project execution started. After the project initiation, monitoring and control activities
were carried out to ensure that the project execution proceeded as per plan. Now, projects are required to
be completed over a much shorter duration, and rapid application development and deployment are
considered key strategies. The traditional long-term planning has given way to adaptive short-term planning.
Instead of making a long-term project completion plan, the project manager now plans all incremental
deliveries with evolving functionalities. This type of project management is often called extreme project
management. Extreme project management is a highly flexible approach to project management that
concentrates on the human side of project management (eg; managing project stakeholders), rather than
formal and complex planning and monitoring techniques.

Quality Management: Of late, customer awareness about product quality has increased significantly.
Tasks associated with quality management have become an important responsibility of the project
manager. The key responsibilities of a project manager now include assessment of project progress and
tracking the quality of all intermediate artifacts.

Change Management: Earlier, when the requirements were signed off by the customer, any changes to
the requirements were rarely entertained. Customer suggestions are now actively being solicited and
incorporated throughout the development process. To facilitate customer feedback, incremental delivery
models are popularly being used. Product development is being carried out through a series of product
versions implementing increasingly greater functionalities. Also customer feedback is solicited on each
version for incorporation. This has made it necessary for an organization to keep track of the various
versions and revisions through which the product develops. The Project manager plays a key role in

Dept. of CS&E, BIT Page 13

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
product base lining and version control. This has made change management a crucial responsibility of the
project manager. Change Management is also known as configuration management.

Requirements Management: In modern software development practices, there is a conscious effort to

develop software such that it would, to a large extent, meet the actual requirements of the customer. A
basic premise of these modern development methodologies is that at the start of a project the customers
are often unable to fully visualize their exact needs and are only able to determine their actual
requirements after they start using the software. From this view point, modern software development
practices advocate delivery of software in increments as and when the increments are completed by the
development team, and actively soliciting change requests from the customer as they use the increments
of the software delivered to them. In fact, a few customer representatives are included in the development
team to foster close every day interactions with the customers. Contrast this with the practice followed in
older development methodologies, where the requirements had to be identified upfront and these were
then 'signed off by the customer and 'frozen' before the development could start. Change requests from
the customer after the start of the project were discouraged. Consequently, at present in most projects, the
requirements change frequently during the development cycle. It has, therefore, become necessary to
properly manage the requirements, so that as and when there is any change in requirements, the latest and
up-to-date requirements become available to all. Requirements management has therefore become a
systematic process of controlling changes, documenting, analysing, tracing, prioritizing requirements and
then communicating the changes to the relevant stakeholders. By the term controlling changes, we mean
that every change request is well managed, and problems such as accidental overwriting of a newer
document with an older document are avoided.

Release Management: Release management concerns planning, prioritizing and controlling the different
releases of a software. For almost every software, multiple releases are made during its life cycle.
Starting with an initial release, releases are made each time the code changes. There areseveral reasons as
to why the code needs to change. These reasons include functionality enhancements, bug fixes and
improved execution speed. Further, modern development processes such as the agile development
processes advocate frequent and regular releases of the software to be made to the customer during the
software development. Starting with the release of the basic orcore functionalities of the software, more
complete functionalities are made available to the customers every couple of weeks. In this context,
effective release management has become important.

Risk Management: In modern software project management practices, effective risk management is
considered very important to the success of a project. A risk is any negative situation that may arise as the

Dept. of CS&E, BIT Page 14

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
project progresses and may threaten the success of the project. Every project is susceptible to a host of
risks that could usually be attributed to factors such as technology, personnel and customer. Unless
proper risk management is practised, the progress of the project may get adversely affected. Risk
management involves identification of risks, assessment of the impacts of various risks, prioritization of
the risks and preparation of risk-containment plans.

Scope Management: Once a project gets underway, many requirement change requests usually arise.
Some of these can be attributed to the customers and the others to the development team. As we have
already mentioned, modern development practices encourage the customer to come up with change
requests. While all essential changes must be carried out, the superfluous and ornamental changes must
be scrupulously avoided. However, while accepting change requests, itmust be remembered that the three
critical project parameters: scope, schedule and project cost are interdependent and are very intricately
related. If the scope is allowed to change extensively, while strictly maintaining the schedule and cost, then
the quality of the work would be the major casualty.Therefore, for every scope change request, the project
managers examine whether the change request is really necessary and whether the budget and time
schedule would permit it.

Project management life cycle

In Project Management process, the project manager carries out project initiation, planning, execution,
monitoring, controlling and closing.

Dept. of CS&E, BIT Page 15

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4

The different phases of project management life cycle are;

Project Initiation
As shown in Figure, the software project management life cycle starts with project initiation. Theproject
initiation phase usually starts with project concept development. During concept development the
different characteristics of the software to be developed are thoroughly understood. The different aspects
of the project that are investigated and understood include: the scope of the project, project constraints,
the cost that would be incurred and the benefits that would accrue. Based on this understanding, a
feasibility study is undertaken to determine whether the project would be financially and technically
feasible. This is true for all types of projects, including the in-house product development projects as
well as the outsourced projects.
For example, an organization might feel a need for a software to automate some of its activities, possibly
for more efficient operation. Based on the feasibility study, the business case is developed. Once the top
management agrees to the business case, the project manager is appointed, the projectcharter is written, and
finally the project team is formed. This sets the ground for the manager to start the project planning
phase.

As has already been pointed out, during the project initiation phase it is crucial for the championsof the
project to develop a thorough understanding of the important characteristics of the project. In his WSHH
principle, Barry Boehm summarized the questions that need to be asked and answered in order to have an
understanding of these project characteristics.

W5HH Principle: Boehm suggested that during project initiation, the project champions should have
comprehensive answers to a set of key questions pertaining to the project. The answers to these questions
would lead to the definition of key project characteristics. The name of this principle (W5HH) is an
acronym constructed from the first letter of each question. This set of seven questions is the following:

 Why is the software being built?

 What will be done?
 When will it be done?
 Who is responsible for a function?
 Where are they organizationally located?
 How will the job be done technically and managerially?
 How much of each resource is needed?

Dept. of CS&E, BIT Page 16

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
Project bidding: Once an organization's top management is convinced by the business case, the project
charter is developed. For some categories of projects, it may be necessary to have a formalbidding process
to select a suitable vendor based on some cost-performance criteria. If the project involves automating
some activities of an organization, the organization may either decide to develop it in-house or may get
various software vendors to bid for the project. We briefly mention the different types of bidding
techniques and their implications and applicability.
Request for quotation (RFQ) :An organization advertises an RFQ if it has good understanding of the
project and the possible solutions. While publishing the RFQ, the organization would haveto mention the
scope of the work in a statement of work (SOW) document. Based on the RFQ different vendors can
submit their quotations. The RFQ issuing organization can select a vendor based on the price quoted as
well as the competency of the vendor. In government organizations, the term request for tender (RFT) is
usually used in place of RFQ. DFT is similar to RFQ; however,in RFT the bidder needs to deposit a tender
fee in order to participate in the bidding process.

Request for proposal (RFP): Many times it so happens that an organization has reasonable under-standing
of the problem to be solved, however it does not have a good grasp of the solution aspects. That is, the
organization may not have sufficient knowledge about the different features that are to be implemented,
and may lack familiarity with the possible choices of the implementation environment, such as, databases,
operating systems, client-server deployment, etc. In this case, the organization may solicit solution
proposals from vendors. The vendors may submit a few alternative solutions and the approximate costs
for each solution. In order to develop a better understanding, the requesting organization may ask the
vendors to explain or demonstrate their solutions. It needs to be understood that the purpose of RFP is to
get an understanding of the alternative solutions possible that can be deployed and not vendor selection.
Based on the RFP process, the requesting organization can form a clear idea of the project solutions
required, basedon which it can form a statement work (SOW) for requesting RFQ from the vendors.

Request for Information (RFI): An organization soliciting bids may publish an RFI. Based on the
vendor response to the RFI, the organization can assess the competencies of the vendors and shortlist the
vendors who can bid for the work. However, it must be noted that vendor selection isseldom done based
on RFI, but the RFI response from the vendors may be used in conjunction with RFP and RFQ responses
for vendor selection.

Project planning
An important outcome of the project initiation phase is the project charter. During the project planning
phase, the project manager carries out several processes and creates the following documents:

Dept. of CS&E, BIT Page 17

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
➢ Project plan ---This document identifies the project tasks, and a schedule for the project tasks that
assigns project resources and time frames to the tasks.
➢ Resource plan ---It lists the resources, manpower and equipment that would be required to executethe
project.

➢ Financial plan--- It documents the plan for manpower, equipment and other costs.

➢ Quality plan---Plan of quality targets and control plans are included in this document.

➢ Risk plan---This document lists the identification of the potential risks, their prioritization and aplan
for the actions that would be taken to contain the different risks.

Project execution
In this phase the tasks are executed as per the project plan developed during the planning phase. Aseries of
management processes are undertaken to ensure that the tasks are executed as per plan. Monitoring and
control processes are executed to ensure that the tasks are executed as per plan and corrective actions are
initiated whenever any deviations from the plan are noticed. However, the project plan may have to be
revised periodically to accommodate any changes to the project plan that may arise on account of change
requests, execution of proper processes. Once all the deliverables are produced and accepted by the
customer, the project execution phase completes and the project closure phase starts.

Project closure
Project closure involves completing the release of all the required deliverables to the customer along with
the necessary documentation. Subsequently, all the project resources are released and supply agreements
with the vendors are terminated and all the pending payments are completed. Finally, a post
implementation reviews undertaken to analyse the project performance and to list the lessons learnt for
use in future projects.

Management control
Management involves following activities:
 Planning - deciding what is to be done
 Organizing - making arrangements
 Staffing - selecting the right people for the job etc.
 Directing - giving instructions
 Monitoring - checking on progress

Dept. of CS&E, BIT Page 18

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
 Controlling - taking action to remedy hold-ups
 Innovating - coming up with new solutions
 Representing - liaising with clients, users, developer, suppliers and other stakeholders.

➢ Much of the project manager's time is spent on only three of the eight identified activities, viz. project
planning, monitoring, and control. The time period during which these activities are carried out is
indicated in Figure. It shows that project management is carried out over three well-definedstages or
processes, irrespective of methodology used.
➢ In project initiation stage, an initial plan is made. As the project starts, the project is monitored and
controlled to proceed as planned. However the initial plan is revised periodically to accommodate
additional details and constraints about the project as they become available. Finally, the project is
closed. In the project closing stage, all activities are logically completed and all contracts are formally
closed.
➢ Initial project planning is undertaken immediately after the feasibility study phase and before starting
the requirements analysis and specification process. Figure below shows this project initiation period.
Initial project planning involves estimating several characteristics of a project. Based on these
estimates, all subsequent project activities are planned. The initial project plans arerevised periodically
as the project progresses and more project data becomes available. Once the project execution starts,
monitoring and control activities are taken up to ensure that the project execution proceeds as planned.
The monitoring activity involves monitoring the progress of the project. Control activities are initiated
to minimize any significant variation in the plan.
➢ Project planning is an important responsibility of the project manager. During project planning, the
project manager needs to perform a few well-defined activities that have been outlined below.Note that
we have given a very brief description of these activities in this chapter. We will discuss these activities
in more detail in subsequent chapters. Several best practices have been proposed for software project
planning activities. In Chapter 3, we will discuss Step Wise, which is based on the popular PRINCE2
(PRojects IN Controlled Environments) method.
➢ While PRINCE2 is used extensively in the UK and Europe, similar software project management best
practices have been put forward in the USA by the Project Management Institute's ‘PMBOK’ which
refers to their publication 'A Guide to the Project Management Body of Knowledge.
1. Estimation The following project attributes are estimated.
2. Cost How much is it going to cost to complete the project?
3. Duration How long is it going to take to complete the project?
4. Effort How much effort would be necessary for completing the project?

Dept. of CS&E, BIT Page 19

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
The effectiveness of all activities such as scheduling and staffing, which are planned at a later stage,
depends on the accuracy with which the above three project parameters have been estimated.

➢ Scheduling Based on estimations of effort and duration, the schedules for manpower and other
resources are developed

➢ Staffing Staff organization and staffing plans are made.

➢ Risk Management This activity includes risk identification, analysis, and abatementplanning.

➢ Miscellaneous Plans This includes making several other plans such as quality assurance plan,
configuration management plan, etc.
Project monitoring and control activities are undertaken after the initiation of development activities. The
aim of project monitoring and control activities is to ensure that the software development proceeds as
planned. While carrying out project monitoring and control activities, aproject manager may sometimes
find it necessary to change the plan to cope with specific situations and make the plan more accurate as
more project data becomes available.
At the start of a project, the project manager does not have complete knowledge about the detailsof the
project. As the project progresses through different development phases, the manager's information base
gradually improves. The complexities of different project activities become clear, some of the anticipated
risks get resolved, and new risks appear. The project parameters are re-estimated periodically
incorporating new understanding and change in project parameters. By taking these developments into
account, the project manager can plan subsequent activities more accurately with increasing levels of
confidence. Figure 1.5 shows this aspect as iterations between monitoring and control, and the plan
revision activities.

Management control
Management, in general, involves setting objectives for a system and then monitoring the performance of
the system. In Figure 1.6, the 'real world' is shown as being rather formless. Especially in the case of large
Dept. of CS&E, BIT Page 20
SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
undertakings, there will be a lot going on about which managementshould be aware.
This will involve the local managers in data collection. Bare details, such as 'location X has processed
2000 documents", will not be very useful to higher management: data processing will be needed to
transform this raw data into useful information. This might be in such forms as 'percentage of records
processed', 'average documents processed per day per person' and 'estimatedcompletion date’.

In our example, the project management might examine the 'estimated completion date' for completing
data transfer for each branch. These can be checked against the overall target date forcompletion of this
phase of the project. In effect they are comparing actual performance with one aspect of the overall
project objectives. They might find that one or two branches will fail to complete the transfer of details
in time. They would then need to consider what to do (this is represented in Figure 1.6 by the box
Making decisions/ plans). One possibility would be to movestaff temporarily from one branch to another.
If this is done, there is always the danger that while the completion date for the one branch is pulled back

Dept. of CS&E, BIT Page 21

SOFTWARE ENGINEERING & PROJECT MANAGEMENT Module-4
to before the overall targetdate, the date for the branch from which staff are being moved is pushed forward
beyond that date. The project manager would need to calculate carefully what the impact would be in
moving staff from particular branches. This is modelling the consequences of a potential solution. Several
different proposals could be modelled in this way before one was chosen for implementation.
Having implemented the decision, the situation needs to be kept under review by collecting and
processing further progress details. For instance, the next time that progress is reported, a branch to which
staff have been transferred could still be behind in transferring details. This might be because the reason
why the branch has got behind in transferring details is because the manual records are incomplete and
another department, for whom the project has a low priority, has to beinvolved in providing the missing
information. In this case, transferring extra staff to do data inputting will not have accelerated data
transfer.
It can be seen that a project plan is dynamic and will need constant adjustment during the executionof the
project. Courses and books on project management (such as this one) often focus considerable attention
on project planning. While this is to be expected, with nearly all projects much more time is spent
actually doing the project rather than planning it. A good plan provides afoundation for a good project, but
is nothing without intelligent execution. The original plan will not be set in stone but will be modified to
take account of changing circumstances.

Dept. of CS&E, BIT Page 22