Module 4 SEPM

Why is project management important?

Large amounts of money are spent on ICT(Information and communications
technology ) e.g. UK government in 2003-4 spent £2.3 billions on contracts for ICT
and only £1.4 billions on road building . Project often fail – Standish Group claim
only a third of ICT projects are successful. 82% were late and 43% exceeded their
budget. Poor project management a major factor in these failures

What is software project management?

Software project management is the art and science of planning and
leading software projects. It is a sub-discipline of project management in
which software projects are planned, implemented, monitored and controlled

What is a Project?
Project: The dictionary definitions put a clear emphasis on the project being a
planned activity. A project is a unique venture with a beginning and an end,
conducted by people to meet established goals within parameters of cost, schedule
and quality.
 A Planned activity
 A Specific pan or design
 A planned undertaking
 A large undertaking

Non-Software Examples:
 A wedding
 An MBA degree
 A house construction project
 A political election campaign
What is a Task?
A small piece of work:
 Meant to accomplish a straightforward goal
 Effort of no longer than a few person-hours
 Involves only a few people
 May or may not be a part of some project
 Usually repetition of a previously accomplished task
 Process management may be relevant!
Non-software Examples:
 Attend a lecture class
 Buy a chocolate from the market
 Book a railway ticket

Jobs versus Projects

 On the one hand there are repetitive jobs a similar task is carried out
repeatedly, for example Kwikfit replacing a tyre on a car or a lecturer giving
an introductory talk on project management. The task is well-defined and
there is very little uncertainty. In some organizations, software development
might tend to be like this – in these environments software process
management might be more important than software project management
 On the other hand some exploratory activities are very uncertain. Some
research projects can be like this – we may not be sure what the outcome will
be, but we hope that we will learn some things of importance. It may be very
difficult to come up with precise plans, although we would probably have
some idea of a general approach.
 Projects seem to come somewhere between these two extremes. There are
usually well-defined hoped-for outcomes but there are risks and
uncertainties about achieving those outcomes.
Distinguishable characteristics of a project
 Non-routine tasks are involved
 Planning is required
 Specific objectives are to be met
 The project has a predetermined time span
 Work is carried out for someone other than yourself
 Work involves several specialism
 People are formed into temporary work group
 Work is carried out in several phases
 Resources available are constrained
 The project is large and complex.
Software projects Versus other types of project
 İnvisibility
 Complexity
 Confirmity
 Flexibility
Invisibility
 Software remains invisible, until its development is complete and it is
operational. Anything that is invisible is difficult to manage and control.
Consider a house building project. The manager can closely monitor the
progress of the project, and take remedial actions if he finds that the progress
is not as per plan.
 In contrast, it becomes very difficult for the manager of a software project to
assess the progress of the project due to the invisibility of software. The best
that he can do perhaps is to monitor the milestones that have been completed
by the development team and the documents that have been produced ---
which at best are rough indicators of the progress achieved.
 Invisibility of software makes it difficult to assess the progress of a project
and is a major cause for the complexity of managing a software project.

Complexity
 Even moderate sized software has millions of parts (functions) that interact
with each other in many ways: data coupling, serial and concurrent runs,
state transitions, control dependency, file sharing, etc.
 Due to the inherent complexity of the functioning of a software product in
terms of the basic parts making up the software, many types of risks are
associated with its development. This makes managing these projects much
more difficult than that for many other kinds of projects.
 Per dollar, pound or euro spent, software products contain more complexity
than other engineered artifacts.

Conformity
 The ‘traditional’ engineer is usually working with physical systems and
physical materials like cement and steel. These physical systems can have
some complexity, but are governed by physical laws that are consistent.
Software developers have to conform to the requirements of human clients. It
is not just that individual can be inconsistent.
 Organizations, because of lapses in collective memory, in internal
communication or in effective decision making can exhibit remarkable
‘organizational stupidity’ that developers have to cater for.

Flexibility
 The ease with which software can be changed is usually seen as one of its
strengths. However, this means that where the software system interfaces
 with a physical or organizational system, it is expected that, where necessary,
the software will change to accommodate the other components rather than
vice versa. This means the software systems are likely to be subject to a high
degree of change.

Contract Management
It is the management of contracts made with customers, vendors, partners, or
employees. Contract management includes negotiating the terms and conditions in
contracts and ensuring compliance with the terms and conditions, as well as
documenting and agreeing on any changes that may arise during its
implementation or execution. It can be summarized as the process of systematically
and efficiently managing contract creation, execution, and analysis for the purpose
of maximizing financial and operational performance and minimizing risk.

Activities covered by the software project management

 The feasibility study this investigates whether a prospective 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 client and other stakeholders
