INTRODUCTION

The need for management is an important distinction between professional

software development and amateur programming. Software project
management is required because professional software engineering is always
subject to budget and schedule constraints. These are set by organization
developing the Software. The Software project manager’s job is to ensure that
software project meets these constraints and delivers software that contributes
to the business goals.

Software managers are responsible for planning, scheduling, Estimation and Risk
Analysis. They monitor the work that it is carried out according to the
requirements and Standards. The most important thing in the development is
that it’s done on time and within the budget. It is not like good project
management can bring the Fruitful results but they might be far better than the
poor management.

Software engineers does the same kind of job like other engineers does but there
are many issues that makes the software engineering difficult and compare to
other tasks, this may include.

1. The product is intangible.

2. The product is uniquely flexible.
3. Software engineering is not recognized as an engineering discipline with
the sane status as mechanical, electrical engineering, etc.
4. The software development process is not standardised.
5. Many software projects are 'one-off' projects.

SCOPE OF THE STUDY

This might include the Following topics which might be discussed in detail, and
the report is for the purpose to discuss all these activities and provide the
Solutions required to carry these Steps in an organized manner.

• Management Activities.
• Project Planning.
• Project Scheduling.
• Risk Management.

REPORT FORMAT

This report includes three main sections:

1. Complete Description of the Steps involved in project management.

2. Steps required carrying out each particular Activity.
3. Conclusion and Recommendations.
 Management Activities
It isn’t possible to completely achieve all the objectives of the jobs and especially
in the case of software management most managers take responsibility at some
stage for some or all of the following activities:

• Proposal Writing.
• Project Planning and Scheduling.
• Project Costing.
• Project monitoring and reviews.
• Personnel selection and evaluation.
• Report writing and presentation.

The first stage includes the proposal to win the project; this includes the
objective and goals of the project. Mostly it contains cost and schedule
Estimates, it might be critical task due to the competition in the market.

Project planning is concerned with identifying the activities, milestones and

deliverables produced by a project. Similarly Cost estimation is a related activity
that is concerned with estimating the resources required to accomplish the
project plan.

Project monitoring is one of the responsibilities of the Project manger to keep

the track of the progress and compare actual and planned progress and costs.
The most effective would be the daily meetings that must conducted between
the Staff members to monitor the progress and make amendments according to
the situation. Throughout the monitoring session, Reviews are also the side
partner of it, which help in getting the picture of the project clear, that how much
success is achieved or possible.

Staff selection is a great issue in order to continue with the Project, this might
include following reasons:

• Project budget may not allow for the use of highly-paid staff;
• Staff with the appropriate experience may not be available;
• An organisation may wish to develop employee skills on a software
project.
• Managers have to work within these constraints especially when there are
shortages of trained staff.

Manager is also responsible for to keep the customer party informed with the
Details, and it can be more difficult, if we are dealing with time taking software’s.
This might include number of presentations and Report writing to make the client
understand the technicalities of the Project. Mostly Prototypes is the best
presentation activity to make the Client Comfortable with the work done.
 Project Planning
The most time consuming project management activity that has to be carried
throughout the development cycle. In short it’s the continuous activity from
initial concept through to system delivery. Plans must be regularly revised as
new information becomes available. Various different types of plan may be
developed to support the main software project plan that is concerned with
schedule and budget.

PSEUDO-CODE

The Project Planning Pseudo code which lets us understand how to handle the
complexity of the Project,

Establish the project constraints

Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise ) then
Initiate technical review and possible revision
end if
end loop

Firstly the project requires getting its constraint set up so that things should be
developed accordingly; initial assessments are taken place for the project
parameters. Accordingly Deliverables and milestones are decided. This Plan
structure is responsible to take the things in order and according to the
schedules. However all this task depends upon the manager, that how better he
can make the work done? Project Schedule is made and activities takes place
according to it similarly all reviews and re-negotiating task occurs continuously
to look out for the holes and get the holes fixed. And if the Problem arises then
proper risk management activities are brought in to use.

STRUCTURE OF PLANINNG

The Structure of the Planning lets one know to how to carry out the Process. This
includes the Following Activities,

• Introduction (to set the constraints and basic objectives of the Project).
 • Project organisation (describes the way in which team is organised, i.e.
setting the works).
• Risk analysis (describe the possible project risks).
• Hardware and software resource requirements (hardware and software
support).
• Work breakdown (break down of the Projects in to activities or
milestones).
• Project schedule (Shows the dependencies).
• Monitoring and reporting mechanisms (Describes the management
reports that must be produced).

Activities in a project should be organised to produce tangible outputs for

management to judge progress. Milestones are the end-point of a process
activity. Deliverables are project results delivered to customers.

ACTIVITIES

Feasibility Requirements Prototype Design Requirements

study analy sis development study specifica
tion

Feasibility User Evaluation Architectur

al System
report requirements report design requirements

MILESTONES

FAILURE

The Project Plan can set out due to following reasons:

• The required resources aren’t available.

• The Work Break Down (causes effect to the schedule).
• To Co-op with the Schedule.
 Project Scheduling
Project Scheduling is one of the difficult tasks for the project manager, Managers
are required to estimate the time resources required to complete the need of the
Project and bring it in to working order. Its life is till the deployment of the
Project; however it regains its life when the Project again comes in to the Stage
of maintenance. This might include the Following important tasks.

• Split project into tasks and estimate time and resources required to
complete each task.
• Organize tasks concurrently to make optimal use of workforce.
• Minimize task dependencies to avoid delays caused by one task waiting
for another to complete.
• Dependent on project manager’s intuition and experience.

The more clear understanding of this activity can be feasible through below
diagram. It tells each activity to be carried in the particular way.

Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities to activities charts

Software Activity char

