Module 4

Introduction
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 less
to 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. In these cases, planning hardly seems necessary, although procedures might be
documented to ensure consistency and to help newcomers.
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.

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:

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 artefacts.

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 long
as 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 their aims but not be sure about the means of achievement.
 Developmental and operational costs need to be [Link] 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.
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 functional
requirements, 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 that
can 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.
 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 onto
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.

Planning, 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
  analyse 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 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 be
an 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.

 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.
 Reasons:
a) Steep growth in available code base.
b) Many programs have already been developed and can be modified for specific customer
needs.
c) 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 systems
in 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 devel- opment as well.
The type of development work a company handles impacts its profitability. A company developing
a 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 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 important
as 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 usually
based 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 be
more 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.

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-commerce
site.'

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 and
regularly 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 business
objective, 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 used
acronym 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.

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,
 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 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 are
several 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 or
core 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 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, it
must 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. Offen, the
scope change requests are superfluous. For example, an overenthusiastic project team member
may suggest to add features that are not required by the customer. Such scope change requests
originated by the overenthusiastic team members are called goldplating and should be discouraged
if the project is to succeed. The customer may also initiate scope change requests that are more
ornamental or at best nonessential. These serve only to jeopardize the success of the project, while
not adding any perceptible value to the delivered software. Such avoidable scope change requests
originated by the customer are termed as scope creep. To ensure the success of the project, the
project manager needs to guard against both gold plating and scope creep.

Project management life cycle

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

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. The
project 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 project
charter 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 champions
of 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?

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 formal
bidding 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 have
to 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, based
on 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 is
seldom 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:
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 execute
the 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 a
plan 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. A
series 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 postimplementation reviews undertaken to analyse the project performance and to list
the lessons learnt for use in future projects.

Management and management control

Management
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
 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-defined
stages or processes,irrespective of methodology [Link] project initiation stage,an initial plan is
[Link] the project starts,the project is monitored and controlled to proceed as [Link]
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 are
revised 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.

Estimation The following project attributes are estimated.

Cost How much is it going to cost to complete the project?

Duration How long is it going to take to complete the project?

Effort How much effort would be necessary for completing the project?

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 abatement
planning.
 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, a
project 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 details
of 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 undertakings, there will be a lot going on about which management
should 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 'estimated
completion 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 for
completion 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 move
staff 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 to before the overall target
date, 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 be
involved 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 execution
of 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 a
foundation 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.