may be aware of the problems they wish to overcome and the aims they wish
to pursue, but not be sure about the means of achievement. The probable
developmental and operational costs, along with the value of the benefits of
the new system, will also have to be estimated. With a large system, the
feasibility study could be treated as a project in its own right – and have its
own planning sub-phase. The study could be part of a strategic planning
exercise examining and prioritizing a range of potential software
 developments. Sometimes an organization has a policy where a group of
projects is planned as a programme of development.

 Planning If the feasibility study produces results which indicate that the
prospective project appears viable, and then planning of the project can take
place. However, for a large project, we would not do all our detailed
planning right at the beginning. We would formulate an outline plan for the
whole project and a detailed one for the first stage. More detailed planning of
the later stages would be done as they approached. This is because we would
have more detailed and accurate information upon which to base our plans
nearer to the start of the later stages.

 Project execution The project can now be executed. The execution of a project
often contains design and implementation sub-phases. Students new to
project planning often find it difficult to separate planning and design, and
often the boundary between the two can be hazy. Essentially, design is
thinking and making decisions about the precise form of the products that
the project is to create. In the case of software, this could relate to the external
appearance of the software, that is, the user interface, or the internal
architecture. The plan lays down the activities that have to be carried out in
order to create these products. Planning and design can be confused because
at the most detailed level, planning decisions are influenced by design
decisions.

 Requirements analysis This starts with requirements elicitation which

investigates what the potential users and their managers and employers
require as features and qualities of the new system. These will relate to the
system as a whole. A quality requirement might be, for instance, that the user
should be able to complete a transaction within a certain time. In this case
transaction time would be affected by the speed of human operation, as well
as hardware and software performance.

 Architecture design This maps the requirements to the components of the

system that is to be built. At the system level, decisions will need to be made
about which processes in the new system will be carried out by the user and
which can be computerized. This design of the system architecture thus
forms an input to the development of the software requirements. A second
architecture design process then takes place which maps the software
requirements to software components.

 Code and test This could refer to writing code in a procedural language such
as C# or Java, or could refer to the use of an application-builder such as
Microsoft Access. Initial testing to debug individual software components
 lOMoARcPSD|21669848

would be carried out at this stage.

 Integration The individual components are collected together and tested to

see if they meet the overall requirements. Integration could be at the level of
software where different software components are combined, or at the level
of the system as a whole where the software and other components of the
system such as the hardware platforms and networks and the user
procedures are brought together.

 Qualification testing The system, including the software components, has to

be tested carefully to ensure that all the requirements have been fulfilled.

 Installation This is the process of making the new system operational. It

would include activities like setting up standing data (such as payroll details
for employees if this were a payroll system). It would also include setting
system parameters, installing the software onto the hardware platforms and
user training.

 Acceptance support This is the resolving of problems with the newly

installed system, including the correction of any errors that might have crept
into the system, and any extensions and improvements that are required. It is
possible to see software maintenance as a series of minor software projects. In
many environments, most software development is in fact maintenance
Plan, 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 you would need to
 Analyze the requirements for the software
 Devise and write test cases that will check that each requirement has been
satisfied
 Create test scripts and expected results for each test case
While a method relates to a type of activity in general. Group of methods of
techniques are often grouped into methodologies such as object design.

Some ways to categorizing software projects

 Compulsory versus voluntary projects
 Information systems versus embedded systems
 Oursourced projects
 Object driven versus product driven development

 In the information systems, the system interfaces with the organization and
in the embedded systems, the system interfaces with the machine
 With objective-based projects, a general objective or problem is defined, and
there are several different ways in which that objective could be reached. The
project team have freedom to select what appears to be the most appropriate
approach.
 With product-based projects, the product is already very strictly de-
fined and the development team’s job is to implement the specification
with which they have been presented. Arguably, information systems
projects are more likely to be objective-based than is the case with soft-
 ware engineering.
 In many cases, an objective-based project could consider a problem and
recommend a solution that is then implemented by a product-based
project.
 A software product development project concerns developing the software
by keeping the requirements of the general customers in mind and the devel-
oped 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 prod-
uct. A generic software product is sold to a broad spectrum of customers and
is said to have a horizontal market.
 Software services on the other hand, cover a large amount of software pro-
jects such as customization, outsourcing, maintenance, testing, and consul-
tancy.
 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. One of
the reasons behind this situation is the steep growth in the available
code base. Over the past few decades, a large number of programs have
already been developed. Available programs can therefore be modified
to quickly fulfill the specific requirements of any customer.
 At present, there is hardly any software project in which the program
code is written from scratch, and software is being mostly developed
by customizing some existing software.
 For example, to develop software to automate the payroll generation
activities of an educational institute, the vendor may customize existing
software that might have been developed earlier for a different client
educational institute. Due to heavy reuse of code, it has now become
possible to develop even large software systems in rather short periods
of time. Therefore, typical project durations are at present only a couple
of months and multi-year projects have become very rare.