ts
requirements and bar char
ts

BAR CHARTS AND ACTIVITY NETWORKS

These are the graphical notations used to illustrate the project schedule. Bar
Charts show project breakdown into tasks. Tasks should not be too small. They
should take about a week or two. Activity charts show task dependencies and the
critical path. Bar charts show schedule against calendar time.
 Dependency diagram Activity Diagram

Bar Chart Diagram

The Above Diagram shows the dependency diagram which tells us about the
arrangement and dependency of the work, Similarly Bar chart and Activity
network diagrams are shown.

SCHEDULING PROBLEMS

Following are the problems that manager face while creating the schedule,

• Estimating the difficulty of problems and hence the cost of developing

a solution is hard.
• Productivity is not proportional to the number of people working on a
task.
• Adding people to a late project makes it later because of
communication overheads.
• The unexpected always happens. Always allow contingency in
planning.
 Risk Management
Risk management is concerned with identifying risks and drawing up plans to
minimise their effect on a project. A risk is a probability that some adverse
circumstance will occur, this might include

• Project risks affect schedule or resources.

• Product risks affect the quality or performance of the software being
developed.
• Business risks affect the organisation developing or procuring the
software.

The Following table shows the risk and its affects.

Risk
Staff turnover
RISK MANAGMENT PROCESS

The process of risk management is illustrated in the Diagram, it includes the

Following Steps.

Risk Risk
Risk analysis Risk planning
identification monitoring

Risk avoidance
List of potential Prioritised risk Risk
and contingency
risks list assessment
plans

• Risk identification
○ Identify project, product and business risks;
• Risk analysis
○ Assess the likelihood and consequences of these risks;
• Risk planning
○ Draw up plans to avoid or minimise the effects of the risk;
• Risk monitoring
○ Monitor the risks throughout the project;

RISK IDENTIFICATION

It’s the first stage of risk management. It’s concerned with discovering possible
risks to the project. Risk identification can be carried out as a team process using
a brainstorming Approach pr may simply be based on experience. There are at
least six types of risk that can arise. It can be understood able through this table.

Risk type Possible risks

Technology The database used in the system cannot process as many

transactions per second as expected.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management are
responsible for the project.
Organisational financial problems force reductions in the project
budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements that require major design rework are
proposed.
Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.

RISK ANALYSIS

Assess probability and seriousness of each risk. Probability may be very low, low,
moderate, high or very high. Risk effects might be catastrophic, serious,
tolerable or insignificant.

Risk Probability Effects

Organisational financial problems force reductions in Low Catastrophic

the project budget.

It is impossible to recruit staff with the skills High Catastrophic

required for the project.

Key staff are ill at critical times in the project. Moderate Serious

Software components that should be reused contain Moderate Serious

defects which limit their functionality.

Changes to requirements that require major design Moderate Serious

rework are proposed.

The organisation is restructured so that different High Serious

management are responsible for the project.

Risk Probability Effects

The database used in the system cannot process as Moderate Serious

many transactions per second as expected.

The time required to develop the software is High Serious

underestimated.

CASE tools cannot be integrated. High Tolerable

Customers fail to understand the impact of Moderate Tolerable

requirements changes.

Required training for staff is not available. Moderate Tolerable

The rate of defect repair is underestimated. Moderate Tolerable

The size of the software is underestimated. High Tolerable

The code generated by CASE tools is inefficient. Moderate Insignificant

RISK PLANNING

Consider each risk and develop a strategy to manage that risk.

• Avoidance strategies
○ The probability that the risk will arise is reduced;
• Minimisation strategies
○ The impact of the risk on the project or product will be reduced;
• Contingency plans
○ If the risk arises, contingency plans are plans to deal with that risk;

Risk Strategy

Organisational Prepare a briefing document for senior

financial management showing how the project is
problems making a very important contribution to the
goals of the business.
Recruitment Alert customer of potential difficulties and the
problems possibility of delays, investigate buying-in
components.
Staff illness Reorganise team so that there is more overlap
of work and people therefore understand each
other’s jobs.
Defective Replace potentially defective components with
components bought-in components of known reliability.
Requirements Derive traceability information to assess
changes requirements change impact, maximise
information hiding in the design.
Organisational Prepare a briefing document for senior
restructuring management showing how the project is
making a very important contribution to the
goals of the business.
Database Investigate the possibility of buying a higher-
performance performance database.
Underestimated Investigate buying in components, investigate
development time use of a program generator

RISK MONITORING

Risk monitoring involves regularly assessing each of the identified risks to decide
whether or not that risk is becoming more or less probable and whether the
effects of the risks have been changed. This might include following steps.
 • Assess each identified risks regularly to decide whether or not it is
becoming less or more probable.
• Also assess whether the effects of the risk have changed.
• Each key risk should be discussed at management progress meetings.

Risk type Potential indicators

Technology Late delivery of hardware or support software, many

reported technology problems
People Poor staff morale, poor relationships amongst team
member, job availability
Organisational Organisational gossip, lack of action by senior
management
Tools Reluctance by team members to use tools, complaints
about CASE tools, demands for higher-powered
workstations
Requirements Many requirements change requests, customer
complaints
Estimation Failure to meet agreed schedule, failure to clear
reported defects

Conclusion and Recommendations

Good project management is essential for project success because of the
intangible nature of software causes problems for management. Managers have
diverse roles but their most significant activities are planning, estimating and
scheduling. Planning and estimating are iterative processes
which continue throughout the course of a project. A project milestone is a
predictable state where a formal report of progress is presented to management.
Project scheduling involves preparing various graphical representations showing
project activities, their durations and staffing. Risk management is concerned
with identifying risks which may affect the project and planning to ensure that
these risks do not develop into major threats.