IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
Module-1 Project Evaluation and Project Planning
1.1 Introduction
What is Project?
A project is a temporary endeavor undertaken to create a unique product,
service, or result.
It involves a series of tasks, activities, and deliverables executed within a
defined timeframe and budget, with the goal of achieving a specific objective.
Projects are distinct from ongoing operational work and have a clear start
and end point.
What is Project Management?
Project management is a systematic approach to planning, organizing, and
managing resources to achieve specific project goals within defined
constraints.
It involves coordinating various activities, tasks, and people to deliver a
project successfully, on time, and within budget.
What is Software Project Management
Software Project Management (SPM) is all about planning, organizing, and
observing the software development process to make sure the project is
completed successfully, on time, and within budget.
It involves tasks like planning, defining the project scope, calculating how
much time and resources are needed, scheduling tasks, allocating
resources, and tracking progress.
The ultimate goal is to deliver a high-quality software product that meets the
needs and expectations of the users.
1.2 Importance of Software Project Management
➢ First, there is the question of money. A lot of money is at stake with ICT
(Information and Communication Technology) projects.
➢ In the United Kingdom during the financial year 2002–2003, the central
government spent more on contracts for ICT projects than on contracts
related to roads (about £2.3 billion as opposed to £1.4 billion). The
biggest departmental spender was the Department for Work and
Pensions, who spent over £800 million on ICT.
➢ Mismanagement of ICT projects means that there is less to spend on
good things such as hospitals.
➢ Unfortunately, projects are not always successful. In a report published
in 2003, the Standish Group in the United States analysed 13,522
projects and concluded that only a third of projects were successful; 82%
of projects were late and 43% exceeded their budget.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
➢ The reason for these project shortcomings is 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’.
1.3 What is Project?
➢ The dictionary definitions put a clear emphasis on the project being a
planned activity.
➢ 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.
➢ The activities that benefit most from conventional project management
are likely to lie between these two extremes.
Activities most likely to benefit from project management
➢ 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:
1. non-routine tasks are involved;
2. planning is required;
3. specific objectives are to be met or a specified product is to be created;
4. the project has a predetermined time span;
5. work is carried out for someone other than yourself;
6. work involves several specialisms;
7. people are formed into a temporary work group to carry out the task;
8. work is carried out in several phases;
9. the resources that are available for use on the project are constrained;
10. the project is large or complex.
➢ Projects are especially problematic as they are temporary sub-
organizations.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
➢ 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.
1.4 Activities Covered by Software Project Management
➢ There are three successive processes that bring a new system into being
1. The feasibility study
2. Planning
3. Project execution
The feasibility study/plan/execution cycle
1. The feasibility study assesses whether a project is worth starting – that
it has a valid business case.
➢ Information is gathered about the requirements of the proposed
application.
➢ Requirements elicitation can, at least initially, be complex and difficult.
➢ The stakeholders may know the aims they wish to pursue, but not be
sure about the means of achievement.
➢ The developmental and operational costs, and the value of the benefits of
the new system, will also have to be estimated.
➢ With a large system, the feasibility study could be a project in its own
right with its own plan.
➢ The study could be part of a strategic planning exercise examining a
range of potential software developments.
➢ Sometimes an organization assesses a programme of development made
up of a number of projects.
2. Planning If the feasibility study indicates that the prospective project
appears viable, then project planning can start.
➢ For larger projects, we would not do all our detailed planning at the
beginning.
➢ We create an outline plan for the whole project and a detailed one for the
first stage.
➢ Because we will have more detailed and accurate project information
after the earlier stages of the project have been completed, planning of
the later stages is left to nearer their start.
3. Project execution The project can now be executed. The execution of a
project often contains design and implementation sub-phases.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
➢ Students new to project planning often find that the boundary between
design and planning can be hazy.
➢ 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.
➢ Planning and design can be confused because at the most detailed level,
planning decisions are influenced by design decisions.
➢ Thus a software product with five major components is likely to require
five sets of activities to create them.
The ISO 12207 so ware development life cycle
➢ The typical sequence of software development activities recommended in
the international standard ISO 12207.
➢ Some activities are concerned with the system while others relate to
software.
➢ The development of software will be only one part of a project.
1. Requirements analysis starts with requirements elicitation or
requirements gathering which establishes what the potential users and
their managers require of the new system.
➢ It could relate to a function – that the system should do something.
➢ It could be a quality requirement – how well the functions must work.
➢ An example of this is dispatching an ambulance in response to an
emergency telephone call.
➢ In this case transaction time would be affected by hardware and
software performance as well as the speed of human operation.
➢ Training to ensure that operators use the computer system efficiently
is an example of a system requirement for the project, as opposed to a
specifically software requirement.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
➢ There would also be resource requirements that relate to application
development costs.
2. Architecture design 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.
➢ Although software developers are primarily concerned with software
components, it is very rare that these can be developed in isolation.
➢ They will, for example, have to take account of existing legacy
systems with which they will interoperate.
➢ 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.
3. 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.
4. 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.
5. Integration The components are tested together to see if they meet the
overall requirements. Integration could involve combining different
software components, or combining and testing the software element of
the system in conjunction with the hardware platforms and user
interactions.
6. Qualification testing The system, including the software components,
has to be tested carefully to ensure that all the requirements have been
fulfilled.
7. Installation This is the process of making the new system operational. It
would include activities such as setting up standing data (for example,
the details for employees in a payroll system), setting system parameters,
installing the software onto the hardware platforms and user training.
8. Acceptance support This is the resolving of problems with the 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. In many
environments, most software development is in fact maintenance.
1.5 Plans, Methods and Methodologies
➢ A plan for an activity must be based on some idea of a method of work.
➢ For example, if you were asked to test some software, you may know
nothing about the software to be tested, but you could assume that you
would need to:
1. analyse the requirements for the software;
2. devise and write test cases that will check that each requirement has
been satisfied;
3. create test scripts and expected results for each test case;
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
4. compare the actual results and the expected results and identify
discrepancies.
➢ While a method relates to a type of activity in general, a plan takes that
method (and perhaps others) and converts it to real activities, identifying
for each activity:
1. its start and end dates;
2. who will carry it out;
3. what tools and materials – including information – will be needed.
➢ The output from one method might be the input to another. Groups of
methods or techniques are often grouped into methodologies such as
object-oriented design.
1.5 Categories of 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.
1.5.1 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.
1.5.2 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.
1.5.3 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.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
➢ 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 fi ne reputation in this fi eld all over the
world. Of late, the Indian companies have slowly begun to focus on
product development as well.
➢ The type of development work being handled by a company can have an
impact on its profitability.
1.5.4 Objective-driven development
➢ Projects may be distinguished by whether their aim is to produce a
product or to meet certain objectives.
➢ A project might be to create a product, the details of which have been
specified by the client.
➢ The client has the responsibility for justifying the product.
➢ On the other hand, the project requirement might be to meet certain
objectives which could be met in a number of ways.
➢ An organization might have a problem and ask a specialist to recommend
a solution.
➢ Many software projects have two stages. First is an objective-driven
project resulting in recommendations.
➢ This might identify the need for a new software system.
➢ The next stage is a project actually to create the software product.
➢ This is useful where the technical work is being done by an external
group and the user needs are unclear at the outset.
➢ The external group can produce a preliminary design at a fixed fee.
➢ If the design is acceptable the developers can then quote a price for the
second, implementation, stage based on an agreed requirement.
1.6 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:
1. Internal to the project team This means that they will be under the
direct managerial control of the project leader.
2. 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
has to be negotiated.
3. 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.
1.7 Setting Objectives
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
➢ The objectives should defi ne what the project team must achieve for
project success.
➢ Although different stakeholders have different motivations, the project
objectives identify the shared intentions for the project.
➢ Objectives focus on the desired outcomes of the project rather than the
tasks within it – they are the ‘post-conditions’ of the project. Informally
the objectives could be written as a set of statements following the
opening words ‘the project will be a success if. . . .’
➢ Thus one statement in a set of objectives might be ‘customers can order
our products online’ rather than ‘to build an e-commerce website’.
➢ There may be several stakeholders, including users in different business
areas, who might have some claim to project ownership. In such a case, a
project authority needs to be explicitly identified with overall authority
over the project.
➢ This authority is often a project steering committee (or project board or
project management board) with overall responsibility for setting,
monitoring and modifying objectives.
➢ The project manager runs the project on a day-to-day basis, but regularly
reports to the steering committee.
1.7.1 Sub-objectives and goals
➢ An objective might be that the software application produced must pay
for itself by reducing staff costs.
➢ A more appropriate goal or sub-objective for the software developers
would be to keep development costs within a certain budget.
➢ We can say that in order to achieve the objective we must achieve certain
goals or sub-objectives first.
➢ These are steps on the way to achieving an objective, just as goals scored
in a football match are steps towards the objective of winning the match.
➢ Informally this can be expressed as a set of statements following the
words ‘To reach objective. . ., the following must be in place. . .’.
➢ The mnemonic SMART is sometimes used to describe well-defined
objectives:
1. Specific: Effective objectives are concrete and well defi ned. Vague
aspirations such as ‘to improve customer relations’ are unsatisfactory.
Objectives should be defined so that it is obvious to all whether the
project has been successful.
2. Measurable: Ideally there should be measures of effectiveness which
tell us how successful the project has been. For example, ‘to reduce
customer complaints’ would be more satisfactory as an objective than
‘to improve customer relations’.
➢ The measure can, in some cases, be an answer to simple yes/no
question, e.g. ‘Did we install the new software by 1 June?’
3. Achievable: It must be within the power of the individual or group to
achieve the objective.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
4. Relevant: The objective must be relevant to the true purpose of the
project.
5. Time constrained: There should be a defi ned point in time by which
the objective should have been achieved.
1.7.2 Measures of Effectiveness
➢ Measures of effectiveness provide practical methods of checking that an
objective has been met.
➢ ‘Mean time between failures’ (mtbf) might, for example, be used to
measure reliability.
➢ This is a performance measurement and, as such, can only be taken once
the system is operational.
➢ Project managers want to get some idea of the performance of the
completed system as it is being constructed.
➢ They will therefore seek predictive measures.
➢ For example, a large number of errors found during code inspections
might indicate potential problems with reliability later.
1.8 What is Management?
➢ It has been suggested that management involves the following activities:
1. planning – deciding what is to be done;
2. organizing – making arrangements;
3. staffing – selecting the right people for the job etc.;
4. directing – giving instructions;
5. monitoring – checking on progress;
6. controlling – taking action to remedy hold-ups;
7. innovating – coming up with new solutions;
8. 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.
Principal project management processes
➢ The above diagram shows that project management is carried out over
three well-defi ned stages or processes, irrespective of the methodology
used.
➢ In the project initiation stage, an initial plan is made.
➢ As the project starts, the project is monitored and controlled to proceed
as planned.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
➢ 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.
➢ 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-defi ned activities that have been outlined below.
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?
➢ 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.
1. Scheduling Based on estimations of effort and duration, the
schedules for manpower and other resources are developed.
2. Staffing Staff organization and staffing plans are made.
3. Risk Management This activity includes risk identification, analysis,
and abatement planning.
4. 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.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
➢ 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.
1.9 Management Control
➢ Management, in general, involves setting objectives for a system and then
monitoring the performance of the system.
The project control cycle
➢ 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’.
➢ 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.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA
IV SEM MCA IT PROJECT MANAGEMENT MODULE-1
➢ They would then need to consider what to do (In the above figure the box
making decision/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.
➢ 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.
Compiled by: Kavyashree G J
Assistant Professor Dept. of MCA