Stake Holders
Stakeholder is a person or group of people who can affect or be affected by a
given project. Stakeholders can be individuals working on a project, groups of
people or organizations, or even segments of a population. A stakeholder may be
actively involved in a project’s work, affected by the project’s outcome, or in a
position to affect the project’s success. Stakeholders can be an internal part of a
project’s organization, or external, such as customers, creditors, unions, or
members of a community. Each stakeholder will have their own goals and
concerns in relation to the project which may be different from those of the project
as a whole. For example, a software developer might work to make a living, pay
the mortgage, learn new things, solve interesting problems. The main stakeholders
need, however, to understand and accept overall project objectives that everyone
can agree to.
They could be:
 Within the project team
 They are under the direct control of the project leader.
 Outside the project team, but within the same organization
 The persons involved in providing assistance from other sources to
carry out the systems testing and functionality.
 Outside both the project team and the organization
 Customers, investors who will benefit from the system or the sub-
contractors who will carry out work for the project

Example
A public library is considering the implementation of a computer-based system
to help administer book loans at libraries. Identify the stakeholders in such a
project Stakeholders
These could include:
 The local authority who own and pay for the library
 The political leadership
 Finance, human resources and other support services
 Library staff at various levels
 Technical support staff
 Software and hardware suppliers
 Library users

Note (a) the stakeholders will vary depending on the implementation approach
adopted for the project
(b) Library users could be sub-divided into different customer segments, e.g.
school children, senior citizens and so on
(c) Some stakeholders will be more distant than others: for examples it could be
argued that authors might be stakeholders in the loans system as the record of
loans of their books could affect their income. However, this would not necessi-
tate having an author as an adviser on the project.

Setting Objectives
Different people who are involved in a project (Stakeholders) will have
different interests in the project and are likely to see different outcomes as being
important. For example, end-users would want a system that is ‘user-friendly’, that
is, easy to learn and to use, and a system that helps rather than hinders them from
doing their jobs. Their managers may be more interested in whether the new
system would allow them to reduce staffing levels. It is important therefore that a
set of clearly defined objectives are identified and published for the project.
Some individual or group needs to be pinpointed who acts as the main client
for the project. The project details should be clearly defined that are accepted by all
the employees of an organization.
The project authority must be identified where there is more than one group
. This authority is held by a project steering committee that has the overall
responsibility for setting, monitoring and modifying the objectives. The project
manager still has responsibility for running the project on a day to day basis, but
has to report to the steering committee at regular intervals. Only the steering
committee can authorize changes to the project objectives and resources. Could be
one person - or a group. Overall authority over the project is often termed as
project steering committee or project management board. The project manager runs
the project on a day-to-day basis, but regularly reports to the steering committee.
Roles:
i) Setting, monitoring and modifying objectives.
ii) The project manager runs the project on a day-to-day basis, but regularly
reports to the steering committee.
Answering the question ‘What do we have to do to have a success?’.
Informally, the objective of a project can be defined by completing the statement:
The project will be regarded as a success if………………………………..
Rather like post-conditions for the project
 Focus on what will be put in place, rather than how activities will be carried
out
 The focus here needs to be on what the situation will be when the project is
completed. In what ways will the world be different? The objectives should
avoid describing activities:
 e.g. ‘a new payroll application will be operational by 4 th April’ not ‘design
and code a new payroll application’

Objectives should be SMART

 S – specific, that is, concrete and well-defined
 M – measurable, that is, satisfaction of the objective can be objectively judged
 A – achievable, that is, it is within the power of the individual or group
concerned to meet the target
 R – relevant, the objective must relevant to the true purpose of the project
 T – time constrained: there is defined point in time by which the objective
should be achieved

Goals/Sub-Objectives
 In order to keep things manageable, objectives might need to be broken down
into sub-objectives. Here we say that in order to achieve A we must achieve
B, C and D first. These sub-objectives are also known as goals, 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. This committee is likely
to contain user, development and management representatives.
 The measure can, in some cases, be an answer to simple yes/no question,
'Did we install the new software by 1 st June?' for example.
 These are steps along the way to achieving the objective
Informally, these can be defined by completing the sentence
To reach objective X, the following must be in place
A……………
B……………
C…………… etc

 Often a goal can be allocated to an individual. Individual may have the capa-
bility of achieving goal, but not the objective on their own e.g.
 Objective – user satisfaction with software product
 Analyst goal – accurate requirements
 Developer goal – software that is reliable
 Scoring a goal in football is a ‘goal’ or sub-objective on the way to achieving
the overall objective of winning the match. Sub-objectives and objectives can
be nested in a hierarchy, so that the objective of winning the match could it-
self be a goal or sub-objective on the way to winning the league etc.
 Goals can be formulated in such a way that they represent what an individ-
ual or group need to do to contribute to the success of the project’s objectives.
 In the example above, the analyst or developer, by themselves, cannot guar-
antee user satisfaction. However, the analyst can contribute to the achieve-
ment of the objective by making sure the users’ requirements are accurately
recorded and the developer by making sure that the software is reliable.
Measures of Effectiveness
Effective objectives are concrete and well defined. Vague aspirations such as
'to improve customer relations' are unsatisfactory. Objectives should be such that it
is obvious to all whether the project has been successful or not. Ideally there should
be measures of effectiveness, which tell us how successful the project has been.
For example, 'to reduce customer complaints by 50%' would be more
satisfactory as an objective than 'to improve customer relations'. How do we know
that the goal or objective has been achieved? By a practical test, that can be
objectively assessed.
e.g. for user satisfaction with software product:
 Repeat business – they buy further products from us
 Number of complaints – if low etc etc
Project Success/Failure
Degree to which objectives are met
Scope

Time Cost
In general if, for example, project is running out of time, this can be recovered for
by reducing scope or increasing costs. Similarly costs and scope can be protected
by adjusting other corners of the ‘project triangle’.

Management
Management can be defined as all activities and tasks undertaken by one or more
Persons for the purpose of planning and controlling the activities of others in order
to achieve objectives or complete an activity that could not be achieved by others
acting independently.It has been suggested that management involves the
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
Identified the following commonly experienced problems:
 Poor estimates and plans;
 Lack of quality standards and measures;
 Lack of guidance about making organizational decisions;
 Lack of techniques to make progress visible;
 Poor role definition – which does what?
 Incorrect success criteria.
The above list looks at the project from the manager’s point of view. What about
the staff who make up the members of the project team? Below is a list of the
problems identified by a number of Computing and Information Systems degree
students who had just completed a year’s industrial placement:
 Inadequate specification of work
 Management ignorance of ICT
 Lack of knowledge of application area
  Lack of standards
 Lack of up-to-date documentation; preceding activities not completed on
time – including late delivery of equipment
 Lack of communication between users and technicians
 Lack of communication leading to duplication of work
 Lack of commitment – especially when a project is tied to one person who
then moves;
 Narrow scope of technical expertise
 Changing statutory requirements
 Changing software environment
 Deadline pressure
 Lack of quality control
 Remote management and Lack of training.

Management Control
Management Control System is defined a ‘set of policies and procedures designed
to keep operations going according to plan”.

The project control cycle

Management, in general, can be seen as the process of setting objectives for a
system and then monitoring the system to see what its true performance is.
 In Figure 1.4 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 man-
agement should be aware. As an example, take an IT project that is to replace
locally held paper-based records with a centrally-organized database. It
might be that staff in a large number of offices that are geographically dis-
persed need training and then need to use the new IT system to set up the
back-log of manual records on the new database. It might be that the system
cannot be properly operational until the last record has been transferred. It
might also be the case that the new system will be successful only if new
transactions can be processed within certain time cycles.
 The managers of the project ought to be asking questions about such things
as how effective training has been, how many records have still to be trans-
ferred to the new database and transfer rates. 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 pro-
cessing 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 the example above, the project leader might examine the 'estimated com-
pletion date' for completing data transfer for each branch and compare this
with 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 are not going to
complete the transfer of details in time, and would then need to consider
what to do (this is represented in Figure 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 staffs 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 might still be behind in transferring details.
This might be because the reason why the branch has got behind in transfer-
ring details is because the manual records are incomplete and another de-
partment, 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 input will not have accelerated data transfer.
Project Management Processes
In the project initiation stage, an initial plan is made. As the project starts, the
project is executed and controlled to proceed as planned. Finally, the project is
closed.

Project Management Life Cycle Versus Product Development Life Cycle

During the software development life cycle, the software developers carry out
several types of development processes. On the other hand, during the software
project management life cycle, the software project manager carries out several
project management processes.

Phases of Project Management Life Cycle

Project Initiation
 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 W5HH 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
 A series of questions that lead to a definition of key project characteristics:
 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 Planning
 Various plans are made:
 Project plan: Assign project resources and time frames to the tasks.
 Resource plan: List the resources, manpower and equipment that re-
quired to execute the project.
 Financial plan: plan for manpower, equipment and other costs.
 Quality plan: Plan of quality targets and control.
 Risk plan: Identification of the potential risks, their prioritization and a
plan for the actions that would be taken to contain the different risks.

Project Execution
 Tasks are executed as per the project plan
 Monitoring and control processes are executed to ensure that the tasks are
executed as per plan
 Corrective actions are initiated whenever any deviations from the plan are
noticed.

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 review is undertaken to analyze the project
performance and to list the lessons learnt for use in future projects.